Google Re-authentication Bypass with SID and LSID cookies
Monday, 2 July 2007Google 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-22.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/ 
 
Original advisory: 
 http://susam.in/security/advisory-2007-06-29.txt 
  Share this content: 
   
   
   
 
 |