Date: Fri, 29 Jun 2007 08:09:49 +0530
From: Susam Pal <susam@...am.in>
To: full-disclosure@...ts.grok.org.uk
Subject: Re: Google Re-authentication Bypass with SID and
 LSID	cookies

In the 'Vulnerability' section, the URL to the previous advisory is 
mentioned as:-

http://susam.in/security/advisory-2007-06-21.txt

This is incorrect. The correct URL is:-

http://susam.in/security/advisory-2007-06-22.txt

Regards,
Susam Pal
susam@...am.in
http://susam.in/

Susam Pal wrote, On Friday 29 June 2007 07:46 AM:
> 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@...am.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/

Powered by blists - more mailing lists