So, a fresh year of college is about to kick off! Our college, like many others, have installed the latest version of moodle for the new year. I have found a pretty severe xss on the latest moodle version, these bugs can and do result in a complete account takeover. This bug effects moodle versions prior to 2.3.9, 2.4.6, 2.5.1 (patches released September the 9th). Edit: There is also a RCE Exploit Developed afterwards by Rapid7 that leveraged this XSS.
I'm going to demonstrate how I can take over a moodle site by chaining this "minor" vulnerability together with other items such as CSRF. It is of course more than possible to escalate privileges to that of a lecturer or admin and also possible to spread an xss worm, I know this based on previous research I did with moodle for my 3rd year project demo. I currently do not have the time it would take to install moodle and test if this is the case.
This time I'd like to do a much more technical proof of concept as my last moodle-takeover post wasn't really that detailed or technical. For the chain of attack, Everything begins with this blog post.
How? All will become clearer if you view this blog post via the RSS feed. You may notice that this particular post has the following line. javascript:MALICIOUS JAVASCRIPT(); You can probably immediately see where this is going.
In moodle there is an option to include a remote RSS feed or blog. As you can probably expect, clicking the "Link to original blog entry" hyperlink results in a very typical prompt box demo containing the domain name of the current site. The attacker now has access to any DOM values within this domain. Luckily for this attacker, These DOM values include the users current moodle session key. This doesn't change once the user logs in, likewise the user's ID doesn't change. We can now run any CSRF attack we want with these values.
What happens if we change this link value to javascript:alert("Session key = "+M.cfg.sesskey+ " User ID = "+window.location.search.split("=")[1]); Now we can see the users session key and user ID are easily accessible from the DOM. These values can then be used to fill in fake forms and submit them as our unsuspecting user. Which will of course lead me on to the second step of our attack, we can send this blog post to an admin, inject javascript into the moodle home/login page, this will be executed every time they log in or access there home page. Now we can steal any users login information. Below you will see both a regular user and an admin users session/id information.
The CSRF form looks like the following...
1">
We will do this by adding malicious html to the moodle welcome page using something similar to the csrf form above. This is also where users login when they first visit the site. This can be submitted to /course/editsection.php. The id parameter in red is usually between 1-3, here we can then use our malicious javascript to steal any user logins by changing where the login form elements are sent or anything else that is malicious/similar. Maybe force every unaware moodle user to install a new plugin? From here the ability to cause havoc is greatly weighed in the malicious attackers favour.
Just for demonstrative purposes you will see an example of the new login window below. Would you try login or download the "Update". Of course this could be done in a much stealthier way, and the popup is just an example that an attackers javascript now runs on the login page. I wonder if they'd make it as obvious...
I reported this bug to moodle, you can find the thread/fix here https://tracker.moodle.org/browse/MDL-41623. (This requires a password to view). <3 XSS. This bug was given the following CVE-2013-4341