_______________________________________________________________________________ Nomad Mobile Research Centre A D V I S O R Y www.nmrc.org hellNbak [hellnbak@nmrc.org] 27May2001 _______________________________________________________________________________ Platform : Windows 2000, Windows NT Application : Specter IDS [www.specter.com] Severity : Low Synopsis -------- 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 SP1 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. Solution/Workaround ------------------- 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. Comments/Theory --------------- 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 completely. 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! ***** _______________________________________________________________________________