Apache.org hacked, Atlassian Fail

April 13, 2010

Today’s big news- several Apache.org web applications were compromised due to a piddly little XSS hole. The writeup on the Apache blog is phenomenal, so I recommend you read that, but the short version is this:

An attacker found an XSS hole in JIRA, a bug tracking application sold by Atlassian. He sent the malicious link to several administrators via the application itself, and they clicked it. (Kind of sloppy, if you ask me- embed the malicious link in an innocent looking page, and the admins may never realize they got compromised). At that point, the attacker modified a file upload directory and placed a few JSP scripts on the server, giving him a web shell and eventually, root access via sudo.

From there, he modified code to steal sessions of active users, dumped password databases, and performed password reset attacks to collect more credentials, eventually giving him what he needed to access other Apache servers. All in all, this is pretty bad, but huge props go out to them for their transparency. The attacker then mounted a similar attack on Atlassian’s own systems, which were in turn compromised.

Unfortunately, this attack was not at all surprising. If I may allow personal experience to color this post, I’ve reported vulnerabilities to Atlassian in JIRA and other applications in the past, and it’s always ended in disappointment. A few examples:

First off, you may recall me mentioning JIRA when I was discussing uploading Flash files to servers last fall. One can disguise a Flash file as a ZIP archive and upload it to the affected server, allowing an attacker to execute Actionscript in the context of the server. I reported this vulnerability to Atlassian at the time, and rather than fix the issue, or at least publish an advisory about it, they sent me instructions on disabling the file upload feature for my installation. Hardly useful. When I report things like this to a vendor, it’s not because I’m worried about it compromising my servers- I’m worried about all the other unaware users of the application.

That’s bad enough, really; It was a simple XSS hole that caused the Apache breach, but that isn’t even the first of the issues I’d found.

Let’s look at another example; a combination of several seemingly unimportant bugs. I used this exact exploit in a penetration test 6 months ago, and while it uses none of the same issues as the Apache.org attack, you’ll notice that the methods and results are eerily similar.

1) Administrator and user functionality throughout JIRA is vulnerable to CSRF. If you still don’t think CSRF is a critical bug, keep reading.

2) One administrator function is the ability to create XML-formatted backups of the database. Those backups can be stored in an arbitrary location, including the web root, and with an arbitrary filename, including JSP. (Atlassian’s response: “You’d have to be a JIRA administrator to do this”).

3) Other poorly-validated form fields exist throughout the application.

Whether it’s because they don’t understand the issues, don’t appreciate them, or don’t care about them, Atlassian’s support people have been generally dismissive of my bug reports. The issues I sent in (JSP-47415, JSP-55831, JSP-55834, and JSP-55835, though nobody but me and JIRA support can see them) have been closed, marked as “duplicate” to unrelated issues, or disregarded saying that an upgrade to the current version will fix them (it does not). To demonstrate a working 0-day (okay, not exactly, these were all first reported months ago), let’s embed a bit of JSP code in one of those poorly-validated form fields, setting our profile’s email preferences to:

It stores that code in the database. Harmless, right? Now, what happens when an administrator is tricked into visiting the following link?

https://jiraapp/secure/admin/XmlBackup.jspa?filename=..%2Fatlassian-jira%2Fshell.jsp&useZip=false&saxParser=&confirm=true&Replace+File=Replace+File

You’re welcome to stand up a demo copy of the application and try it yourself, but here’s the spoiler: It’ll create a backup of your database, saved with a .jsp extension, and executable by the webserver. If stealing your password hashes and other data wasn’t bad enough (it is a publicly accessible backup of the database, after all), the embedded JSP code also gives the attacker the ability to run arbitrary shell commands. Awesome.

Compare that to the attack that hit Apache.org, and it’s not hard to see the similarities. These aren’t the only such bugs in the application, and these ones aren’t being fixed. Apache’s bugs only got fixed after they were used to attack Atlassian themselves. In my mind, you don’t get any credit for dealing with bugs after an attack, when you’ve left multiple equally critical ones open for almost six months. This is the kind of thing that frustratessecurity researchers. Again, the privilege-escalation-to-shell-command issue used in the attack on Atlassian has been patched, despite the fact that, like the XML backup bug, “You’d have to be a JIRA administrator to do this.”

While I have very little respect for Atlassian, the sad truth is that we in the web security world have been preaching the severity of XSS, CSRF and other “unimportant” issues for years. Because those attacks leave very little evidence behind, and because very few breached organizations ever disclose the details of those events, we don’t actually see them used in the wild that often, but cases like the Apache.org incident are clear examples that the attackers know about these attacks, and they are using them.

Just because we don’t see it, doesn’t mean it doesn’t happen.

Comments

-->

• Login

  Login:
  
  Password:
  
  Remember me
  
  
  Not a member yet?
  Sign Up Now!

• Blogroll

  • MAD Security