Home page logo
/

fulldisclosure logo Full Disclosure mailing list archives

Re: Google Re-authentication Bypass with SID and LSID cookies
From: "Debasis Mohanty" <debasis.mohanty.listmails () gmail com>
Date: Fri, 29 Jun 2007 09:02:29 +0530

comments inline

At this stage,
ideally the session should be disabled and should be enabled only after
the user re-authenticates himself. However, the session associated with
SID and LSID cookies remain alive at the server side.

That *certainly* doesn't prove a threat. It is by-design and still
would require a user to provide his/her password to re-authenticate.


Therefore, it is
not safe to abandon the session at this stage. An attacker can set these
cookies in his browser and access the compromised account by visiting
http://www.gmail.com/, https://www.google.com/accounts/ManageAccount,
etc.

The point here is if someone can get access to other user's cookie and
session details then there are *other* urgent things to be attended.
Impersonating other users by setting stolen cookie or replaying
sessions is not something new and will work in almost all web
applications. This is because in most cases the cookies or session
details are not bounded to the machine's IP or MAC. So it is easy to
reuse them from some other machine. One most popular way attackers can
have access to these details is by exploiting the user via XSS. There
are also other ways to achieve it but the most preferred attack vector
always remain XSS.

also in your other post
(http://susam.in/security/advisory-2007-06-22.txt) you have talked
about a session management error which again looks highly misleading.

If you run your post through Google, I'm sure they will have similar
opinion. Here is their contact detail -
http://www.google.com/contact/security.html


regards,
-d



On 6/29/07, Susam Pal <susam () susam in> wrote:
Google Re-authentication Bypass with SID and LSID cookies

This document is also available at:-
http://susam.in/security/advisory-2007-06-29.txt

Researcher:-
Susam Pal

Type:-
Session management error

Timeline:-
2007-06-21 - Discovered
2007-06-22 - Reported to vendor
2007-06-29 - Public disclosure

Summary:-
During a session, while performing a crucial operation Orkut requires a
user to authenticate himself with his password in order to prevent
walk-by attacks. If a user fails this authentication, he is redirected
to login page, where he needs to re-authenticate himself. However, at
this stage the session is not disabled temporarily at the server side.
This can be exploited by an attacker to bypass re-authentication.

Description:-
On successful Orkut login, the following cookies are set:-

1. Domain: .www.orkut.com
    Cookie: orkut_state
2. Domain: .google.com
    Cookie: SID
3. Domain: www.google.com
    Cookie: LSID

The security flaw associated with the first cookie has already been
explained in http://susam.in/security/advisory-2007-06-21.txt

The second and the third cookies are responsible for another flaw which
is described in this advisory. In the login page of Orkut, the login
form appears from google.com in an inline frame and the form inputs are
submitted back to google.com. Hence these cookies are set for the domain
google.com and www.google.com.

Vulnerability:-
When an Orkut user fails to authenticate himself during a session (say,
while deleting a community), the user is redirected to a login page
where the user has to enter his password to login again. At this stage,
ideally the session should be disabled and should be enabled only after
the user re-authenticates himself. However, the session associated with
SID and LSID cookies remain alive at the server side. Therefore, it is
not safe to abandon the session at this stage. An attacker can set these
cookies in his browser and access the compromised account by visiting
http://www.gmail.com/, https://www.google.com/accounts/ManageAccount,
etc.

Impact:-
1. If an attacker manages to steal the SID and LSID cookies of the user,
    he can gain access to the compromised account even after the user has
    been logged out as described in 'Vulnerability' section.
2. In case of unsuccessful authentication during a session, when the
    user finds himself logged out, if he leaves the browser unattended,
    a trespasser can login to his account simply by accessing a valid URL
    for his account as mentioned in 'Vulnerability' section.

Solution:-
When a user fails to authenticate himself during a session as described
in 'Vulnerability' section, then the session associated with him should
be disabled at the server side. The session should be enabled only after
the user successfully authenticates himself.

Prevention:-
1. When a user fails to authenticate himself during a session and he is
    logged out for re-authentication as described in 'Vulnerability'
    section, he must re-authenticate himself to log in and then logout
    properly by clicking the 'Logout' link. This deletes the session
    associated with SID and LSID cookies at the server side.
2. A user logged into Orkut, Google, GMail, etc. should not run any
    untrusted JavaScript or program to prevent the cookies from being
    stolen.

Disclaimer:-
This document is published with the hope that it will be useful, but
without any warranty; without even the implied warranty of
merchantability or fitness for a particular purpose. The information in
this advisory should be used for education, research, experimentation,
bug-fixes and patch-releases only. The author shall not be liable in
any event of any damages, incidental or consequential, in connection
with, or arising out of this advisory.

Revision History:-
2007-06-29 - Initial release

Contact Information:-
Susam Pal
susam () susam in
http://susam.in/

_______________________________________________
Full-Disclosure - We believe in it.
Charter: http://lists.grok.org.uk/full-disclosure-charter.html
Hosted and sponsored by Secunia - http://secunia.com/


_______________________________________________
Full-Disclosure - We believe in it.
Charter: http://lists.grok.org.uk/full-disclosure-charter.html
Hosted and sponsored by Secunia - http://secunia.com/


  By Date           By Thread  

Current thread:
[ Nmap | Sec Tools | Mailing Lists | Site News | About/Contact | Advertising | Privacy ]
AlienVault