Updated on May 17th, 2019. Currently the vulnerability has been deemed as “Rejected,” meaning it’s not really an issue. Read a response from Moodle HQ with details at the bottom.
On April 28th, a vulnerability affecting Moodle 3.6.3 was documented by ethical hacker from Turkey Özkan Mustafa, aka AKKUŞ on his Pentest Blog.
URGENT: Review the Admin roles in your #Moodle site ASAP 😱 CVE-2019-11631 High Severity vulnerability found https://t.co/P3Bohzz3e6
— LMSPulse #eLearnSuccess (@lmspulse) May 2, 2019
The exploit has been codified on the Common Vulnerabilities and Exposures (CVE) list with code CVE-2019-11631. The list and codes are maintained by certified security authorities from around the world and allow a trustworthy channel of interaction and exchange regarding vulnerabilities.
Vulnerability via unrestricted file upload
To exploit CVE-2019-11631, the actor must access a Moodle and be authenticated as an admin. Once inside the system, the actors would have to upload a ZIP package containing PHP code under a file with
name theme_*.php using an “install addon” feature in an AJAX repository.
By leading the system to believe a Moodle plugin is being uploaded manually, a common method by admins to install Moodle plugins, a dangerous file can be placed in Moodle structure that would be executed automatically.
The U.S. National Institute of Standards and Technology has classified the vulnerability as “Unrestricted Upload of File with Dangerous Type” (CWE-434) and rated it a 7.2 or “High” under the current Severity methodology (CVSS v3.0). It considers the complexity of the attack as low, and does not require user intervention. But the fact that it requires admin-level authentication leads to attain a high-level of “Priviledges Required (PR)” which could hinder its incidence. In most systems, the Log system could give a trail of users who decided to proceed with a malicious upload, assuming they don’t also use their admin roles to edit the logs.
According to MITRE, non-profit advocacy in fields related to IT and security funded by the U.S. government, vulnerabilities of the type CWE-434 usually originate at the “Architecture and Design” stage of the development lifecycle. The entry explains:
“This weakness is caused by missing a security tactic during the architecture and design phase“.
Upload-based attacks are especially common for server-side technologies such as ASP or PHP, Moodle being built under the latter language. These systems are prone to automate the execution of files without especifying permissions explicitly.
Review admin role access early and often
Moodle site admins are urged to review the trustworthiness of user with admin roles, and withdraw access in case of doubt.
From a security strategy perspective, MITRE recommends that systems should always assume an input is malicious and reject trust-based or “accept known good” forms of validation. Whitelist criteria for files that can be uploaded should be reviewed frequently and consider an encompassing number of properties. Sanity checks or MIME contenty type validation should be considered “partial solutions” at best.
Recommended solutions include internal file renaming, providing a fixed mapping of the system’s file, or more generally establishing checkpoints throughout the upload to root process.
Volunteers interested in understanding and addressing the vulnerability can find the full process at AKKUŞ’ blog. Find an alternative source at exploit-db.com.
Moodle HQ Response
On May 17th, Michael Hawkins, Moodle Security Officer, requested to include the following clarifications:
- The CVE-2019-11631 vulnerability has been rejected, as in it’s not actually a vulnerabilty.
- Moodle abides by security recommendations regarding admin roles. Across an organization, as few people as possible should have it, as it awards entire control of a Moodle site. Other users can use the Manager role, to be used whenever possible.
- Site administrators have the Security overview report tool which shows warnings in case of improper configuration and instances of risk. It also allows for auditing of user admin roles.
Our coverage on Core Software for LMS and Learning Systems is supported by Moonami, a company that provides a full range of Moodle services that combine the flexibility, scalability, and power of Amazon’s world-leading cloud platform (AWS) with fanatical Moodle support. Click here to learn more.
With all respect: If a person has access rights as admin you have other/bigger problems to care about. (or do you not trust your own admin??)
To expand on gers point, an admin is equivalent to root and can delete everything on a site by design. Marcus
An easy fix/workaround: disable plugin installation via the web UI and install all plugins via the command-line going forward.
This can be accomplished by removing write access to the moodle/ directory (either by changing filesystem permissions, or changing the ownership to a user other than the webserver’s uid). Just make sure not to change the moodledata/ directory’s permissions or ownership too – that still needs to be writeable by the webserver.
Relevant CommitStrip: http://www.commitstrip.com/en/2014/01/10/tu-sais-que-tes-un-vrai-codeur-quand/