IT vulnerability researcher Netanel Rubin has detailed a critical loophole in Moodle that would let a hacker execute malicious code on behalf of the site. This flaw affects all Moodle versions, and it has already been identified and fixed in the latest releases for Moodle 3.2.2, 3.1.5, 3.0.9 and 2.7.19 (LTS). If your Moodle site is not one of this versions, be forewarned to update now.
As Rubin explains, the core of the exploit is on the AJAX technology, broadly used by modern websites to update information without having to refresh the whole page.
When developers create new functionality for Moodle that uses AJAX, they must register it as an “external function”. This creates a gateway that controls and limits the changes that can be made on the Moodle site and its database.
The problem began when the gateway increased the ability to change user attributes. Rubin believes that when developers first allowed AJAX to edit user data and preferences, they thought this would not include the ability to change users permissions. But this was not considered by the developers who worked on the Course Overview Block, which shows all the courses a user is enrolled and their respective roles. A function in the Block, that shows you the list of roles for a user, asks for a sorting preference. But when you provide no preference and leave the space empty, the function resorts to use “legacy code”. The gap between the new and old code, Rubin points out, allows for “Object Injection”, which can significantly alter the capability of the function, beyond what was initially expected.
This is, in Rubin’s eyes, the core of the vulnerability: assumptions about how the code is supposed to be used. “Different developers, at different times, with different needs in mind write different code for the exact same functionality“. Moodle HQ puts a lot of effort preventing these kinds of security gaps, rigorously filtering the things external functions can ask for.
Rubin admits that exploiting this flaw is very complicated, and even if someone could do it to impersonate the site’s credentials and users, they would still find many limitations. But Rubin’s posts shows how, by having some familiarity with the site and acting with caution, anyone could gain privileges to execute code with plenty of freedom from the server that hosts the Moodle site.
Ultimately, Rubin attributes this vulnerability to “having too much code, too many developers and lacking documentation“, causing fissures that tend to go unnoticed. This is an ongoing security concern for any large code base with lots of contributors. It is by no means exclusive to Moodle.
If your Moodle site is not 3.2.2, 3.1.5, 3.0.9 or 2.7.19 (LTS), you should perform an update immediately.