On Tue, Mar 3, 2009 at 3:28 PM, Biz Marqee <[email protected]> wrote: > This was 2 years well spent... NOT! > > Seriously what is with all these people popping up releasing advisories that > are absolute SHIT? Is it to try and get jobs or what?
I worry it's only going to get worse as the economy gets worse. > > > On Tue, Mar 3, 2009 at :55 AM, ISecAuditors Security Advisories < > advisories at isecauditors.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/ >> > > _______________________________________________ > 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/
