Home    |    View Topics    |    Search    |    Contact Us    |   



Category:   Application (Security)  >   SPECTER Intrustion Detection System Vendors: (NETSEC)
SPECTER Intrusion Detection System Can Be Made to Consume All CPU Resources By Remote User Actions
SecurityTracker Alert ID:  1001621
SecurityTracker URL:
CVE Reference:   GENERIC-MAP-NOMATCH   (Links to External Site)
Date:  May 27 2001
Impact:   Denial of service via network
Exploit Included:  Yes  
Version(s): 4.5, 5.0
Description:   Nomad Mobile Research Centre announced a vulnerability in the SPECTER honey pot intrusion detection system that allows a remote user to cause the system to consume all CPU resources.

Specter reportedly opens a number listening ports and will supply a remote user with fake banner information.

It is reported that Specter does not detect an Nmap stealth scan (the -sS option) and allows remote users to correctly identify the operating system that Specter is running on.

When a remote user initiates many telnet connections to port 23 of a Specter host, different fake banners will be returned, which may raise suspicions of a remote user planning an attack.

When a remote user initiates multiple full Nmap scans on a Specter host, the Specter engine will consume all CPU resources while attempting to generate alerts for the administrator.

Testing was reportedly performed with the following configuration :

Windows NT Server 4.0
Service Pack 6a + a ton o hot-fixes
Specter IDS 4.5, and 5.0 [5.5 is latest version - not tested]

Windows 2000
Specter IDS 4.5 and 5.0

Impact:   A remote user can cause the Specter host to consume all CPU resources.
Solution:   No solution was available at the time of this entry.
Vendor URL: (Links to External Site)
Cause:   Resource error
Underlying OS:  Windows (NT), Windows (2000)

Message History:   None.

 Source Message Contents

Subject:  *


                          Nomad Mobile Research Centre
                                 A D V I S O R Y
                          hellNbak []


                              Platform : Windows 2000, Windows NT
                           Application : Specter IDS []
                              Severity : Low


Specter IDS - which is really a honeypot - can be exploited remotely to
consume all available CPU resources by using some very simple methods.
Additionally, other issues with Specter IDS have been discovered.

Tested configuration

Testing was done with the following configuration :

Windows NT Server 4.0
Service Pack 6a + a ton o hot-fixes
Specter IDS 4.5, and 5.0 [5.5 is latest version - not tested]

Windows 2000
Specter IDS 4.5 and 5.0

Problem(s) Reported

Specter is a honeypot of sorts that is supposed to log and alert admins
via email when the machine with Specter installed on it is hit with a port
scan or basic port connect requests.  Specter sets up a number listening
ports and supplies the remote attacker with fake banner information.

The first issue, is very simple and almost laughable.  Specter does not
detect an Nmap stealth scan (the -sS option).  Not only does Specter not
detect these scans, the O/S identification feature correctly identifies
the O/S that the product is running on.

The second issue, also a lame one, is found by initiating Telnet sessions
to one of the listening Specter ports.  For example, TCP 23 - Telnet
reports a fake banner when Specter is enabled and of course, there
is actually no service behind the port.  Telnet to this same port
ten (10) times and six (6) out of ten (10) times you will receive a
different fake banner.  Obviously, an attacker would be tipped off that
this is some sort of honeypot system.

The last issue - again a lame one - is when a full Nmap scan is performed
on the box running Specter.  In particular, multiple (2 or 3) Nmap scans
will cause the Specter engine to consume all CPU resources while
attempting to generate alerts for the administrator.  Additionally,
constantly port scanning a Specter enabled machine will flood an
administrators mailbox with hundreds of Sepcter alerts that are very low
in detail and will essentially blind the administrator to any real issues.


The latest version of Specter has not been tested.  Vendor cooperation has
been low.  I guess the simplest work around is, don't run Specter.  See
rant below.


OK, I know this is a very lame advisory and almost not even worth the text
it is typed with.  But, I have noticed a few networks, mostly in Europe
running Specter.

I also have noted that these issues have been reported to the vendor by at
least two other individuals.  In talking with the vendor, I was also told
that there are multiple other, more serious issues, with earlier versions
of Specter and the engine piece of the software had to be re-engineered

The vendor cooperation was very spuratic and they were more worried about
where/how I obtained their software to test than the actual issues.  They
also made a comment. "So what, you can crash a honeypot, what does it
matter?" which I actually agree with to a point depending on your use of a
honeypot.  Honeypots as a research tool are valuable.  Specter as a
research tool is useless and I question its value as any kind of security
feature or attack deterrant.

Not really security issues I guess, but more bugs.  Users of the software
should know that this product does not enhance the security of anything.

Disclaimer -

This advisory contains findings in an extended lab environment.  The
opinions expressed in this advisory are those of hellNbak only.

***** This advisory will not be sent to Bugtraq.  I do not support a
mailing list that is part of a business model and is used to make others
rich! *****


"I don't intend to offend - I offend with my intent"


** TO UNSUBSCRIBE, send the command "UNSUBSCRIBE win2ksecadvice"
** FOR A WEEKLY DIGEST, send the command "SET win2ksecadvice DIGEST"


Go to the Top of This SecurityTracker Archive Page

Home   |    View Topics   |    Search   |    Contact Us

This web site uses cookies for web analytics. Learn More

Copyright 2021, LLC