SANS ISC: Apache.org Bugtracker Breach - SANS Internet Storm Center

• SANS Site Network
  • Current Site
  • Internet Storm Center
  • Other SANS Sites Help
  • Graduate Degree Programs
  • Security Training
  • Security Certification
  • Security Awareness Training
  • Penetration Testing
  • Industrial Control Systems
  • Cyber Defense Foundations
  • DFIR
  • Software Security
  • Government OnSite Training

SANS ISC InfoSec Forums

A few readers pointed us to an announcement by the Apache Foundation about a breach of their bugtracking software.

First of all: Kudos to Apache for publishing a nice and detailed incident report [1]. The attack included a number of elements that in itself are frequently ignored, but if combined in an attack like this one, turn out to be deadly.

Reading the blog post, a cross site scripting attack or simple password brute forcing was used to compromise the attack. While either attack appears to have the potential to succeed, it is not clear which one was finally used to gain access.

The cross site scripting attack used an additional twist in hiding the malicious URL via tinyurl.com. This made it more likely that an administrator would actually click on the URL.

Once the bug tracking system was compromised, the attacker modified it to log passwords. An administrator happened to use the same password to log in to the bug tracker as they use on the system itself.

Lets skip to the lessons learned:

• While it is not clear if the XSS attack was successful, it is important to note that attacks like this happen and can work. A simple mitigation would be to use the "httponly" option for session cookies. This way, session cookies can not be stolen via injected Javascript. It doesn't fix the XSS vulnerability, but it makes exploiting it harder.
• It is important to mitigate against brute forcing attacks. This mitigation should include two parts: (1) detection of brute force attacks and an automatic lock out mechanism. (2) a strong password policy backed up by password audits (to avoid "strong" passwords like password1! that may satisfy the policy but are still easily guessed.
• Don't forget the ability to quickly un-lock accounts to avoid a brute force attack turning into a DoS attack.
• Shared passwords are bad. Really bad. I actually recommend that people use some form of "password safe" software or write them down (yes... flame me for it. But I currently list 540 strong passwords). In the past I recommended different types of passwords for different purposes. But I found that sometimes a password starts out as "unimportant" and later becomes "important".

See the full blog post for more details and more lessons learned.

[1] https://blogs.apache.org/infra/entry/apache_org_04_09_2010

------
Johannes B. Ullrich, Ph.D.
SANS Technology Institute
Twitter