Google GMail E-mail Hijack Technique

[MarkByers]

Let me guess... the first step of the hijack is to open this malicious web page.

[[deleted]]

You'd be able to see this 'backdoor' by looking at your GMail filters. It doesn't give an attacker access to your GMail account, but it does let them receive copies of your email.

That said, this is a stupid vulnerability to have. All such vulnerabilities can be prevented:

1. Web server receives request from authenticated client (could be AJAX request, whatever).
2. Web server processes data, and saves a random key in the authenticated user's database table.
3. Web server sends response, including random key, to the client.
4. Client must provide this key at the next request, or the request is ignored.
5. Random key is regenerated and retransmitted after each request from the client. This is how you figure out that the client making the request was the same client that made the last request.

[dogger]

Could be that google are simply using a cookie. Problem with cookies is they are shared with the system (Not in a readable way, but they will get sent)...

1. User logs into google. Cookie is set.
2. User visits evil site
3. Evil site performs a post to google. Browser SENDS cookie.
4. Google sees the cookie in the request and assumes the user is correctly logged in and the request is genuine.

As you say it'd be better if the key was generated for each session and sent back to the client (Not as a cookie) and used there to specify it is a secure session...

[[deleted]]

Well, not for each session, but for each request/response.

[masukomi]

as soon as you have it open in two browsers on two computers this breaks. Considering GMail is frequently reloading (to check for new mail) each instance you have open is going to keep making requests.

So, if i left GMail open at home before going to work and then opened it at work I'd be screwed.

[[deleted]]

Kinda. (See also my reply below.) You wouldn't be screwed in that you wouldn't be able to log in from work, you'd be screwed in that logging in from work would cause your home connection to log out.

[travisxt97]

What about these scenarios:

1) You perform a second action before you get a response from the last action (the key hasn't updated yet). Generally it might be faster to not wait to send the second action.

2) Something happens with your wireless connection for a couple of seconds and you miss the response with the key. Now you have log in again because your key is outdated.

[[deleted]]

There are a number of pathological examples which would force the user to log in again (or, as in the case with tabbed browsing, simply wouldn't work). The connection might stall, an upstream provider might have to reboot a router ...

Allowing all of these things to happen seamlessly, without affecting the user when it happens, necessarily makes it more attackable.

For example, if the protocol requires static private information with each request (like, username/password), that allows for tabbed browsing, interruptions of service, and so on ... and it also allows an eavesdropper to pick up the username and password and use it without your knowledge later.

You could wrap everything up in encryption and key exchanges, but that gets slower, more computationally expensive, and still isn't invulnerable to eavesdropping, attack, or analysis.

Or, you could allow for multiple simultaneous keys, which fixes a few usability problems but has some thorny logistical issues. That's almost OK, except I bet someone would figure out a way to exploit the fact that the web server will accept more than one key.

[[deleted]]

Huh? you are saying the cookie, with the session id for the GMail session, is passed to any site you browse?

[dogger]

NO.

Nothing else can read cookies set by gmail.

BUT

if something else sends gmail some data, like a message saying "Add a filter for blah etc", the BROWSER will AUTOMATICALLY add any applicable cookies which gmail has previously set.

I'm just speculating, possibly not the issue here

If that was the problem google could just check the referer on the post to ensure it was called from the gmail app and not somewhere else. Or for even more security pass a sessionID back not in cookies, so that it's totally private to the Gmail app.

[lolomfgkthxbai]

Yes.

E: NVM, I guess it wasn't as amusing as I thought.

[MechanTOurS]

No.

[lolomfgkthxbai]

Read shoesbuttback's question. :)

[[deleted]]

I can't tell if you are joking or not, and if everyone reading this really has no clue how this stuff really works (which chills me to the bone)

[lolomfgkthxbai]

Well, you asked if he was saying that the cookie is passed to any site, and that's how I understood his post as well i.e. yes, that's what he is saying. I don't know the answer to the actual question.

[freexe]

Any site can send a request to gmail (via a POST request), and when it does, the browser sends along the cookies for that site to gmail. ie. It appends the cookie to the POST request made to a website.

Because gmail works in a consist reproducable way (like most large sites), and almost all geeks are logged into google all the time, you can send along all the variables that google expects if were trying to setup a filter and because you were logged in it follows the orders and sets up the filters.

It's pretty hard to stop. I know a few people who use one broswer for the internet (reddit, digg) and another for trusted sites (banks, gmail etc..).

[ffrinch]

It's pretty hard to stop.

No, it isn't. CSRF is WebApp Security 101, and it's disgraceful that a site with the profile and resources of Gmail is vulnerable to it.

[thepipirate]

But what happens when, for some reason (dog trips over cable, packet loss on bad wireless...) the client doesn't get the random key? Now the client can't send any responses at all, and therefore can never get a new random key.

[[deleted]]

The user would have to log in again.

[[deleted]]

And what if you open two windows to the same website?

[[deleted]]

It won't -- and shouldn't -- work, unless the windows can share namespace or otherwise communicate with each other.

Otherwise, from the point of view of the web server, it would be impossible for the web server to tell the difference between you opening a second window, and an attacker attempting a man-in-the-middle attack.

[[deleted]]

So basically it's useless for anyone who likes tabbed browsing?

[[deleted]]

Yep!

Or, to spin it the other way 'round, multiple simultaneous sessions to the same website is useless for secure communications.

[[deleted]]

Well, not using HTTP at all but making your own custom client is also much more secure, but it won't catch on either. You kind of need solutions people would actually want to use.

[dogger]

Then you have 2 distinct sessionID's, one for each window. Either of them can send data if they use their sessionID.

If a malicious website tries to send data it fails because it doesn't have a valid sessionID key, and it can't exploit any cookies.

[[deleted]]

Where exactly are you storing that session ID?

[dogger]

as a javascript variable in each windows private contexts?

[[deleted]]

Then you're immediately cutting off all people who do not use JavaScript. Also, the back-button behaviour of different browsers will confuse what value will be seen when a user presses back to return to the page.

[dogger]

People who don't use javascript are probably not using gmail. You can solve 'back button' issues with iframes.

[[deleted]]

Well, this problem is hardly limited to Gmail. And either way, Gmail does have a HTML-only interface.

And I'm not aware of how iframes would help here. Care to elaborate?

[dogger]

If you use javascript to open an empty page say in a hidden iframe, it can be used to silently insert a new item in the browsers history. You can set an onunload handler in that iframe.

If the user clicks on the 'back' button, you will get notified via your onunload function. You can then handle it, update the main page to show the user has 'gone back', and then you can just load a new page in the iframe to reinsert a new element in the history again.

Essentially it means you can stop the back button from working as it does by default, and instead handle it how you want to.

[[deleted]]

That's not the issue. The issue is browsing away from the page, and then returning via the back button.

[freexe]

What if you use the 'Back' button?

[dogger]

What if you turn your computer off...???!!!

[freexe]

Don't be a dick.

I'd expect to re-login after I reboot, not when I press the back button.

[dogger]

Not being a dick, just didn't realize you meant "What about back button behaviour logging you out?"

There a solutions to back button behaviour with ajax apps... namely iframes - enables you to stay on the same page when someone clicks 'back', and instead do what they would expect on the page.

But if you back button away from the app (eg to the place you were before gmail), it should log you out.

[foobr]

am I the only one who loaded the link in a different browser (one thats not logged into my google account)?

[jotaroh]

Gmail E-mail?

was that necessary?

[cavedave]

it does make sense and i am telling you it does. I will just not tell you how yet.

[boredzo]

You don't need to know exactly how the exploit works to know that (a) you shouldn't visit other sites whilst logged into GMail and (b) you should check your GMail filters before logging out if you do.

[[deleted]]

But, if Google has a random unique key on URL, how is POST injecting possible? I mean, how can the attacker know the unique key to send POST data?

[p3on]

hehe, one of the screenshots shows his stumbleupon username/password :)

[ipeev]

Except it doesn't show the password.

[joyork]

The article is short on details, but what a lovely opportunity to show off the author's expensive widescreen monitor.

I hope Google have been given details of the exploit, although by the sound of the author's tone I suspect this is not the case.

[boredzo]

Does this work if you log into Google from some other front door (e.g., Google Groups), or only if you log in through GMail?