INTRODUCTION

This bug
has already been corrected, that's why it's been published (October-November
2005)

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: href="http://www.google.com/accounts/ServiceLoginAuth">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.