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 [EMAIL PROTECTED] 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 > [EMAIL PROTECTED] > 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/
