From the Atlassian company blog:
Around 9pm U.S. PST Sunday evening, Atlassian detected a security breach on one of our internal systems. The breach potentially exposed passwords for customers who purchased Atlassian products before July 2008. During July 2008, we migrated our customer database into Atlassian Crowd, our identity management product, and all customer passwords were encrypted. However, the old database table was not taken offline or deleted, and it is this database table that we believe could have been exposed during the breach.
[…]
The impact
What’s affected?
If you have an Atlassian account from before July 2008 — you should definitely change your password with us. Also, if you used that username/password combination for any other site, we recommend you change it there as well to prevent people potentially gaining access to other systems.
What’s not affected?
- If you created your Atlassian account after July 2008, you should not be affected. We notified you via email because we feel it’s important every customer is aware of the situation.
- If you’re an Atlassian customer running our products behind the firewall, your passwords are not affected. By default, our products store the passwords for the userbase in an encrypted form.
- If you’re an Atlassian SaaS or hosted customer, your userbase and customer data are not affected. Those are stored in another system.
- No credit card or payment details were accessible.
[…]
Lessons we’ve learned today
Firstly, we made a big error. For this we are, of course, extremely sorry. The legacy customer database, with passwords stored in plain text, was a liability. Even though it wasn’t active, it should have been deleted. There’s no logical explanation for why it wasn’t, other than as we moved off one project, and on to the next one, we dropped the ball and screwed up.Secondly, in attempting to be as open as possible, we sent a communication to all customers — not just those affected — at once. Our intent was to keep everyone notified of the situation, but we appear to have done more to raise alarm with unaffected customers. Beyond that, with hundreds of thousands of accounts changing passwords simultaneously, our web servers crumpled — causing yet more user alarm. We apologise for the extra consternation this caused — our web servers are now back purring along as normal.
In hindsight, we should have reset passwords for affected users on their behalf. This would have avoided the unexpected transactional load on our web servers, and communicated the problem to the rest of our customers in a different way.
Hat-tip The Next Web.
Update 1: Bob McMillan reports:
Hackers broke into a server used by the Apache Software Foundation to keep track of software bugs.
The attack did not compromise the open-source Web server’s source code repository, but it did give hackers access to a server used by the project to keep track of bugs, and they also obtained low-privilege accounts on another server used to maintain the people.apache.org Web site, according to Philip Gollucci, vice president of Apache infrastructure. “None of the source code was affected in any way,” he said.
By taking advantage of a common Web programming error known as a cross-site scripting bug, and then using another password-guessing attack, hackers were able to break into the Atlassian JIRA software used by Apache. They then installed a password stealing program on that software, ultimately seizing full control of the machine. That gave them access to two other programs hosted by Apache on the same server, the Confluence wiki program and Bugzilla.