gmailbug.txt

`   
  
*- 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()>  
  
`