From XSS to root: Lessons Learned From a Security Breach

In an excellent blog, the people from Apache did a very good job analyzing and documenting how a security breach happened–going through all the stages of the attack and drawing conclusions. Should you ever become the unfortunate victim of an attack, this blog offers an example of how to document it!

I quote:”If you are a user of the Apache-hosted JIRA, Bugzilla, or Confluence, a hashed copy of your password has been compromised.” So if you are a user, please act accordingly after reading this blog ­čśë

But let’s take a look at the early stages of the attack; I feel there are some important conclusions missing:

Apache reports two simultaneous attacks that were launched. A brute-force attack against the JIRA login and an attempt to exploit a (previously unknown) cross-site scripting attack. They later say that just one of the attacks was successful, but not which one. From their blog:

The attackers via a compromised Slicehost server opened a new issue, INFRA-2591. This issue contained the following text:

ive got this error while browsing some projects in jira [obscured]

Tinyurl is a URL redirection and shortening tool. This specific URL redirected back to the Apache instance of JIRA, at a special URL containing a cross-site scripting (XSS) attack. The attack was crafted to steal the session cookie from the user logged-in to JIRA. When this issue was opened against the Infrastructure team, several of our administrators clicked on the link. This compromised their sessions, including their JIRA administrator rights.

So administrators–knowledgeable and security-minded users–with elevated privileges opened an unverified├é┬álink that was supplied by an external (anonymous?) source. And worse: The link was clearly obfuscated. This is where all technical security measures fail. Users worldwide are told again and again to be very careful with links in email and social networks, especially when they come from an untrusted source. Well, the fact that Koobface is alive and spreading makes it obvious that users still are too happy to click on any link they get. That experienced administrators fall for this makes the future look gloomy indeed. ­čÖü

And another word about the URL obfuscators: A link shortened with tinyurl is one of very few that I would open, simply because it has got a preview feature you can enable, showing you the actual link before it takes you there. If at least one of the targeted users in this incident would have enabled that feature, the XSS attack would have become obvious and would have been discovered immediately.

So folks, please enable such functionality before you fall victim to an attack through obfuscated links, and stay clear of unknown URL shorteners or those without a preview feature.

2 comments on “From XSS to root: Lessons Learned From a Security Breach

  • Surely an attacker could offer a link to any page that they have control over, and have that page redirect to the XSS’d page. Given the number of vulnerable web applications around, the only ‘safe’ course of action would be to not visit any websites that you haven’t already visited – which is clearly impractical.

  • It is very interesting to see how everyone is *now* concerned with these short links, especially after the got hacked because of a short link,

    When TinyURL, and all the other >500 followers, started to offer shortening services, all the people began to use short URLs like crazy. I think that Twitter played its role, though. Wouldn’t it be better to prevent all this to happen by analyzing short links before the bad guys started to exploit them?

    However, I have noticed that one effort is being made along this direction: besides it’s own shortening service, the guys at seem to offer a simple analyzer that goes a little deeper than “previewing”.


Leave a Comment

five + nine =