Apache.org and Attack Soup

This morning, a <a href="http://isc.sans.org/diary.html?storyid=8623">story</a> from the Internet Storm Center caught my eye. The piece, about an attack launched against the <a href="http://en.wikipedia.org/wiki/Bug_tracking_system">bug tracking system</a> used by <a href="http://apache.org/">Apache.org</a>, was pretty technical, so I asked Johannes Ullrich, chief research officer for SANS, to break it down.

This morning, a story from the Internet Storm Center caught my eye. The piece, about an attack launched against the bug tracking system used by Apache.org, was pretty technical, so I asked Johannes Ullrich, chief research officer for SANS, to break it down.

Turns out there were two attacks, and it's not clear which one worked. The first attack was a cross-site scripting attack, a type of computer security vulnerability found in Web applications, most commonly Web browsers. An attacker actually injects client-side script into the browser of a trusted site capable of taking over the browsers of those who surf to the site. In this case, the attacker filed a bug report and included a 'tinyurl' as part of it. Tinyurls can be dangerous because it doesn't allow the end user to see where the link is going. Usually someone can identity a suspicious URL by its content, but not in this case. The attack waited for an administrator to log in and click on the malicious URL, which triggered the cross-site scripting flaw, according to Apache.

From there, the cross-site scripting flaw was used to steal the administrator's session cookies. These session cookies identify the user to the Web site. It turns out the attacker can actually log in as an administrator without a password using just the session cookies - a lot of damage for essentially clicking on a bad link.

The second possible attack is thought to be password brute forcing. This is exactly what it sounds like. An attacker attempts to guess a password until it gets lucky. Either attack can result in the same outcome--administrator privileges of the bug tracking system. But as it turned out, one of the administrators logged in using the same password for both the bug tracking system and a server used by an Apache.org project. The attacker was then able to use the same credentials to log in to the server and steal Apache's complete password database, though I'm told it was encrypted.

What's most interesting is how different vulnerabilities got used together, Ullrich said. An analogy that comes to mind is how you can use a number of different ingredients to make a good chicken soup, but the central ingredient, chicken, always stays the same.

"This particular case is interesting in that it shows how several minor security failures can cooperate to lead to a major breach," he added.

It also should be noted that Apache.org released a thorough incident report, not a common practice because organizations like to be discreet about how they fix security vulnerabilities.

"In some cases, the root cause has not been eliminated and disclosing too much detail could lead to another breach," Ullrich said. "Apache on the other hand fixed the problem, and by disclosing details allows others to learn how to prevent similar exploits in the future."