Message-ID: <00e301c60631$112995e0$0100a8c0@nuclearwinter>
Date: Wed Dec 21 13:18:38 2005
From: fd at g-0.org (GroundZero Security)
Subject: XSS vulnerabilities in Google.com

are we starting to post vulnerabilities in specific websites now rather than daemons/clients etc. ?
i mean there are thousands of websites which are vulnerable to xss,sql injection or worse because of their
custom scripts. in my opinion this should be posted to the website owners if you feel like, but its of no real use
to the security community. hm another thing i'm wondering about is, is it legal to just audit a website without
asking the owner if its ok ? how will he know its not a real attack? ok as for xss there cant be much harm done
to the server itself, but what if, for example, you cause a DoS through testing certain variables for overflows ?

  ----- Original Message ----- 
  From: Watchfire Research 
  To: full-disclosure@...ts.grok.org.uk 
  Sent: Wednesday, December 21, 2005 1:58 PM
  Subject: [Full-disclosure] XSS vulnerabilities in Google.com


  //=====================>> Security Advisory <<=====================//

   

  ---------------------------------------------------------------------

  XSS vulnerabilities in Google.com

  ---------------------------------------------------------------------

   

  --[ Author: Yair Amit , Watchfire Corporation http://www.watchfire.com

  --[ Discovery Date: 15/11/2005

  --[ Initial Vendor Response: 15/11/2005

  --[ Issue solved: 01/12/2005

  --[ Website: www.google.com 

  --[ Severity: High

   

  --[ Summary

   

  Two XSS vulnerabilities were identified in the Google.com website, 

  which allow an attacker to impersonate legitimate members of Google's 

  services or to mount a phishing attack.

  Although Google uses common XSS countermeasures, a successful attack 

  is possible, when using UTF-7 encoded payloads.

   

  --[ Background

   

  Google's URL redirection script

  ---------------------------------------------------------------------

   

  The script (http://www.google.com/url?q=...) is normally used for 

  redirecting the browser from Google's website to other sites.

   

  For example, the following request will redirect the browser 

  to http://www.watchfire.com :

        - http://www.google.com/url?q=http://www.watchfire.com 

   

  When the parameter (q) is passed to the script with illegal format 

  (The format seems to be: http://domain), a "403 Forbidden" page 

  returns to the user, informing that the query was illegal. 

  The parameter's value appears in the html returned to the user.

   

  If http://www.google.com/url?q=USER_INPUT is requested, the text in 

  the "403 Forbidden" response would be:

        - "Your client does not have permission to get URL 

        /url?q=USER_INPUT from this server."

        

  The server response lacks charset encoding enforcement, such as:

  * Response headers: "Content-Type: text/html; charset=[encoding]".

  * Response body: "<meta http-equiv="Content-Type" (...) charset=[encoding]/>".

        

  Google's 404 NOT FOUND mechanism

  ---------------------------------------------------------------------

   

  When requesting a page which doesn't exist under www.google.com, a 

  404 NOT FOUND response is returned to the user, with the original 

  path requested.

   

  If http://www.google.com/NOTFOUND is requested, the following text 

  appears in the response:

  "Not Found

  The requested URL /NOTFOUND was not found on this server."

   

  The server response lacks charset encoding enforcement, such as:

  * Response headers: "Content-Type: text/html; charset=[encoding]".

  * Response body: "<meta http-equiv="Content-Type" (...) charset=[encoding]/>".

   

  --[ XSS vulnerabilities

   

  While the aforementioned mechanisms (URL redirection script, 

  404 NOT FOUND) escape common characters used for XSS, such as <> 

  (triangular parenthesis) and apostrophes, it fails to handle 

  hazardous UTF-7 encoded payloads.

   

  Therefore, when sending an XSS attack payload, encoded in UTF-7, the 

  payload will return in the response without being altered.

   

  For the attack to succeed (script execution), the victim.s browser 

  should treat the XSS payload as UTF-7.

   

  --[ IE charset encoding Auto-Selection

   

  If 'Encoding' is set to 'Auto-Select', and Internet-Explorer finds a 

  UTF-7 string in the first 4096 characters of the response's body, 

  it will set the charset encoding to UTF-7 automatically, unless a 

  certain charset encoding is already enforced. 

   

  This automatic encoding selection feature makes it possible to mount 

  UTF-7 XSS attacks on Google.com.

   

  --[ Solution

   

  Google solved the aforementioned issues at 01/12/2005, by using 

  character encoding enforcement.

   

  --[ Acknowledgement

   

  The author would like to commend the Google Security Team for their 

  cooperation and communication regarding this vulnerability.

   

   



------------------------------------------------------------------------------


  _______________________________________________
  Full-Disclosure - We believe in it.
  Charter: http://lists.grok.org.uk/full-disclosure-charter.html
  Hosted and sponsored by Secunia - http://secunia.com/
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.grok.org.uk/pipermail/full-disclosure/attachments/20051221/4deb43ab/attachment.html

Powered by blists - more mailing lists