[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <468470F5.5010008@susam.in>
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