mailing list archives
NMRC Advisory - KeyManager Issue in ISS RealSecure on Nokia Appliances
From: hellNbak <hellnbak () nmrc org>
Date: Wed, 20 Mar 2002 18:04:55 -0500 (EST)
I N F O R M A T I O N A N A R C H Y 2 K 0 2
Nomad Mobile Research Centre
A D V I S O R Y
hellNBak (hellnbak () nmrc org)
Platforms : Nokia Appliances
Application : RealSecure Network Intrusion Detection (NIDS)
Severity : Medium
This advisory documents an issue when using RealSecure NIDS on Nokia
appliances. It seems that during development, a test system named
"starscream" and test user "skank" was used as it was left behind in the
IPSO image in the ISS.ACCESS file as a KeyManager.
There is the potential that this information, depending on the
configuration of the NIDS, can be used to push new pubkey files to the
sensor, reconfigure or take control of the NIDS daemon and daemon
When you install RealSecure on any platform a file named ISS.ACCESS is
created and used for various configuration settings including the
--ISS Access 6.0--
The Roles\KeyAdministrator line is used to determine the machine name and
username of what ISS calls the KeyAdministrator. This user has the ability
to manage the keys used when communicating with the daemon.
This line is added during installation but the second line,
\startscream_skank is present in the IPSO as a "default". This does not
exist on any other platform or in the HIDS RealSecure product.
The vulnerability lies in the fact that as a KeyAdministrator, you
essentially can control the functions of the daemon including what events
it monitors for and how it alerts. It is important to understand that
this is only possible if RealSecure is configured to rely on the console
system to push the necessary public keys to it, which is the default
method of installation.
If the Nokia Voyager web applet is used to install this IPSO you do not
have the option to turn on authentication. Authentication in this case
means that the administrator must, via sneakernet or other secure channels
manually copy the necessary keys to the sensor.
The RealSecure NIDS sensor listens on two TCP ports, TCP-2998 is used to
control the daemon while TCP-901 is used to monitor events. Obviously,
you do not want to allow these ports to pass through your firewall. In
an ideal situation, the NIDS sensor should have a shadow interface
enabled to monitor and only communicate back to the console via a private
mangement network that is not accessable by any other devices.
It is also a good idea to not allow the NIDS sensor to accept new public
keys directly from a console but only when copied manually to the system.
RealSecure 6.0 was tested, it is unknown if other versions are effected.
ISS is aware of the issue and has removed this line from version 6.5.
The version of Nokia software does not make a difference although this
does not exist on any other platform such as Windows NT, or Solaris.
Thanks to Ring Zero for taking this one to the vendor for me. Here is
a portion of the email received back from ISS.
---------- Forwarded message ----------
Date: Wed, 20 Mar 2002 12:22:05 -0500
From: "Lamb, Kris (ISS Atlanta)" <KLamb () iss net>
To: 'Ring Zero' <ringzero () www nmrc org>
Subject: RE: Anomaly in RealSecure
As far as the starscream_skank, that was a QA box from the product
development team that was accidentally left in the iss.access when IPSO
shipped. We have already addressed this with Support and all customers
have been notified to remove that entry. It was removed in IPSO 6.5.
If you are running RealSecure version 6.0 and below you need to simply
stop the NIDS daemon and edit the ISS.ACCESS file and remove the following
If you installed the IPSO manually and turned on authentication you are
unaffected but should probably remove the line anyways.
No NMRC advisory, let alone one written by me would be complete without
some sort of rant so here it goes;
Responsible Disclosure and the IETF: I applaud Chris Wysopal and Steve
Christey for their efforts in attempting to bring a standard to
vulnerability disclosure. I may not have agreed with the entire document
but at least these two guys were willing to take input from the community
as a whole. I hope the standard finds a home and eventually evolves to
something acceptable by the research community as a whole. Trust me folks
-- we do not want government, or any vendor to do this for us. Too bad
the IETF doesn't have the balls or brains to deal with this issue.
ISS: While their products can use some improvement, especially when
attempting to implement it in a large mixed environment I am impressed
with the level of cooperation and support being offered by ISS. I take
back most of the bad things I have ever said about you........ :-)
Thanks to Ring Zero for bringing this issue to the attention of ISS.
This advisory is Copyright (c) 2002 NMRC - feel free to distribute it
without edits but fear us if you use this advisory in any type of
To be posted on: NMRC.ORG web site, VulnWatch, and Bugtraq
"I don't intend to offend, I offend with my intent"
hellNbak () nmrc org
- NMRC Advisory - KeyManager Issue in ISS RealSecure on Nokia Appliances hellNbak (Mar 21)