Neohapsis is currently accepting applications for employment. For more information, please visit our website www.neohapsis.com or email firstname.lastname@example.org
From: hellNbak (hellnbakNMRC.ORG)
Date: Sun May 27 2001 - 12:27:59 CDT
Nomad Mobile Research Centre
A D V I S O R Y
Platform : Windows 2000, Windows NT
Application : Specter IDS [www.specter.com]
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.
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]
Specter IDS 4.5 and 5.0
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
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
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.
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
"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"
SEND ALL COMMANDS TO: listservlistserv.ntsecurity.net