Parsing Quirk Causes bit.ly XSS

Fun fact: When your browser parses a document, it locates <script> and </script> tags before evaluating the javascript within. While this appears to make sense, it creates an interesting quirk- injected </script> tags, even within quoted javascript strings, will force it to end a block of javascript code and throw a parse error. It will also allow you to start a new block of unquoted (and therefore, executed) code.

I put together a basic demonstration of this quirk a while ago and bounced it off a few people. As it turns out, this is known behavior, and was even used in one of the first examples on RSnake's XSS Cheat Sheet.

Arguably, this is not really even a bug. It stems from the order in which the document is parsed- structure (tags) is handled before parsing javascript content. I looked into the various standards that apply and didn't see anything dictating how this behavior should be handled, but I confess I didn't look that hard.

At any rate, the reason I'm writing about it today is because I found an XSS hole in the popular URL shortener, bit.ly. This can be used to compromise browsing history, tamper with a user's bit.ly settings, and even abuse Twitter accounts (they have a Twitter API).

Due to the nature of the exploit the link only works once, so I can't send you directly there. However, if you take the following URL and make "CHANGEME" a unique string, it should work.

http://bit.ly/?url=http%3A%2F%2Fskeptikal.org&keyword=%22%3C/script%3E%3Cscript%3Ealert(1337)%3C/script%3ECHANGEME

While it's generally known that putting user-supplied input into executable code is a bad idea, many developers still do it, especially with javascript. Don't assume that just because the input is wrapped in quotes, it will not be XSS-able.

Watch Out For Suspicius Links

As part of our recent research on CSRF attacks, Russ McRee found a vulnerability in the Linksys WRT160N router. Sadly, this wasn't a huge shock to us, but what was surprising was the response from Linksys:

We can’t reasonably prevent CSRF's without bogging down our code. The compromise we had made here is to have a timeout on the web interface, so users are logged out after 10 mins of inactivity. We have also advised users to not click on suspicious links while logged in to the web interface, or close the web interface as soon as they are finished configuring the router

As ridiculous as the entire response is, I'd like to focus on the "Don't click suspicious links" bit. Most users will click on any link you throw at them, particularly from link-heavy social sites such as Twitter. In fact, if you clicked through to this page from my Twitter post, the page you're currently on should be at "http://skeptikal.org/a_very_suspicious_link."

Why did you click it?

Because you trust me. And you trust Twitter. And you trust my hosting company. And your DNS servers. And my DNS servers. And TinyURL.

I could rant on this topic for a while, but I know I'd be preaching to the choir. Don't trust any links, anywhere. Especially don't trust the ones from TinyURL, bit.ly, or any other URL shortening service. You have no way of knowing whether a site is malicious or not until you load it into your browser. Even then, it's doubtful that you'd ever notice. You're probably not a normal user, but most people wouldn't ever recognize real malware for what it is, especially if it's properly obfuscated.

In theory, a goal of never clicking a malicious link is impossible to achieve. In practice though, many malicious links are fairly easy to recognize if you just look at the URL. This is why sites like TinyURL allow you to preview links before being redirected to them. Earlier today, @OWASP_podcast sent out the following tweet:

http://tinyurl.com/preview.php?enable=1 will force all TinyURLs to appear in preview mode on your machine.

It's a good idea, but this is clearly a URL that modifies user preferences based on GET variables, and I couldn't help noticing that the same preference could be disabled with a bit of CSRF:

<img src="http://tinyurl.com/preview.php?disable=1">

I'd call this a failure on TinyURL's part, but even if you did preview the URL, there's no guarantee the seemingly innocent link won't have malicious content, redirects, cross-site scripting, HTML injection holes, poorly configured DNS, poorly coded flash files, content ownership problems, compromised FTP accounts or other issues.

Just keep that in mind- previewing a link is a convenience, not a security feature.

GuestCentric Systems- Not Really That Secure.

I ran across a press release from GuestCentric Systems dated April 20, in which they announced their partnership with McAfee to put the McAfee Secure logo on all their client's pages.

GuestCentric offers a booking management service to independent hotels, and from the looks of things, it's actually a pretty cool app. They appear to be awfully proud of that system, and the fact that it was certified as secure. Now we all know that the McAfee Secure certificaton has serious deficiencies, but that horse doesn't appear to be dead yet, so I'll keep flogging.

The video on GuestCentric's press release essentially mimics the hype from McAfee- put the logo on your website, watch your sales jump 14%. It says nothing about the actual state of security in the app, and is purely marketing fluff. This always irritates me, but it doesn't surprise me. Of course, it also should come as no surprise that GuestCentric has XSS holes on their website, or that the booking application itself contains XSS holes as well. It also has CSRF holes and more.

What is interesting to me in this instance is that the GuestCentric app is almost completely AJAX. While McAfee secure is terrible at finding XSS and CSRF holes in the first place, it certainly does not parse AJAX and does not intelligently fuzz for these vulnerabilities. Short of detecting out of date software on the server, scanning this application with McAfee Secure is particularly useless.

The really amazing thing to me is that McAfee values their brand so little. Their name and logo are put on so many websites that they have so little to do with, nobody actually trusts (or in most cases, even sees) their certification.

McAfee keeps citing their 14% number. While I have doubts about the validity of that study (and real data has never been released), I have to wonder whether those numbers would be the same today. Something tells me that the answer is a resounding "no."

Spamming Ecommerce with CSRF

The idea isn't entirely new- CSRF has been used in the past to abuse ranking systems and push pageviews through the roof. These attacks have a lot of applications in spamming, black hat SEO, and manipulating site statistics.

I came up with an interesting variant on this recently. Instead of trying to get as many hits as possible to a page (in an ecommerce app, for example), we can force users to view a product of our choosing (one we sell, of course). This, in turn, will make that product pop up in his "recently viewed items" page, or, in many cases, the front page of the site. It's easy to see how this attack could be directly monetized- putting your product on the front page of, say Amazon.com, will go a long way towards increasing its visibility and ultimately, its sales.

This attack can even be targeted towards specific audiences very easily by sticking these history-poisoning links in domain-specific websites- weight loss products on weight loss forums, tech products on tech sites, etc.

The important distinction is that instead of attacking the server directly, we're abusing the user's session. Taking it a step further, some sites allow the attacker to actually stick products in the user's shopping cart via CSRF. If you don't notice that they're there, you may end up buying things you didn't intend. If you do notice them, you still will likely click through and view the product- effective advertising, no doubt.

As a proof of concept, this page will poison your browser's Amazon.com recommendations, eBay product views, your Walmart.com shopping cart, and your Overstock.com cart.

Could spammers use CSRF to push their products to the front page of your favorite ecommerce portals? You bet. Would that be valuable? Given the massive amount of money people throw at the SEO and advertising industries, I have to assume so.

I'll Be Speaking at Defcon 17

I've known about this for a few weeks, but it just went up on Defcon's website today. Russ McRee and I will be presenting at Defcon 17 in Las Vegas next month. The title of the presentation is "CSRF: Yeah, it still works." If you're going to be there, I'd love to see you.

Strongwebmail Contest Won

StrongWebMail announced yesterday that we officially won their $10k contest. Surprisingly, they don't appear to have learned from this last round of bad publicity and intend to launch another contest- once they've patched some holes and tightened the rules.

Assuming that the new rules aren't ridiculously restrictive, I'll probably participate in the next round- I've still got a few tricks up my sleeve. However, I must say I feel a bit dirty for feeding this publicity machine. These hacking contests, frankly, are a joke. If nobody gets in, marketing will hail their product as unbreakable. If somebody does get in, they call foul for breaking the rules. While some structure is necessary for any organized contest, the whole point of hacking is finding ways to bend rules and manipulate the system.

StrongWebMail's press release said "It is important to note that the frontend protection offered by StrongWebmail.com was not compromised. In fact, Lance and his team were forced to find a way around the phone authentication." That's not entirely true- we simply took the easiest route. With the webmail app riddled with holes, we saw no point in bothering with the front end. Considering it took us less than a minute from registration to find the hole we used to compromise the app, can you blame us?

I understand that StrongWebMail was created to demonstrate Telesign's 2-factor authentication system, but this is a perfect demonstration that security needs to be addressed holistically. When you claim to have "The Most Secure Email Accounts on the Planet", nobody cares that it's the third party app that is vulnerable- they care about the fact that the email accounts are indeed vulnerable.

The exploit that we used to break in involved an XSS hole in the email preview feature. We sent a message to the CEO's email account, and when viewed, his web browser made several AJAX requests to the server, slurping the contents of his inbox and then depositing it on a logging script under our control. Lance did an interview in which he discussed the details of the exploit further, and I recommend you read that for more details.

Finally, I want to give another big thanks to Lance James and Aviv Raff for working on this with me. Not only was it very fun, but it made some very good points (that will likely be forgotten soon) about web application security: Escape outputs, be careful with what third-party software you use, and don't taunt the hackers.

The StrongWebMail Incident

In case you've been living under a rock, Lance James, Aviv Raff, and I took up StrongWebMail's challenge to break into their CEO's webmail and claim a $10,000 prize. The terms of the contest preclude us from disclosing the details of the exploit, and while they've partially patched the holes that caused it, I'm not sure we're ever going to be allowed to tell the whole story.

Rest assured, we will openly disclose as much as we can, as soon as we can. In fact, I already have a blog post written and ready to go live. It will be published early next week at the latest, so stay tuned.

The current status: StrongWebMail's CEO confirmed that we exploited the application. They still have not confirmed that we won the prize, and are checking to make sure we complied with the contest rules. I'm confident we did. They gave themselves 3 business days (from yesterday, when we submitted the golden ticket) to confirm the win.

A few news reports about the incident implied that we may not qualify because social engineering is off limits. I can't make comments regarding the extent to which we used social engineering, but the rules say nothing about it- only that "working with an employee of StrongWebmail.com or one of its affiliates or partners to complete the hack" is not allowed.