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 not to have intention to publish 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 "dare" 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 consequence 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 ask 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 :).
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 at look what we have in the cookie, and we change the value of "ID" for the one we got in the "ver" variable we got before, this what surprising makes 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.
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.
