McAf.ee is Stupid

McAfee just announced that they are releasing a URL shortener, and it's currently in beta (well it actually says "This Site is a Beta."). Honestly, I'm still trying to figure out what it's actually useful for, and not coming up with much. Did somebody decide it was needed? Did somebody think it would be helpful? Is this just McAfee swinging wildly in the dark at things that vaguely sound security related in order to bloat their product portfolio and brand?

Yeah, that might be it.

At any rate, there's a few issues I noticed with a quick inspection.

The server doesn't appear to be prefetching the URL, so it can't have any idea whether the URL is dangerous or not. Presumably it's checking the URL against the (admittedly impressive) database of sites that they use for SiteAdvisor, another McAfee product.

It does have some basic Javascript/XSS filtering, but it's only effective against specific vectors- it filters out some HTML characters (like < and >), but not other XSS vectors: " onload=alert(1)

Most URLs will be placed inside an iframe with some basic information about the target URL. If the URL is deemed harmless (or "green"), the user's browser can be set to bypass the iframe and go directly to the page. Presumably this is just a convenience-- there's no way this could actually provide any browser security, but if a way to attack this iframe were found, or if the iframe needed to be disabled, an attacker could turn that feature on/off via CSRF:

http://mcaf.ee/api/config?bypass_frames=1
http://mcaf.ee/api/config?bypass_frames=0

The only real information McAfee provides somebody visiting a shortened URL is in the iframe, where it says what kind of website they think you're visiting (in the case of skeptikal.org, it's "Software/Hardware Blogs/Wiki"). Interestingly, if the link I provide throws a 302 or other redirect, it still thinks you're looking at my site. Since they're not prefetching the page, they have no idea whether I'm redirecting you elsewhere, or attacking you directly. If users are screening pages using McAf.ee, it's trivial to bait-and-switch them onto another site.

The question I'm still asking is "who thought this would be useful?" It's really not. First off, they claim to let people create "safe short URLs." That's not even close to true, based on what I've seen. Second, the whole thing is pointless unless users refuse to click on any other shortened URLs-- a ridiculous proposition to begin with. Attackers will just use a different URL shortener. Users will keep clicking on anything, and it's not the URL shortener's job to keep them safe at any rate. Not to say that McAf.ee directly causes security issues, but it doesn't appear to solve any security issues either.

/sigh

Another day, another Twitter XSS

It may surprise some, but I really haven't been big on XSS lately, mostly because it's a problem that hasn't changed for years, and the most basic form of it is still brutally simple to exploit. Not a lot of excitement in it, I guess. But that doesn't mean that it doesn't deserve attention- in fact, that's exactly why it does. So when a new Twitter XSS popped up on my feed reader this morning, I took the 10 minutes it takes to write a proof of concept, and put together an exploit.

You can check it out if you like (It won't bite until you manually click the "pwn me" button, so the link is safe, but don't take my word for it, use NoScript and RequestPolicy). Frankly, if I wanted to hack you, I'd be doing it silently on this page, not that one.

I'll post a followup later. This example drives some pretty interesting points home.

Cross-subdomain Session Fixation

Last fall I wrote a bit about cross-subdomain cookie attacks. As often as I come across more uses for them, I think that they are a much more serious issue than most people (myself included) have made them sound. Today, I came across a variant which I'd theorized about in the past, but never bothered to find in the wild, and I think it merits some attention.

You may be familiar with Hack Is Wack- a stupid marketing campaign from Norton/Symantec. The premise is simple: users submit videos, which are voted on, and the winner gets to roll with Snoop Dogg...'s manager. You may not know it, but most of Snoop's music is information security-related. "What's My Name" is about AuthN, "Drop it like it's Hot" is about SQL injection, not to mention constant references to cron, gzip, and other unix commands in his lyrics. It's really a pretty natural match.

At any rate, the Hack is Wack site is chock full of holes. For example, there's the publicly available, indexed cache directory with all that SQL, JSON and other data. There's the XSS vulns (HTML5 only, though it should be simple enough to rewrite), CSRF holes, and the Flash upload issues in the video upload script (a Joomla module that appears to have been used without any quality control or review despite the fact that it's currently in Alpha)

A security company using bad code in a marketing site? Shocking, I know. I'm really not here to harp on them though. I'm over security vendors being full of shit- they all are, it's not news.

I just found a particular attack vector interesting.

The voting system for uploaded videos is grossly vulnerable to CSRF, and probably much more serious things, based on the format of the "vote" URL (unencoded, for ease of reading):

http://www.hackiswack.com/index.php/home/rate.html?videoid=\'.24.\'&rating=4

This means that I can create image tags in my own website to vote for a specific video and stuff the ballot box. Classic CSRF, right? It's something I've talked about before, but unfortunately, this one isn't quite so simple. You have to be logged into the site to vote, and they prevent a user from voting twice for the same video, so to manipulate this poll, we really need to create a whole bunch of user accounts. The user registration page is part of the main Joomla codebase, and it uses session-based tokens to prevent CSRF- the way they should.

The interesting thing here, is that the application doesn't enforce the HTTP Host header. Instead of http://hackiswack.com, there's no reason you can't use the application from http://184.106.223.144, or more importantly, http://hackiswack.skeptikal.org (no, this doesn't actually go there, but there's no reason it can't).

Once I have my own domain set up, I can easily force a visitor to skeptikal.org to assume arbitrary session cookies that will also be sent by his browser to hackiswack.skeptikal.org, and with a known session cookie, I can request the page myself and parse it for the CSRF token. I can then embed that token in any forms I force the user to send, bypassing the protections that Joomla so carefully puts in place.

All right, so this is a lot of work, and probably isn't practical for stuffing ballot boxes, (especially since there are already much more serious vulnerabilities to take advantage of) but as a way of bypassing CSRF protections, it's perfectly valid. There are plenty of times where a CSRF protection mechanism can be bypassed with a simple session fixation attack. A variation on this was described by RSnake last fall, using DNS rebinding instead of subdomains. It's probably more potent with DNS rebinding, but a cross-subdomain attack tends to be much simpler to set up.

The key to remember is that in this case, you can't take over an arbitrary session, so it is of limited use for, say, compromising an Admin. However, if you want to log a user into a website (with known credentials), or otherwise force him to do something on your behalf, it's a very useful technique. Something to keep in mind, at least, and another reason why websites that don't require specific Host headers should be considered vulnerable.

Hat tips to The Harmony Guy and Packetwerks for pointing out some of the holes in the Hack is Wack site