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.