This time another targeted attack against the site was successful and allowed the attackers to capture the passwords of users logging into the bug-tracking service. It also exposed the entire password list, which sadly although hashed was salted with a static salt rather than a random one..so it’s vulnerable to brute-forcing.
I’d say a good set of Rainbow Tables would make short work of it.
Hackers penetrated the heavily-fortified servers for Apache.org in a “direct, targeted attack” that captured the passwords of anyone who used the website’s bug-tracking service over a three-day span last week.
The breach, the second to hit Apache.org in eight months, also exposed a much larger list of passwords belonging to people who accessed the site’s bug-tracking section. While the databases used a one-way hash to disguise the passwords, two of the lists are vulnerable to dictionary attacks because Atlassian, the maker of issue-tracking software used by Apache, failed to add “random salt” to them.
As a result, Apache officials said users who logged in to the bug section of the website from April 6 to April 9 “should consider the password as compromised, because the attackers changed the login form to log them.” They also warned that there’s a high risk of compromise to other users if they employed simple passwords based on dictionary words.
If you are a user of Apache.org and the bug tracker in particular and you logged in between April 6th and April 9th, you should consider your password comprised. That means change your password and if you use the same password anywhere else, change those too.
Personally if I had a login there I’d change my password regardless, because given enough time and processing power most of the hashed passwords can be cracked.
I think Apache.org should mandate a forceful password change for all accounts in the system for security reasons, I don’t think anyone would complain.
The intrusion began on April 5 when unknown attackers using a hacked server from Slicehost opened a new bug report on Apache.org. The post contained a shortened web link from tinyurl.com that exploited an XSS, or cross-site scripting, vulnerability on Apache’s support website.
The hole was the result of a bug in JIRA, the issue-tracking software made by a company called Atlassian. The exploit was designed to steal session cookies used to authenticate people logged in to Apache’s JIRA system. When several Apache administrators following the fraudulent bug report clicked on the on the malicious link, their JIRA administrator rights were then compromised.
The attackers also carried out a brute-force attack that flooded the site with hundreds of thousands of password combinations. By April 6, one of the two methods allowed the attackers to gain full administrative rights on the JIRA system. For three days, the hackers used their powers to copy users’ home directories and files and to install a program that logged the passwords of anyone accessing the system.
The initial attack vector was an XSS against the admins of the bug-tracking software which enabled the attackers to compromise their accounts and get further access to the system.
The full postmortem from the Apache team is here:
The same virtual host also attacked Atlassian directly and comprised their customer accounts.
Source: The Register
- The Logjam Attack – ANOTHER Critical TLS Weakness
- WordPress Critical Zero-Day Vulnerability Fixed In A Hurry
- Commix – Command Injection Attack Tool
- Apache.org Hacked Using Remote SSH Key
- gotroot modsecurity Rules for Apache – Anti-spam and Security
- ISIC – IP Stack Integrity & Stability Checker
Most Read in Exploits/Vulnerabilities:
- Learn to use Metasploit – Tutorials, Docs & Videos - 230,662 views
- AJAX: Is your application secure enough? - 119,543 views
- eEye Launches 0-Day Exploit Tracker - 85,229 views