Thursday, November 21, 2013

Google Account Recovery Vulnerability

Global Main Authentication and Identification Library (GMAIL)


If I told you to think of the most sensitive features (security-wise) in a web application, you would probably say – Login. Well if your definition of "Login" does not include password recovery, then it would definitely be the second one. This means, that password recovery is often in the center of attention for attackers – and for security professionals.

So let's say you are using Paypal, Facebook or Twitter, and you forgot your password (shit happens, right?). They will ask you to put your email in a nice input box, and wait until you get a password recovery link. If you're using Gmail (hey, who are you trying to fool? – you are!), it is the tool you recover passwords with, for every other application out there. Did you ever stop and ask what does GMAIL stand for? It’s the Global Main Authentication and Identification Library. Seriously, if someone got access to your Gmail account, he can "password recover" his way to any other web/mobile application out there (!). More about this can be viewed on a video by "security researcher" Don Friesen http://www.youtube.com/watch?v=2tJ-NSPES9Y.

What about the password recovery of your Gmail account? It's the password recovery for all the other password recoveries. According to the security jargon, it is a Mega-mega-mega-mega-password-recovery. A lot of nasty hacker's out there would love to find some holes in this fortress, that's why I decided to take a quick look at it.

There is no such thing as a Harmless CSRF


Let's begin our journey by entering the password recovery page:



The first step is pretty straight forward - just enter the Email address.


Watch out for the "arsessiondata" cookie parameter, as this encrypted little guy is going to store our progress throughout the recovery process (AR stands for Account Recovery).

Do you see a CSRF token here? I didn't think so. But seriously, what's the worst someone can do? Make you initialize password recovery process for other Google Accounts?

Google adds CAPTCHA validation for accounts that are being abused through their Password Recovery. You can CSRF a list of accounts, which will eventually show this annoying CAPTCHA to users once they choose to recover their password:



This also serves as a CSRF protection. But the problem is that you only see this if this particular account was abused or your IP address is an abusing address.

You should put CSRF protection on all data changing forms. If you rely on CAPTCHA's as CSRF protection, make it consistent.

If the account was not abused, you will be redirected to the following confirmation page:




On the way there, the name for the current account you chose for the password recovery process is being added to the encrypted cookie… which is starting to gain some weight:


"Spear-Phishing-Ready" Cross-Site Scripting and Open Redirect


You're now going to be asked tons of tons of questions, and I am going to spare the screenshots for you:
  • Step 1: Password – what is the last password you remember.
If you do not have a phone number or recovery email address, or just selected "Verifiy your identity by answering multiple questions", you'll get to step 2.
  • Step 2: Contact – define an email for Google to contact during the process.
  • Step 3: Password (again) and dates – what is the last password you remember? When did you last used and created your account?
  • Step 4: Security Question and Answer
  • Step 5: Gmail – give email addresses for contacts you talk with often, names of labels and your password recovery mail.
  • Step 6: Products – You might get away with this one, which asks you the dates you started using different Google products.
WOW! That's a lot of information. That's got to mean that Google takes Password Recovery seriously. 
We are during the final step:



Yey! Let's click on the Reset Password button. Oh! Wait! What's up there in the URL? That's another URL? Could we have an Open Redirect Issue here? Or better a Cross-Site Scripting vulnerability?
If there is one of these vulnerabilities here (or both) , than it's a spear phishing heaven. 

Your email address is there, it's on an HTTPS legit Google page, and there is only a single button there asking you to reset the password of your account!

Let's have a look in Burp's repeater:


Holy guacamole! We are reflected directly to a form action! That's awesome… we can put any URL here… and since you know you've just clicked a Reset Password button on Google, you would be happy to give away your password :)

Such a phishing exploit will look like this:


 

Once you click on the Reset Password button, you are going to get to the hacker's page (a smart hacker will use a Google hosted site, like Google Sites):


Now I want you to be honest and agree that if Google says that "you 've confirmed ownership" of your Google Account, and asks you to choose a new password you will not do so? At least your auntie would!

But you know what would be really fun? If we can turn it to a Cross-Site Scripting attack. I mean, we are reflected in a form-action attribute. All we've got to do is just put a javascript/vbscript/data URL and we're done (we also get to choose from a large variety of obfuscating encodings: HTML encoding, partial URL encoding, partial script encoding and even Base64 if we choose to use data URLs).

XSS filters! XSS filters?


Let's do it, but I am warning you… this is a pretty obvious XSS attack, and Google Chrome has one of the best XSS filters out there:




WTF? Seriously, where is that XSS filter when you need it?


We love wizards! (Flow Bypass using Forceful Browsing)


Okay. We had to insert tons of information to get to this step. Like seriously tons of info. And this is the last step! This means there is no way to exploit this thing…

Let's see if we are lucky enough and there is a flow bypass to the last step?



Hell no. We are getting redirected to the begging of this nightmare.
Let's just start the process, and see if we can jump from the first step to the last step (classical password recovery flow bypass). We are doing this to get our encrypted cookie parameter.

Let's try our luck with the exploit link again:


Hell yeah! Flow bypass worked… and straight to the final exploitable step.

Putting it all together


Now we need to get the user to initialize the password recovery process. How comfortable, things have come full circle. Remember the harmless CSRF from step 1? The one that "just" let you initialize the process?

Hey, but that was a POST message – which means, it's going to be just a bit harder to exploit. Unless we can just make it a GET request:

Yup… that also works.

Summary and building exploit (for example, spear-phishing):


1) Select a victim that uses Gmail (all you need is a Google Account, but KISS). For our example we will use hatechnion@gmail.com.

2) Send a phishing email, customized with the victims email address in the URL:


3) The link should actually refer to an attacker's site (and it does):

4) The attacker's site performs a CSRF with the customized email address, and once completed – launches the XSS exploit. The code might look like this:

Can you detect a vulnerability in the attack code itself ? 

The code above, reads a Hash parameter ("Email") for the victim's email. It creates an invisible image and puts an "initialize password recovery" link as its source.
After the request is processed, an Error event is thrown (since this is not really an image).

5) The onError handler now redirects to the XSS'd URL.
6) The user clicks "Reset Password"… and from here the sky is the limit.

The exploit video


Google Security Team Response

Google security team acted really fast. This issue was fixed in 10 days. This was reported according to the Vulnerability Reward Program rules (http://www.google.co.il/about/appsecurity/reward-program/) and I will get a financial reward alongside another Hall of Fame entry. 

37 comments:

  1. Was the ...jsEnabled=Fasle... intentional (that is, do they actually look for Fasle instead of False) or a typo?

    ReplyDelete
    Replies
    1. It was originally set to True. I changed it to False and didn't notice any change (but the link still says False).

      Delete
  2. now dis trick iz working or not?

    ReplyDelete
  3. Nice find. Though I think any and all Google Security emails will have a lock next to them. If they don't it's not Google (also not from a Google email address) if it were and not coming from a google IP they would have spamed the message or marked it as phishing.

    ReplyDelete
    Replies
    1. Keep in mind that the attack might be targeting a specific user (and not in a large distribution), making it impossible to mark it as Spam.
      In addition, the majority of the population does not actually validate the origin of every received email.

      Delete
  4. Great finding! Looking forward to see more of them

    ReplyDelete
  5. Bravo! Really great bug! Congrats!!!

    ReplyDelete
  6. The Jew would have got more gold had he sold it privately. But like most Jews, you want everyone to like you so, good on you for being a rat and not just looking like one.

    ReplyDelete
  7. hehehe great
    well can u help me to hacked a site ? :P

    ReplyDelete
  8. This comment has been removed by a blog administrator.

    ReplyDelete
  9. Lovely job! :)
    I didn't understand the password recovery bypass - could you please explain that further?

    ReplyDelete
    Replies
    1. If you are referring to the "flow bypass" part, checking the state of the recovery process (the progress and completed steps) before granting access to the final page - would've prevented this attack.

      Delete
    2. Yes, I understand the mitigation - I don't understand the attack. You sent the https://www.google.com/accounts/recovery/ktpass?rpu=javascript:alert(/H4F1F/) request with no cookie and it didn't work (redirect). Then you write you do classic flow bypass trick and suddenly it works. I don't know that classic bypass recovery trick.

      Delete
  10. Thank you for you share.I have one question.Why the url in email looks like "Https://google.com/....", but when victim click it the browser jump to "http://www.orenh.com/test.html#Email=hatechnion@gmail.com"?

    ReplyDelete
    Replies
    1. An html link is composed of two parts:
      1) The href (actual place the links leads to -> in this case orenh.com
      2) The text to display for the users (Normally says something like "Click Here", but it could be a "link").

      Nothing forces the two to match. That's just the design of HTML.

      Delete
  11. Im afraid everything about my android is infected somehow, all after ive attempted to thwart the hackers empire, built using my desktop via incognito mode. Hoe can i get free help? My world is crashing down so fast I'm afraid of living.

    ReplyDelete
  12. above tutorial for work on Andord mobile or it will work with firefox as well cause i tried to do this on my laptop but i didn't find arsessiondata in browser view source

    ReplyDelete
    Replies
    1. Works on every browser. Mobile included. Firefox included.

      The session would not appear by "viewing source". Use an interception proxy like Burp Suite, ZAP Proxy, Fiddler, CAT or any other.

      Delete
  13. This comment has been removed by a blog administrator.

    ReplyDelete
  14. This comment has been removed by the author.

    ReplyDelete
  15. Does the Vulnerability still exist?I test,but didn't succeed.

    ReplyDelete