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.
