COMMAND

	KeyManager Issue in ISS RealSecure on Nokia Appliances

SYSTEMS AFFECTED

	RealSecure Network Intrusion Detection (NIDS) Version 6.0
	 (Build 6.0.2001.141)

PROBLEM

	hellNBak     found     following,     as     published      by      NMRC
	[http://www.nmrc.org/InfoAnarchy] :
	

	 Synopsis

	 --------

	

	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
	components.
	

	

	 Details

	 -------

	

	When you install RealSecure on any platform a file named  ISS.ACCESS  is
	created and  used  for  various  configuration  settings  including  the
	following lines;
	

	

	--ISS Access 6.0--

	[\\];

	[\\Roles];

	[\\Roles\\KeyAdministrator\\];

	[\\Roles\\KeyAdministrator\\machinename_username\\];

	[\\Roles\\KeyAdministrator\\starscream_skank\\];

	[\\Roles\\MasterStatusManager\\];

	

	

	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.
	

	

	 Mitigating Factors

	 -------------------

	

	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.
	

	

	 Tested configurations

	 ---------------------

	

	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.
	

	

	 Vendor Response

	 ---------------

	

	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

	

	<SNIP>

	

	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.

	

	<SNIP>

	

	-----------------------------------------

	

	

	 Update (22 March 2002)

	 ======

	

	hellNBack added exploit details :
	

	I simply set my machine name to starscream and my user  to  skank  I  am
	able to connect and push new keys generated by my console.
	

	You can connect via the console and root access on the Nokia box is  not
	an issue. The console connects to the control chanell and allows  me  to
	push new keys down using the deployment wizard which then allows  me  to
	set my new console as  the  \"master  controller\"  and  gather  alerts,
	modify policied etc...
	

	

	1.)	Install RealSecure IPSO using the Nokia Voyager web tool.

	2.)	Install REalSecure Console to NT Box

	3.)	Connect and configure Console as key manager

	4.)	Install another box as the REalSecure console and name this box

	Starscream and create a username skank.

	5.)	Login as skank launch the console and attempt to connect to the

	Nokia box.

	

	

	From  here  you  should  be  able  to  connect  to  the  Nokia  box   as
	starscream_skank is already a keymanager.
	

	

SOLUTION

	 Patch

	 =====

	

	RealSecure for Nokia 6.0 Build 6.0.2001.141d

	

	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 line:
	

	[\\Roles\\KeyAdministrato\\starscream_skank\\];
	

	If you installed the IPSO manually and turned on authentication you  are
	unaffected but should probably remove the line anyways.
	

	

	 Comments/Rants

	 --------------

	

	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........  :-)

	

	

	 Greetz

	 ------

	

	Thanks to Ring Zero for bringing this issue to the attention of ISS.

	

	

	 Copyright

	 ---------

	

	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

	commercial endeavour.