Thursday, October 30, 2014

Reflected File Download - A New Web Attack Vector


From my Company's Blog:

On October 2014 as part of my talk at the Black Hat Europe 2014 event, I presented a new web attack vector that enables attackers to gain complete control over a victim’s machine by virtually downloading a file from trusted domains. I decided to call this technique Reflected File Download (RFD), as malware can be "downloaded" from highly trusted domains such as Google.com and Bing.com without ever being uploaded...

The full blog post, including links to the WhitePaper and exploit videos is now available:
http://blog.spiderlabs.com/2014/10/reflected-file-download-the-white-paper.html
Posted by at 117 comments:

Tuesday, June 10, 2014

One Token to Rule Them All - The Tale of the Leaked Gmail Addresses

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.

 Go to summary and video.

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):

https://mail.google.com/mail/mdd-f560c0c4e1-oren.hafif%40gmail.com-bbD8J0t6P6JNOUO36vY6S_pZJy4

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:
  1. The email address that requested access (hastudent@gmail.com) is not in the URL.
  2. The request also works as an unauthenticated request (no cookies).
  3. 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 
  1. The first part “https://mail.google.com/mail/", is just the normal mapping to the Gmail application.
    [Homer says: "Sigh!"]
  2. The second “/mdd” is the mapping for the mail delegation deny servlet.
    [Homer says: "Sigh!"]
  3. 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!"].
  4. My email address – probably not relevant.
    [Homer plays Spider-Pig again].
  5. 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.

Should your company move to the cloud? A really hard question!
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).

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?
Now let's put it all into DirBuster:

  1. Dictionary name is gmail_0000.txt
  2. Select starting options would be "URL Fuzz"
  3. 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: 
  1. Get the delegation deny URL.
  2. Create a dictionary with all 10-HEX-Character-Long-Token combinations. Ruby is awesome for that.
  3. DirBuster in URL Fuzz mode to obtain all valid tokens.
  4. Bypass Google Anti-Bot protection.
  5. Convert tokens to email addresses (for example, with Burp's intruder).
  6. Send Google a file with some of the extracted email addresses.
  7. Get a bounty.
What else can be done with this information? 
Read "From username to full account takeover".

The exploit video

Posted by at 224 comments:

Tuesday, February 11, 2014

CVE-2014-0050: Exploit with boundaries, Loops without boundaries

You are more than invited to read the post I wrote on the SpiderLabs blog about CVE-2014-0050.
The post include analysis of the vulnerability, exploit and recommendations. You can find the post here:

http://blog.spiderlabs.com/2014/02/cve-2014-0050-exploit-with-boundaries-loops-without-boundaries.html


Posted by at 53 comments:

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. 

Posted by at 643 comments:

Saturday, November 16, 2013

Coming soon...

Coming soon...
Posted by at 33 comments:
Subscribe to: Posts (Atom)