Author Topic: XSS Vulnerabilities in Google.com found!  (Read 3236 times)

0 Members and 1 Guest are viewing this topic.

Offline deadly7

  • 42
  • x86
  • Hero Member
  • *****
  • Posts: 6496
    • View Profile
XSS Vulnerabilities in Google.com found!
« on: December 21, 2005, 09:47:15 pm »
First off, I DID read this.

Quote
//=====================>> 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.
[17:42:21.609] <Ergot> Kutsuju you're girlfrieds pussy must be a 403 error for you
 [17:42:25.585] <Ergot> FORBIDDEN

on IRC playing T&T++
<iago> He is unarmed
<Hitmen> he has no arms?!

on AIM with a drunk mythix:
(00:50:05) Mythix: Deadly
(00:50:11) Mythix: I'm going to fuck that red dot out of your head.
(00:50:15) Mythix: with my nine

Offline iago

  • Leader
  • Administrator
  • Hero Member
  • *****
  • Posts: 17914
  • Fnord.
    • View Profile
    • SkullSecurity
Re: XSS Vulnerabilities in Google.com found!
« Reply #1 on: December 22, 2005, 05:44:08 pm »
Yet another thing that websites have to do to protect IE users, eh?  How annoying. :)

Offline Newby

  • x86
  • Hero Member
  • *****
  • Posts: 10877
  • Thrash!
    • View Profile
Re: XSS Vulnerabilities in Google.com found!
« Reply #2 on: December 22, 2005, 05:50:23 pm »
Quote
Google solved the aforementioned issues at 01/12/2005, by using
character encoding enforcement.
- Newby
http://www.x86labs.org

Quote
[17:32:45] * xar sets mode: -oooooooooo algorithm ban chris cipher newby stdio TehUser tnarongi|away vursed warz
[17:32:54] * xar sets mode: +o newby
[17:32:58] <xar> new rule
[17:33:02] <xar> me and newby rule all

I'd bet that you're currently bloated like a water ballon on a hot summer's day.

That analogy doesn't even make sense.  Why would a water balloon be especially bloated on a hot summer's day? For your sake, I hope there wasn't too much logic testing on your LSAT. 

Offline iago

  • Leader
  • Administrator
  • Hero Member
  • *****
  • Posts: 17914
  • Fnord.
    • View Profile
    • SkullSecurity
Re: XSS Vulnerabilities in Google.com found!
« Reply #3 on: December 22, 2005, 06:00:47 pm »
Quote
Google solved the aforementioned issues at 01/12/2005, by using
character encoding enforcement.

That means it can happen to other sites.  And if I'm not mistaken, it only affects Internet Explorer.  So yeah, it's like I said.. :)