In a recent penetration test of a Moodle instance, a review of the installed plugins revealed several security issues in a plugin that has not been updated for several years.
The Jmol/JSmol plugin for the Moodle Learning Management System displays chemical structures in Moodle using Java and JavaScript. The plugin implements a PHP server-side proxy in order to load third party resources bypassing client-side security restrictions. This PHP proxy script calls the function file_get_contents() on unvalidated user input.
This makes Moodle instances with this plugin installed vulnerable to directory traversal and server-side request forgery in the default PHP setup, and if PHP’s “expect” wrapper is enabled, also to remote code execution. Other parameters in the plugin are also vulnerable to reflected cross-site scripting. Note that authentication is not required to exploit these vulnerabilities.
The JSmol Moodle plugin was forked from the JSmol project, where the directory traversal and server-side request forgery vulnerability was partially fixed in 2015.
This issue is tracked at https://tracker.moodle.org/browse/CONTRIB-7516.
Proof of Concept
Directory Traversal
Accessing the following link reads a file from the Moodle server’s file system, in this case the Moodle configuration file with database credentials.
Any file the web server process has access to is readable by an attacker. The accessed files are not included in PHP code, so an attacker will not be able to execute their own code on the server through this vulnerability alone. Access to the server’s file system may however enable an attacker to gain access elsewhere.
Reflected Cross-Site Scripting
Accessing the following link runs JavaScript code in the context of the victim’s browser.
Malware Distribution
The following link contains a Base64-encoded file, which the server decodes and provides to the victim when the link is accessed.
Recommendation
Uninstall the plugin from Moodle’s Site Administration interface. Ensure that the uninstallation also removes the directory from the web server’s file system (such as /var/www/moodle/filter/jmol). Using Moodle’s “Disable plugin” action does not disable the vulnerable PHP scripts, as it only removes the functionality of the plugin from the Moodle interface, but the standalone PHP scripts continue to be accessible on the web server, thus can still be exploited.
Using third party components forked from other projects carries a higher risk the further the development goes from the upstream project. In addition to following the security advisories of each installed component, also follow those of the upstream projects in case their fixes are not applied to the forks in a timely manner.