Message-Id: <20070629042401.E170A383@lists.grok.org.uk>
Date: Thu, 28 Jun 2007 21:29:04 -0700
From: "Susam Pal" <susam@...am.in>
To: full-disclosure@...ts.grok.org.uk
Subject: Re: Google Re-authentication Bypass with SID and
 LSID cookies

Reply to Debasis 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. 
> 

As mentioned in the advisory, this *doesn't* require a user to provide 
his/her password to re-authenticate. The presence of valid cookies is enough 
to bypass re-authentication. This is a potential threat on a shared system 
where a user is logged out to failed authentication during a session and he 
assumes it to safe the shared PC at that point and leaves. Another user can 
simply put a valid URL such as the http://www.gmail.com/ or 
https://www.google.com/accounts/ManageAccount and access his account without 
his password. 

An ideal design would be to disable the session unless the user 
re-authenticates himself successfully with his password. This has been 
explained in the 'Solution' section. 


>> 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.

Agreed. 'Impact' section describes only the possible consequences. In future 
if an XSS flaw is discovered in future, the XSS flaw can be used to hijack 
sessions and the information in this advisory would allow you to have access 
to the compromised account even after the user has *logged out* or has been 
logged out. 

> 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. 
> 

As explained in the previous advisory, the vulnerability is that an attacker 
can access a compromised account even after the user has *logged out*. 
Logging out should *terminate* or *disable* the session at the server side 
which is not happening in case of Orkut sessions. 

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

> On 6/29/07, Susam Pal <susam@...am.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@...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