As discussed in detail by the Apache infrastructure team, a cross-site scripting vulnerability in Atlassian's JIRA led to a full root account compromise on the ASF's issue and request tracking server. If you don't care to read the full story from the infrastructure team, the following sequence of events led to the compromise:
- Attackers opened a new JIRA issue with a malicious tinyurl.com link that led to the JIRA page with an XSS vulnerability
- Simultaneously, attackers launched a brute force attack on the JIRA login form
- Several administrators clicked the tinyurl link, which compromised their cookies (giving the attackers JIRA admin access)
- Attackers uploaded malicious a JAR file that collected JIRA passwords at login. One of the compromised passwords had also been used for a local account with full sudo privileges.
There's more to the story, but those points capture the bulk of the attack.
This compromise interests me because it's an explicit, targeted, successful attack against a security conscious and capable next-generation web technology team. Several techniques were used in this attack:
- Social engineering. The attackers opened an issue as if they were a trusted source posting a legitimate link. The Apache administrators trusted them.
- Web application security flaw. XSS is #2 on the OWASP top 10 list.
- Lack of vigilance. As the infrastructure team points out, the same password was used in a number of cases, and the JIRA user was overly privileged.
I hear a lot of grumbling when I highlight XSS vulnerabilities in a penetration testing report. "Is this really a serious problem?" and "we're not a target" and "it doesn't matter if they steal the cookie" are common complaints. Let's face it - if the Apache team can be powned, we should all be wary.
Comments
What indicators did the admin team at ASF discover that clued them in to the compromise? I would think that after such a well executed attack, the attackers would not just reveal that they have rooted the box.