*- Gmail Bug -*

 

 

*INTRODUCTION*

This bug has already been corrected, that's why it's been published.

In this manual you will see step by step how to exploit Gmail's
vulnerability, that gave you access to any account, reported by
Anelkaos, colaborator of elhacker.net's forum and patched by Google by
October 18. Due to the bug's gravity (that allowed in a few simple steps
to login in any Gmail account), it was decided not to publish this
document while the bug was still active. Motives are more than obvious
because ALL Gmail accounts were vulnerable to the bug.

Google hasn't declared definitively this topic, and they seem to have no
intention of publishing the bug. The veracity of the failure was
demonstrated to the editors of the Magazine "Seguridad0", logging into
an account created for that purpose, just as described in
http://www.elistas.net/lista/informativos/archivo/indice/61/msg/79/.
They also "dared" to publish this news in CyruxNET and PCWorld.

The bug was discovered in October 14 and it was patched in October 18
because ANELKAOS decided to conctact GMail instead of publishing the bug
in a list of security, and lamentably we couldn't do more demos in other
sites that we sent the news, and because we're not HBX Networks, all the
people claimed for a "hacking' test". Thanks to heaven, we have saved
all the mails where Google recognize the failure. ;).

Unlike the reported by HBX and published by BetaNews last year, this bug
doesn't require cookie robbery, and because of that, the bug's danger
was considerably higher.

*PROCEDURE*

This is the way Sirdarckcat (EHN's user) developed the exploit, although
the original method is easier, the concept is the same one.

Due to the fact that this demonstration was realized against another's
person account, all data that could bring legal consequences have been
hiden. In AUTH variable goes the ciphered address of the mail's
propetary, and although we don't know how to decipher it, we've
preferred to hide its values, in case "someone else" could :).

First of all, we need two sessions. For that we've chosen to use
Internet Explorer and Mozilla. We start the session normally... for
example, in Mozilla..

If we pay attention, we notice that the login screen is now different.
It doesn't just ask if you've forgotten your password, it also asks now
for the user. Too much casualty, isn't it? That soon and coinciding with
the publishing of the bug's existence it has changed the authentication
is too much coincidence, isn't it? We're talking about 10 days ago :).

Well, let's continue. Now we need some data we'll modify. For that we
will also iniciate an Internet Explorer session, but we stop the browser
as soon as it says "Loading...".

We simply look at the source code and we save the value of the "ver"
variable, that we will need later.

 

Then we allow the page to continue loading, and we look the direction of
the inbox, that we can see by pressing right clicking, and then Properties.

We will need the "zx" variable, and we save it.

Now we go to 'mail/?username=victim&zx=[zx Variable]'

  And we stop the charging of the page just when it stops Loading,
getting inside:

We stop again the browser, and we look at the source code.

Here we have the code of AUTH that we need to initiate session as our
victim, but our cookie disagree (not the same).

We take a look inside the cookie, and we change the value of "ID" for
the one we got in the "ver" variable we got before, this what surprising
does is to return a valid value! It doesn't have related information,
why does that happen? Who knows...

GMail confirms that it's well ciphered, and completes correctly all the
rules. Nevertheless, even the content is not related, it doesn't return
an error.

 

Once modified the cookie, in the Explorer session, we enter into the
following page:

http://mail.google.com/mail?gxlu=victim&zx=[zx Variable]

 

In this moment we haven't already started the session, we've just
associated with the victim's account.

So we go to: www.google.com/accounts/ServiceLoginAuth
<http://www.google.com/accounts/ServiceLoginAuth>.

 And it sends you to:

mail.google.com/mail/?auth= [CODIGO auth]

At this point all we have to do is to modify the values of the cookie
that will expire... At least we give it 1 minute of life.

We enter mail.google.com/mail/?&&rm=false&null=Entrar&continue

We stop the loading because if we don't, Google is going to close our
session, so we write:

javascript:document.cookie+=";expires=Thu,%2001%20Jan%202070%2000:00:00%20GMT";

Once extended the cookie's life, we enter
http://mail.google.com/mail/?auth=[AUTH Code]

And we start the session as the victim.

Complete access, of course :).

*GOODBYE AND CLOSE.*

OK, it's a Beta version, and they don't have to report anything. But if
they would have recognized it and published a thank you note, this
information wouldn't had been published. We have 3 ways to get to the
same result, the others 2 are quite easier, and because of that easily
we can deduce that it's a multibug, and a design error. With all these
clues, they will not take too much to discover new methods.

 

 




 | encuesta <../encuesta.htm> | foro <../foro.htm> | boletín
<../email.htm> | recomendar </cgi-bin/birdcast.cgi> | ¿algún fallo?
<../bug.htm> | <javascript:window.print()>