The road to glory, from XSS to Root on apache.org

On the 9th of April 2010, Apache.org infrastructure suffered a direct and targeted attack on the server hosting the Apache issue-tracking software, Atlassian JIRA.  This is the second major compromise the Apache Software Foundation suffered in less than a year, when last August, the main Apache Foundation website was also hacked.

The attackers crafted an attack by exploiting a cross-site scripting vulnerability in JIRA software via a TinyURL redirect.  Thanks to this attack, the attackers managed to gain root access to brutus.apache.org, the server hosting Atlassian JIRA, Bugzilla and Confluence software.  By gaining root access to brutus.apache.org, the attackers managed to get a hashed copy of the user passwords of JIRA, Bugzilla and Confluence.

The attack

The attackers first submitted a new issue in JIRA (issue code INFRA-2591), which contained the following message;

“I’ve got this error while browsing some projects in jira http://tinyurl.com/ybnf8xt”

Upon receiving such message, a number of administrators from the infrastructure team clicked on the link.  By clicking on the link, their sessions were compromised; by exploiting a cross-site scripting vulnerability in Atlassian JIRA.  Meanwhile, the attackers also launched a brute force attack against JIRA login.jsp.

Thanks to the above attacks, the attackers managed to gain administrator privileges on JIRA, where the attackers immediately changed the path used to store uploaded attachments.  The path they configured allowed the execution of JSP files, where JIRA users could also write to this location.  The attackers later created several new issues, and uploaded a number of attachments to them, which contained a JSP file that browses and copies the file system of the victim once he accesses such JSP attachment.  Therefore the attackers also gained copies of many users’ home directories, and other various files.  They also uploaded other JSP files that gave them backdoor access to the system using the account JIRA software runs under.

Therefore the next step was for the attackers to try and gain root access to burtus.apache.org.  Therefore they sent password reset mails from JIRA to members of the Apache infrastructure team.  Thinking that JIRA encountered a bug, members of the infrastructure team followed the steps to change their temporary password back to their usual passwords.

One of the reset passwords was the same of a local user account on the brutus.apache.org machine, which also had full sudo access.  At this stage, the attackers gained full root access, with which they were able to get a hashed copy of all the passwords of JIRA, Confluence and Bugzilla software.

The attackers also found out that several users had cached Subversion credentials, which were used to login to minotour.apache.org, Apache Foundation’s main shell server.  At least the attackers were unable to escalate privileges with the compromised accounts on minotour.apache.org.  Once they started resetting passwords, the attackers also started to shut down some services.

The aftermaths and what we have learnt

Unfortunately, many people still think that a cross-site scripting vulnerability is not a dangerous vulnerability.  Though from the above attack, one can see how from a simple xss vulnerability, a group of attackers can craft an attack and gain access to a whole server infrastructure.
Apart from causing downtime and problems, this attack resulted in a lot of work for the Apache Foundation team, to move operations from one server to another.

Thanks to the Apache Software Foundation members who shared all the above information, one could also learn a number of lessons.

• Using one-time strong passwords, could be a real life saver.  If the attacker manages to put his hands on a hashed copy of passwords, the stronger the passwords are the more difficult it would be for the attacker to extract the password.  Dictionary words passwords will be the first passwords to be extracted.  One can also notice that sharing the same passwords between different systems, is never a good idea.
• Service isolation can also help in such attacks.  The more services running on a single machine, the more opportunities for an attacker to spread his damage.  By isolating services, the attacker can only gain access to the vulnerable service.

Read more about Apache Security

THE AUTHOR

Acunetix

Acunetix developers and tech agents regularly contribute to the blog. All the Acunetix developers come with years of experience in the web security sphere.