Get a signed plain text version of this advisory.
Monday, April 19, 2010
===============
jira.jboss.org security incident notification
- -----------------------------------------------------------------
Our jboss.org community infrastructure was recently the target of a cyber attack.
The incident was related only to jboss.org infrastructure and does not affect JBoss
Enterprise software product offerings.
The focus of this attack was jira.jboss.org, a machine which runs a free
Atlassian JIRA instance used for tracking of issues with various jboss.org
related projects. The attack was consistent with other recent high profile
attacks:
https://blogs.apache.org/infra/entry/apache_org_04_09_2010
http://blogs.atlassian.com/news/2010/04/oh_man_what_a_day_an_update_on_our_security_breach.html
http://in.relation.to/Bloggers/HibernateJIRACompromised
We believe the jboss.org JIRA instance was compromised via a previously
unknown cross-site scripting (XSS) attack. This attack eventually allowed
administrative access to the JIRA instance on April 11th, 2010, and subsequently
user credentials from a backend database, containing passwords hashed without a
random salt.
Just as in the recent attacks on Apache.org and Atlassian.com's sites, the
attack against the jboss.org infrastructure originated from Slicehost and
shares similar traits and tactics.
What does this mean?
- ---------------------------------
If you are a user of jboss.org services which require a login, your account
credentials may have been compromised as a result of this attack.
We strongly advise users of our services to maintain different passwords for
any other services and applications they may consume. In the event that you
may have used the same password on a system in addition to the jboss.org
related machines, we recommend that you change those passwords immediately.
We also note that JBoss Enterprise software product offerings were not impacted by this
attack.
What steps have been taken to address the issue?
- ---------------------------------------------------------------------------
We have taken a number of actions to help address and improve the security of
of our offering to the jboss.org community.
* Shortly after Altassian provided a patch for the XSS attack against JIRA,
our system administrators applied the patches to our systems.
* Our system administrators began an audit of these systems after the public
disclosures of Apache.org and Atlassian.com's recent attacks. Initial
investigation did not reveal any indications of a compromise, and we posted
these findings on the jboss.org community site on April 16, 2010.
Upon closer examination and application of a second round of patches we discovered
there had been an intrusion on the JIRA application, however, circumstances of the
attack differed slightly from previous disclosures, and left different signatures. This
discovery was made on Saturday, April 17th.
* We have quarantined the jboss.org Subversion repositories in order to
conduct an audit and help ensure their integrity before we make them
available again. We're also checking other jboss.org systems to make sure their
data has not been compromised. Our investigation to date does not show any
unintentional changes.
* We have also forced lockout on credentials that we believe may have been at
risk, and have notified the owners of those accounts as to the possible
compromise of the account information.
* We are investigating additional controls around the authentication mechanism
of this system, and will look to improve the application's security and
tolerance to attacks.
* Strong system level security, including the use of SELinux in enforcing
mode, helped ensure the integrity of the underlying OS. Detailed logging
helped track and recreate the attack.
We published this announcement so that our community members may learn from
our experiences managing through this event and will examine their own JIRA instances
accordingly to ensure that they are better protected and secured as well.
Atlassian's recent update may be of value to our users, in helping to ensure
their own JIRA instance integrity:
Comments