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
.

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.

Source

http://www.indian-hackers.net

Related hyperlinks

http://www.elistas.net/lista/informativos/archivo/indice/61/msg/79/

Description:
SquirrelMail is a standards-based webmail package written in php. It
includes built-in pure PHP support for the IMAP and SMTP protocols.
Unfortunately there is a fairly serious variable handling issue in one
of the core SquirrelMail scripts that can allow an attacker to take
control of variables used within the script, and influence functions
and actions within the script. An updated version of SquirrelMail can
be downloaded from their official website. Users are advised to update
their SquirrelMail installations as soon as possible.

Variable Overwriting:
There is a fairly serious variable overwriting vulnerability in one
of the core SquirrelMail scripts. The vulnerable script makes use of
an extract() call in a careless manner, thus allowing us to overwrite
any variables declared before the fault extract call is made. Let’s
have a look at /src/options_identities.php

/**
* Path for SquirrelMail required files.
* @ignore
*/
define(‘SM_PATH’,’../’);

/* SquirrelMail required files. */
require_once(SM_PATH . ‘include/validate.php’);
require_once(SM_PATH . ‘functions/global.php’);
require_once(SM_PATH . ‘functions/display_messages.php’);
require_once(SM_PATH . ‘functions/html.php’);

/* POST data var names are dynamic because
of the possible multiple idents so lets get
them all
*/

if (!empty($_POST)) {
extract($_POST);
}

As we can see from the above block of code, the careless extract()
call is made after a majority of the important variables used in
the application are loaded, thus making them vulnerable to being
easily overwritten. In short, by submitting the variable(s) of the
attackers choosing a malicious user could easily influence many
important variables, and function calls.

Solution:
Thanks to Jonathan Angliss and the SquirrelMail team for a prompt
resolution to this vulnerability. In regards to the updated files

http://www.squirrelmail.org/download.php

The latest version of SquirrelMail 1.4.5 can be downloaded from the
link above, and users are advised to upgrade as soon as possible.

Related Info:
The original advisory can be found at the following location

http://www.gulftech.org/?node=research&article_id=00090-07142005

Credits:
James Bercegay of the GulfTech Security Research Team

Problem Description:

The SquirrelMail PHP package is vulnerable to a number of cross-site
scripting problems, most of which were reported by Martijn Brinkers.
If an attacker could get a user to read a specially-crafted email or
using a manipulated URL, they could execute arbitrary scripts running
in the context of the victim’s browser, which could lead to cookie
theft, compromise of the user’s webmail, etc.

The updated packages have been patched to correct these problems.

References:

http://cve.mitre.org/cgi-bin/cvename.cgi?name=CAN-2005-1921

Updated Packages:

Corporate 3.0:
183b7a7c227551f918d7492460bb6b3e corporate/3.0/RPMS/squirrelmail-1.4.2-11.1.C30mdk.noarch.rpm
d518ad049ece85134416192604c02d2e corporate/3.0/RPMS/squirrelmail-poutils-1.4.2-11.1.C30mdk.noarch.rpm
88b3c9159a1b186057f3b858a3533e26 corporate/3.0/SRPMS/squirrelmail-1.4.2-11.1.C30mdk.src.rpm

Corporate 3.0/X86_64:
8fdd9a1cc0ae5ccbbff200a1a3120fdd x86_64/corporate/3.0/RPMS/squirrelmail-1.4.2-11.1.C30mdk.noarch.rpm
0453dd30fcc737a436dac03191ab44be x86_64/corporate/3.0/RPMS/squirrelmail-poutils-1.4.2-11.1.C30mdk.noarch.rpm
88b3c9159a1b186057f3b858a3533e26 x86_64/corporate/3.0/SRPMS/squirrelmail-1.4.2-11.1.C30mdk.src.rpm

To upgrade automatically use MandrakeUpdate or urpmi. The verification
of md5 checksums and GPG signatures is performed automatically for you.

All packages are signed by Mandriva for security. You can obtain the
GPG public key of the Mandriva Security Team by executing:

gpg –recv-keys –keyserver pgp.mit.edu 0×22458A98

You can view other update advisories for Mandriva Linux at:

http://www.mandriva.com/security/advisories

If you want to report vulnerabilities, please contact

security_(at)_mandriva.com