[NEWS] Nokia IPSO Script Injection Vulnerability
From: SecuriTeam (support_at_securiteam.com)
To: email@example.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.
- - - - - - - - -
Nokia IPSO Script Injection Vulnerability
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
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).
* IPSO version 3.5
* IPSO version 3.6
* IPSO version 3.7
* 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
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.
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:
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. [...]"
(Additional details are listed at:
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
By submitting raw (non-URL encoded) http requests to the device an
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
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
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...
The original advisory is available at:
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: firstname.lastname@example.org
In order to subscribe to the mailing list, simply forward this email to: email@example.com
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.