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.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:
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
actionattribute 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":
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 (18.104.22.168 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.
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 ;-).
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, 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.
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 aauthorization bypass hole?