The Apache Software Foundation reports that it was hit earlier in April by a sophisticated attack that compromised user passwords.
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
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
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
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
"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
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