eWEEK content and product recommendations are editorially independent. We may make money when you click on links to our partners. Learn More.
Hackers launched a multistage, targeted attack against the Apache Software Foundation’s infrastructure April 5 that compromised user passwords.
According to the foundation, the hackers took advantage of an XSS (cross-site scripting) vulnerability using a shortened URL to target the server hosting issue-tracking software for the open-source group’s projects. The foundation uses a donated instance of Atlassian JIRA to track issues and requests, and hosted the instance on brutus.apache.org, running Ubuntu Linux 8.04 LTS.
“If you are a user of the Apache-hosted JIRA, Bugzilla or Confluence, a hashed copy of your password has been compromised,” the foundation said in an April 13 statement on the Apache Infrastructure Team blog. “JIRA and Confluence both use a SHA-512 hash, but without a random salt. We believe the risk to simple passwords based on dictionary words is quite high, and most users should rotate their passwords.”
The statement continued, “Bugzilla uses [an] SHA-256, including a random salt. The risk for most users is low to moderate, since prebuilt password dictionaries are not effective, but we recommend [that] users should still remove these passwords from use.
“In addition, if you logged into the Apache JIRA instance between April 6 and April 9, you should consider the password [to be] compromised because the attackers changed the log-in form to log them.”
Apache officials posted a detailed account of the atack here. According to their investigation, attackers opened a new issue April 5 via a compromised Slicehost server. The issue contained a shortened URL “redirected back to the Apache instance of JIRA, at a special URL containing a cross-site scripting (XSS) attack crafted to steal the session cookie from the user logged in to JIRA. … Several of our administrators clicked on the link. This compromised their sessions, including their JIRA administrator rights.”
The post continued:
““At the same time as the XSS attack, the attackers started a brute-force attack against the JIRA login.jsp, attempting hundreds of thousands of password combinations.On April 6, one of these methods was successful. Having gained administrator privileges on a JIRA account, the attackers used this account to disable notifications for a project and to change the path used to upload attachments. The path they chose was configured to run JSP files, and was writable by the JIRA user. They then created several new issues and uploaded attachments to them. One of these attachments was a JSP file that was used to browse and copy the filesystem. The attackers used this access to create copies of many users’ home directories and various files. They also uploaded other JSP files that gave them backdoor access to the system using the account that JIRA runs under.By the morning of April 9th, the attackers had installed a JAR file to collect all passwords on login and save them. They then sent password reset e-notifications from JIRA to members of the Apache Infrastructure team. These team members, thinking that JIRA had encountered an innocent bug, logged in using the temporary password sent in the mail, then changed the passwords on their accounts back to their usual passwords.One of these passwords happened to be the same as the password to a local user account on brutus.apache.org, and this local user account had full sudo access. The attackers were thereby able to log in to brutus.apache.org, and gain full root access to the machine. This machine hosted the Apache installs of JIRA, Confluence, and Bugzilla.”“
With root access in hand, “the attackers found that several users had cached Subversion authentication credentials and used these passwords to log in to minotaur.apache.org (aka people.apache.org), our main shell server,” the group said. However, the attackers “were unable to escalate privileges with the compromised accounts.”
The post continued, “About 6 hours after they started resetting passwords, we noticed the attackers and began shutting down services. We notified Atlassian of the previously unreported XSS attack in JIRA and contacted Slicehost. Atlassian was responsive. Unfortunately, Slicehost did nothing, and two days later the very same virtual host (slice) attacked Atlassian directly.
“We started moving services to a different machine, thor.apache.org. The attackers had root access on brutus.apache.org for several hours, and we could no longer trust the operating system on the original machine.
“By April 10th, JIRA and Bugzilla were back online. On April 13, Atlassian provided a patch for JIRA to prevent the XSS attack,” the group said. Apache’s Confluence wiki is still offline, but the group said it is “working to restore it.”
The foundation said it has taken a number of steps to address the security issues exposed in the attack, including disabling caching of Subversion passwords and mandating one-time passwords for super-users on all Linux and FreeBSD hosts.