Even for the marketing guy, there’s no escaping security
December 28, 2010
Rob Murray here. I’m one of the “behind the scenes” guys here at The Hacker Academy, producing all the graphics, marketing materials, and help with the development and maintenance of the site. While most of my colleagues in the graphics and marketing worlds would never have the topic of security cross their minds, more and more today it’s becoming necessity to place security in the forefront of the mind, regardless of application.
Take for example the XSS vulnerability found within Google’s popular service Website Optimizer. GWO is quickly becoming a major cornerstone of internet marketing and research. This prevalence in today’s modern marketing vehicles opens up an increasing number of doors for vulnerabilities, like the aforementioned Cross-site Scripting problem in GWO, to be exploited in new, not previously thought of areas.
Now, for those who incorporate GWO services into their website for reporting and split-testing and haven’t addressed this problem, it’s recommended that you take the time to fix the vulnerability; both by Google, and common sense. It’s actually brutally easy, to be honest. Truth be told, the vulnerability will only affect those who have also had their server compromised by a separate attack, but it’s still a good idea to not let this one slip through the cracks. Note, the vulnerability only affects experiments that were created before December 3rd, 2010; any new experiments created after this date already include the updated code. It is recommended you delete any paused or completed experiments and remove the scripts from your site(s) to ensure the elimination of any latent threat.
For those who don’t want to delete an experiment that are currently running, here’s a link to another blog post with a great walkthrough for updating the Google Web Optimizer Control Script for your experiments:
Google Website Optimizer Security Bug and How to Fix It via Search Marketing Sage
It just goes to show how prevalent security threats are, and how wide a scope they cover, in our modern world. Even as a “graphics guy”, I like to think of it as a “good offense always trumps good defense” scenario: no matter what your job title, security is the proactive responsibility of all members of the team. Time and time again, it’s proven that it’s just only the network that is directly at risk, but the secondary and tertiary access vehicles as well.
Just some thoughts and a heads up 
Cheers,
Rob Murray
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.
