Dangerous Vulnerability Found In Moodle 3.6.3, Earlier Versions Potentially Affected, Issue Not Yet Fix

Source: https://www.lmspulse.com/2019/dangerous-vulnerability-found-in-moodle-3-6-3-earlier-versions-potentially-affected-issue-not-yet-fix/

Dangerous-Vulnerability-Found-In-Moodle-3.6.3-Earlier-Versions-Potentially-Affected-Issue-Not-Yet-Fix-696x392

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.

LMSPulse@lmspulse

URGENT: Review the Admin roles in your site ASAP ? CVE-2019-11631 High Severity vulnerability found

Özkan Mustafa Akkuş@ehakkus

(CVE-2019-11631) In Moodle 3.6.3 and in prior versions, the plugin installation area can be manipulated and the #command can be executed on the server. You must have an admin account to #exploit this #vulnerability. ?(EDB-ID:46775) https://www.exploit-db.com/exploits/46775 

Embedded video

See LMSPulse’s other Tweets

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.

Dangerous 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.

No solution available yet. Review admin role access immediately

As a solution has not been made widely available, Moodle site admins are urged to review the trustworthiness of user with admin roles, and withdraw access in case of doubt for the time being.

The difficulty of providing a fix, and therefore an ETA on a bug patch, is unclear at the moment.

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.

At the time of writing, Moodle had not provided any official updates.

Leave a Reply

Your email address will not be published. Required fields are marked *