[NEWS] Nokia IPSO Script Injection Vulnerability

From: SecuriTeam (support_at_securiteam.com)
Date: 11/12/03

  • Next message: SecuriTeam: "[NT] Vulnerability in Microsoft Word and Microsoft Excel Could Allow Arbitrary Code to Run (MS03-050)" 
    To: list@securiteam.com
Date: 12 Nov 2003 20:15:58 +0200

    The following security advisory is sent to the securiteam mailing list, and can be found at the SecuriTeam web site: http://www.securiteam.com
    - - promotion

    The SecuriTeam alerts list - Free, Accurate, Independent.

    Get your security news from a reliable source.
    http://www.securiteam.com/mailinglist.html

    - - - - - - - - -

      Nokia IPSO Script Injection Vulnerability
    ------------------------------------------------------------------------

    SUMMARY

    Nokia Network Voyager is "an SSL-secured, web-based element management
    interface to Nokia IP Security Platforms. Enabled via the Nokia IPSO
    operating system (OS), Network Voyager is used to configure and monitor
    individual Nokia IP Security Platforms. Through the simple, yet powerful
    user interface of Network Voyager, users can point any web browser at an
    individual Nokia IP Security Platform and immediately manage the device".

    FishNet Security has performed a partial application security assessment
    on the Nokia Network Voyager Interface, along with full vulnerability
    research regarding discovered vulnerabilities. An application security
    assessment is the process of identifying security risks and baselining the
    security posture of a specific application. A full assessment may take
    weeks or months of man-hours depending on the complexity of the
    application.

    Due to time and complexity of assessing and entire platform, only a
    partial assessment has been performed on the Nokia Network Voyager
    application. FishNet Security's assessment team does offer comprehensive
    evaluation identifying threats, vulnerabilities, and suggesting solutions
    to specific security issues. In addition, FishNet Security's assessment
    services team performs vulnerability research on previously unknown
    vulnerabilities discovered during the course of assessment activities.
    With this information, an organization can design and implement a strategy
    to reduce overall risk exposure to its application(s).

    DETAILS

    Vulnerable systems:
     * IPSO version 3.5
     * IPSO version 3.6
     * IPSO version 3.7

    Immune systems:
     * IPSO version 3.7 Build31
     * IPSO version 3.6 FCS13
     * IPSO version 3.5.1 FCS10
     * IPSO version 3.5 FCS22

    It is possible to inject script into Nokia Network Voyager to remotely
    gain root access to the platform. The remote root is both passive and
    conditional. Actions that can be taken include (1) creating admin
    accounts, (2) setting password on admin accounts (thus enabling them), (3)
    disabling daemons for products running on the platform like firewall or
    NIDS, (4) reboot platform to come up with a new configuration.

    Basically, the Network Voyager interface functions are mostly POSTable
    forms, so with a little creativity you can script code that will
    automatically post any form.

    Passive: The code you inject will not execute until a client with
    administrative privileges logs into the Network Voyager interface. Code
    execution is dependent upon the client (web browser), hence the
    designation 'Passive'.

    Conditional: If vendor recommended guidelines have been followed to secure
    the Nokia IP Security platform, this vulnerability is difficult to
    exploit. However, with Nokia's shipping default configuration, this
    vulnerability is trivial to exploit.

    Remediation:
    FishNet Security notified Nokia of this vulnerability on 10.27.2003.
    Nokia's response was immediate after we supplied proof of concept and full
    documentation. Nokia worked swiftly to produce fixes and provided them to
    our team for follow-up testing.

    For Best Practices to securing Nokia Network Voyager, which also
    significantly mitigate this risk, please see:
    <http://www.fishnetsecurity.com/CSIRT/disclosure/Nokia/Securing.Nokia.Network.Voyager.pdf> http://www.fishnetsecurity.com/CSIRT/disclosure/Nokia/Securing.Nokia.Network.Voyager.pdf.

    From Nokia's release:
    "Nokia Enterprise Solutions wishes to inform you of the immediate
    availability of the following IPSO versions:
     
    IPSO v3.7 Build31
    IPSO v3.6 FCS13
    IPSO v3.5.1 FCS10
    IPSO v3.5 FCS22
     
    Please log into http://support.Nokia.com to read the release notes and
    retrieve these new images. [...] These releases address a security issue
    described as a Network Voyager Script Injection vulnerability, which is
    described in Resolution 18356. Nokia strongly recommends that all
    platforms be upgraded to the latest releases of these IPSO versions. If
    this is not possible, then please follow the workarounds described in
    Resolution 18356. [...]"

    Findings:
    (Additional details are listed at:
    <http://www.fishnetsecurity.com/CSIRT/disclosure/Nokia/Nokia.Voyager.Threat.Details.pdf> http://www.fishnetsecurity.com/CSIRT/disclosure/Nokia/Nokia.Voyager.Threat.Details.pdf).

    The Nokia Network Voyager access log web interface
    (http://nokiaappliance/cgi-bin/httpdaccesslog.tcl) vulnerable to Script
    Injection which allows an unauthenticated user the ability to create admin
    level users, reboots the device, and essentially performs any other
    administrative-level functions through the use of malicious JavaScript.

    By submitting raw (non-URL encoded) http requests to the device an
    unauthenticated user is able to insert malicious JavaScript directly into
    the voyager access log. When this access log is viewed by an authenticated
    administrator via the web interface the malicious code is executed by the
    client web browser and a variety of functions can be performed on the
    device.

    The easiest way to submit a request to the Voyager interface is by using a
    local web proxy. While a telnet client or even netcat could be used,
    negotiating syntax and the potential need for an external SSL wrapper
    makes this tedious. For the Windows platform, Achilles and Spike Proxy are
    both free tools that could be utilized for this, and automate SSL
    negotiation if SSL is in use. We use SPI Dynamics SPIProxy, a commercial
    tool (part of WebInspect) and Spike Proxy on Windows. For Linux or BSD,
    there are a variety of open source tools that can be used, from HTTPush,
    to the SPIKE toolkit, to Ettercap, to Firebird browser extensions, etc.

    The important thing is that you submit a raw request to the HTTP or HTTPS
    interface that gets logged. As for the script injected, you can use your
    imagination and basically go through the Voyager interface and TCL scripts
    and postulate what all forms can be automatically posted, scripted actions
    taken, etc. Virtually anything can be done with a script that the user can
    perform via a browser inside the Nokia Network Voyager interface. Other
    tools that may be utilized to exploit various threat vectors are packet
    crafters and packet injectors, TCP session ID predictors, and various man
    in the middle utilities to inject commands into existing TCP sessions.
    After the malicious code is successfully injected into the logs, the HTTPd
    access logs will then need to be viewed by a user with administrative
    privilege to execute the code. There are a number of conditions under
    which an administrator would normally review the HTTPd access logs, but in
    addition, a malicious attacker will likely attempt various forms of either
    service interruption (e.g. DDoS) or social engineering to stimulate the
    administrator to review the access logs. Code could also be injected into
    the logs to alert the malicious attacker that the logs had been viewed. A
    simple HTTP GET to the malicious attacker's web server would leave an
    entry in that server's web logs that the malicious attacker could monitor
    for. A tool like SWATCH could be used to automatically monitor these logs
    for entries from poisoned Nokia IP Security Platforms, to automatically
    alert the malicious attacker when his scripts had been executed and a new
    system was vulnerable to exploitation. In this way notification of
    successful system compromise could be automated.

    Sample attack scenario, step-by-step:
    1. Malicious entity identifies Nokia IP Security platform belonging to
    Company X and identifies that the Nokia Network Voyager interface is
    listening on 172.16.1.1 port 443 with no client access restrictions.

    2. Malicious attacker injects script into the device including script to
    create a new administrative user, set the password, and do an HTTP GET to
    a third, external web server with a unique, identifiable GET string.

    3. Malicious attacker calls Company X, identifies himself as Nokia
    support, and asks for the firewall administrator. Attacker explains Nokia
    is calling customers to warn them of the new xipocsic threat to the
    platform, and encourages them to review their HTTPd access logs as soon as
    possible (in addition to other logs, of course).

    4. Company X Firewall administrator reviews Nokia Network Voyager HTTPd
    access logs, finds nothing resembling the xipocsic threat, and closes
    their browser. Unbeknownst to the administrator, depending on the
    scripting ability of the malicious attacker, several pop-under boxes have
    executed script and closed creating another administrative user, setting
    the password and enabling the user, and doing an HTTP GET to an external
    web server.

    5. Malicious attacker has SWATCH monitoring the logs of the external web
    server used for this hacking, and automatically kicks off an alert via
    email when it notices a certain type of HTTP GET in the logs. This alert
    is all the attacker needs to know they have *another* compromised platform
    waiting for them to exploit.

    If SSL were enabled, or interface access restrictions enabled, there would
    be many more steps to injecting the code, including predicting TCP session
    ISN, SSL Session ID, and blindly spoofing source IP until a valid source
    IP (allowed to connect) could be located and used for injection. For a
    remote attacker, using forged packets would mean this was all done quite
    blind, and almost impossible to tell when successful. For an attacker
    local to the network allowed to connect (or a closely adjoining network)
    it would be much easier to exploit this. In addition to being able to
    inject packets into valid TCP sessions, they could spoof IPs from a valid
    source and also potentially capture the responses to the spoofed packets,
    meaning the work wouldn't be blind at all...

    ADDITIONAL INFORMATION

    The original advisory is available at:
    <http://www.fishnetsecurity.com/CSIRT/disclosure/Nokia/advisory.public.FN2003111101.txt> http://www.fishnetsecurity.com/CSIRT/disclosure/Nokia/advisory.public.FN2003111101.txt.

    The information has been provided by
    <mailto:Arian.Evans@fishnetsecurity.com> Evans, Arian.

    ========================================

    This bulletin is sent to members of the SecuriTeam mailing list.
    To unsubscribe from the list, send mail with an empty subject line and body to: list-unsubscribe@securiteam.com
    In order to subscribe to the mailing list, simply forward this email to: list-subscribe@securiteam.com

    ====================
    ====================

    DISCLAIMER:
    The information in this bulletin is provided "AS IS" without warranty of any kind.
    In no event shall we be liable for any damages whatsoever including direct, indirect, incidental, consequential, loss of business profits or special damages.

  • Next message: SecuriTeam: "[NT] Vulnerability in Microsoft Word and Microsoft Excel Could Allow Arbitrary Code to Run (MS03-050)"

    Relevant Pages