|
|
|
|
| |
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). |
| |
Credit:
The original advisory is available at: http://www.fishnetsecurity.com/CSIRT/disclosure/Nokia/advisory.public.FN2003111101.txt.
The information has been provided by Evans, Arian.
|
| |
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.
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).
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...
|
|
|
|
|
|
|
|
|
|
