XSS to Root in Apache Jira Incident
In this blog post we explain how malicious hackers hacked into the Apache Foundation web servers and gained root access. They started by exploiting a cross-site scripting vulnerability in a web application called Jira. We scanned Jira with Netsparker and detected all of the vulnerabilities the malicious hackers exploited and more. This incident should serve as an example to all corporations to use Netsparker Web Application Security Scanner to identify and close down web application vulnerabilities.
The Apache Foundation infrastructure (apache.org) was a victim of a targeted attack for the second time this year. By exploiting a cross-site scripting vulnerability in a commercial bug tracking system called Jira, and using some social engineering skills, the attackers were able to gain access to several core servers of the Apache foundation.
The Apache Foundation & JIRA hacking Attack Details
Exploiting a XSS on Jira
Attackers knew of the cross-site scripting vulnerability in Jira, a commercial bug tracking system used by the Apache foundation. To exploit this vulnerability, the attackers posted a new issue on JIRA;
"I've got this error while browsing some projects in jira http://tinyurl.com/ybnf8xt"
This message triggered the interest of Apache.org members, some of which were administrators. Upon clicking on this link, the cross-site scripting vulnerability was exploited and the members' sessions were compromised.
At this stage the attackers managed to gain administrator privileges on JIRA. Posing as administrators, the attackers changed the location of where JIRA stored uploaded files to a location where they could store and execute JSP files. They created a number of issues through JIRA which contained several malicious JSP files. Some of these JSP files were used to browse and copy the file system of the victim who accessed the file, and some others gave them backdoor access.
Social Engineering Attack Helps Hackers Gain Root Access on Apache.org
Once the attackers had admin access to JIRA, they installed a tool that would collect all passwords and logins. They then sent JIRA password reset notification to the Apache infrastructure team. The victims thought it was some bug in JIRA, so they followed the instructions to reset their passwords to the original ones.
One of these passwords was the same as the password to a local user account on an apache.org server where hosted installs of JIRA, Confluence and Bugzilla were installed. To make things worse, this account had full sudo access on the machine brutus.apache.org.
The attackers took advantage of the root access and started looking around for sensitive data. They found out that several users had cached Subversion authentication credentials and used these credentials to login to the apache.org main shell server; jackpot!
Atlassian JIRA Attacked
2 days after the Apache.org & JIRA attack, Atlassian JIRA servers were also attacked, presumably the same hacker exploiting the same vulnerability. JIRA announced this in a blog post on the 13th of April 2010. The blog post stated "The breach potentially exposed passwords for customers who purchased Atlassian products before July 2008."
Netsparker Identifies XSS Vulnerabilities in JIRA
After hearing the news, our engineers downloaded the latest demo of JIRA and scanned it with Netsparker web application security scanner. Much to everyone's surprise, Netsparker identified 10 different instances of cross-site scripting vulnerabilities in the latest version of JIRA.
Use Netsparker throughout Each Stage of the SDLC
If JIRA used Netsparker throughout the software development life cycle, such hack attacks would have been avoided. It took weeks for Apache to recover from such attack; the attackers had root access to the servers and they had to move everything to new servers rather than fixing the old ones.