Since I don't really know where to start, let's start at the end. At the very end of this attack, I am going to hold what appears to be every single email address hosted on Google. So what? I mean why is that such a big deal? To answer this question, you might want to read the following article I just posted on the Trustwave SpiderLabs Anterior Blog: From a username to full account takeover.
As indicated in my previous post, GMAIL is the Global Main Authentication and Identification Library. It is used everywhere from sites like Facebook and Twitter to online-banking. Owning your Gmail account is a hacker's dream – because it means all other accounts are now in reach.
Think about how much money a spammer or a country (China?) are ready to pay for a list of all Google Accounts related emails? At the end of this post you will also find out how much money Google thinks that such a list is worth.
Short Version
I really think that you'll enjoy this blog, however, for those of you who can't take 5 minutes to read it, here is a one-liner:
I bruteforced a token in a Gmail URL to extract all of the email addresses hosted on Google.
I bruteforced a token in a Gmail URL to extract all of the email addresses hosted on Google.
Gmail Delegation Feature
Did you know that you can use the Gmail delegation feature to grant other people access to your Gmail account? Well until (very) recently, neither did I. You can go to account settings, and select “Add another account”:
 |
| Gmail Settings - Gmail Delegation Feature |
After you do that, an email message will be sent to the account you just entered. It looks like this:
 |
| Gmail Delegation - Accept or Deny? Can you spot the differences? |
As you can see there is an accept link and a reject (deny) link. We can play “spot the differences” – but I am not sharing my bounty with the finder. Clicking on the reject link gets you this message (the language differs based on the settings of the delegation email Google account):
 |
| The "delegation deny" link for "hastudent@gmail.com" |
Google is telling us for which email address we denied access. In this case it is hastudent@gmail.com. Given that:
- The email address that requested access (hastudent@gmail.com) is not in the URL.
- The request also works as an unauthenticated request (no cookies).
- Google is extremely distributed.
It would be safe to assume that something in the URL helps Google determine the delegation email address and present it to us.
Deep URL inspection with Homer Simpson
Let’s take a closer look at the request URL, with our friend Homer Simpson:
https://mail.google.com/mail/mdd-f560c0c4e1-oren.hafif%40gmail.com-bbD8J0t6P6JNOUO36vY6S_pZJy4
- The first part “https://mail.google.com/mail/", is just the normal mapping to the Gmail application.
[Homer says: "Sigh!"] - The second “/mdd” is the mapping for the mail delegation deny servlet.
[Homer says: "Sigh!"] - What does “f560c0c4e1” stand for? It looks like a token. There is some hope here, as this one is so short and it’s hexadecimal
[Homer says: "WooHoo!"]. - My email address – probably not relevant.
[Homer plays Spider-Pig again]. - What does “bbD8J0t6P6JNOUO36vY6S_pZJy4” stand for? It looks like an encoded blob. This is normally a BAD sign as Google loves to HMAC request URLs and that could be a giant “pain in the scans”.
[Programmer Homer says: while(true)("Sigh!"+"D'oh");].
So this leaves only (3) and (5). First thing first, I tampered the blob from (5). WooHoo! It is not validated and the email is still being exposed! Note that in the “delegation accept” URL it was actually validated.
Well, if I counted correctly we are left with the token from (3). From now on we will call it “the token”, “token” or “my precious”. My precious token, I won’t let any sneaky little hobbitses take it from us!
One Token to Rule Them All – The Fellowship of the Token
So I start a bruteforce – and what do you know… I get email addresses, lots of lots of email addresses. So many email addresses that every single tool I use for the bruteforce collapses. So I write my own multithreaded script in ruby – which is not as fast as I want.
I took a break to look at the (temporary) results of ~1000 emails. And I see a lot of none “@gmail.com” addresses. So I check the domain names of these emails and then it hits me – these are domains of organizations that are using “Google Apps for Business” and this also includes the internal @Google.com addresses of Google employees.
That is actually a pretty hot topic right now. Should we move to the cloud? Should we use Gmail as our organizational email manager? As the argument about the future of enterprise email goes on with a focus on security - leakage of organizational emails might assist attackers in their spear-phishing attacks and eventually expose the company to advance persistent threats.
Question to Google: business emails can be considered more sensitive than “@gmail.com” addresses. So why don’t you separate the environments that deals with such addresses. I mean, why not sandbox the entire organization using the “/a/ " mapping, that is already there. I see no reason to put all emails in the same database (at least not for delegation).
 |
| Should your company move to the cloud? A really hard question! |
Question to Google: business emails can be considered more sensitive than “@gmail.com” addresses. So why don’t you separate the environments that deals with such addresses. I mean, why not sandbox the entire organization using the “/a/ " mapping, that is already there. I see no reason to put all emails in the same database (at least not for delegation).
My precious token can get them all, even if you never gave your email address to any single living creature (especially hobbits). Private emails or business email addresses with your organization’s domain, all are mine. If you consider some of your employees and executives email addresses confidential, that’s a problem.
One Token to Rule Them All – The Two Towers
So, where were we? Our current goal is to bruteforce all tokens. We still haven't found a tool that is fast enough to get us through. A tool that will enable us to leak all email addresses.
Well, salvation finally came from our "direst" friend, the mighty wizard of OWASP, also known as the DirBuster. Not a lot of people know that DirBuster is also a great URL Fuzzer. With the ability to support a large number of threads alongside using HEAD requests to improve performance, DirBuster is our current hope.
But, in order to get DirBuster to work, we need to provide a dictionary. In this case, it would hold all 10-character long combinations of such an HEX-string. Generation of such a dictionary is fairly simple (here is a ruby example, and yes I know it could be done in one line):
 |
| Ruby dictionary generation. Simple, isn't it? |
- Dictionary name is gmail_0000.txt
- Select starting options would be "URL Fuzz"
- The URL to fuzz is /mail/mdd-{dir}-support@google.com-O6xUbWXP7hm8GaZGUetuk5f9vlU
 |
| DirBuster accepts the challenge |
DirBuster will now replace the string "{dir}" with all of the tokens from our dictionary. Each 200/OK response is one small victory towards our glorious battle.
Bypass Google's Anti-Bot Protections
If you ever tried to scan Google then you probably encountered this message, also known as the "Google Sorry" product:
First things first, apology accepted. Google will start throwing this at you after ~30K requests, and sometimes even sooner. It really depends on the URL, cookies, your IP address and a bunch of other stuff.
Have you noticed something weird in the URL pasted into DirBuster? That's right, I've put "support@google.com" there, instead of my own email address. This is a honeypot which confuses Google to block requests with that string in the URL instead of blocking our entire attack campaign. So, now you can try for yourself, go ahead and confirm that the following link would get Google to apologize to you:
And now, try replacing that string with something else… You see? I told you so. This is useful information whenever you choose to launch automated attacks on Google (which you shouldn't without getting permission from the Google security team). So after they'll block us – we would just change this to "bla@google.com" for example, and keep on going.
One Token to Rule Them All – The Return of the King
We have the tokens, all we've got to do in order to translate tokens into email addresses is to access these links. A simple wget/curl loop would do. I chose to use Burp's intruder for that:
 |
| That's a lot of email addresses. Censored for the sake of humanity. |
After the hard work invested in this attack, I think it is pretty obvious that I would get the honor of declaring the King's return - the one that saved the day once again – the Google Security Bot:
 |
| Thank you Google Security Bot! |
The Google Security Bot and his knights (the Google security team) fixed the vulnerability and rewarded me with a 500$ bounty.
Summary and building exploit:
To sum it all up - here is the process simplified to a step-by-step list:
- Get the delegation deny URL.
- Create a dictionary with all 10-HEX-Character-Long-Token combinations. Ruby is awesome for that.
- DirBuster in URL Fuzz mode to obtain all valid tokens.
- Bypass Google Anti-Bot protection.
- Convert tokens to email addresses (for example, with Burp's intruder).
- Send Google a file with some of the extracted email addresses.
- Get a bounty.
What else can be done with this information?
Read "From username to full account takeover".
Read "From username to full account takeover".
