From thegnome@NMRC.ORG Tue Sep 14 16:02:52 1999 From: Simple Nomad X-Sender: (Unverified) To: jericho@attrition.org Date: Tue, 14 Sep 1999 18:55:42 -0400 Subject: NMRC Advisory: HackerShield on Windows NT _______________________________________________________________________________ Nomad Mobile Research Centre A D V I S O R Y www.nmrc.org Simple Nomad [thegnome@nmrc.org] 10Sep1999 _______________________________________________________________________________ Platform : Microsoft NT 4.0 SP5 Application : Hackershield v1.1 Severity : High Synopsis -------- The HackerShield product creates a local account during installation with a password that is not machine specific. This includes the HackerShield demo product available via the Internet. Tested configuration -------------------- Testing was done with the following configuration : Microsoft NT 4.0 Server and Workstation with SP3 (no additional hotfixes) Microsoft NT 4.0 Server and Workstation with SP5 (with Csrss, LSA-3, RAS, WinHelp hotfixes) HackerShield Product Version 1.10.1105, Package Version 11 Product Background ------------------ Hackershield (http://www.bindview.com/products/HackerShield/) -- originally developed by Netect (http://www.netect.com/), but recently purchased by Bindview (http://www.bindview.com) -- is a security scanner that scans for security flaws on Windows and Unix platforms. It is very similar and compares nicely to the feature set of ISS' Internet Security Scanner and NAI's CyberCop. It allows both manual and auto-updates of new hack signatures, called RapidFire updates, as well as automated scanning sessions which allow a system administrator to define a schedule for scanning a set of network resources. The idea is to provide an automated method of keeping your systems fairly up-to-date from a security perspective by downloading new vulnerabilities and running pre-scheduled scans. This is fairly similar to the modern anti-virus model where you set your anti-virus software to automatically download new virus signature files from the anti-virus vendor's FTP site and then run the virus scan, except the automated updates come via PGP-signed email. Bug - Service User password is recoverable ------------------------------------------ To facilitate HackerShield automation of scanning, a Service User named NetectAgentAdmin$ is installed with local Administrator privileges on the scanning computer. Unfortunately, the password can be easily recovered. Since the advent of recent patches to Microsoft NT, recovery of Service User password information is a little harder. For example, pwdump will not recover the hash for NetectAgentAdmin$, but pwdump2 will. Users of L0phtcrack will not be able to dump this user, but using pwdump2 will get the following for this user (text is wrapped): NetectAgentAdmin$:1001:7a8754eda3b21376136260cc65a99030: \ 2d6156879a7f61fdddb10c96427483d7::: Being security conscious, the HackerShield folks at least made the password 14 characters, but the password is not machine-specific. The first 12 characters are np7m4qM1M7VT while the last two are non-printing characters. Due to the non-printing characters, L0phtcrack will not brute-force crack the password using the standard choices of character sets (although it should be possible to type in the alt codes into a custom character set -- we did not try this as the characters are still non-printing), but using Paul Ashton's code (posted to NTBugtraq August 9, 1997) it can be extracted as plaintext on an NT 4 SP3 workstation or server. The implications of this should be obvious -- a service user with a known password and local administrator rights is a prime target for intruders of NT systems. Depending on where the product is loaded in your organization, you have a potential vehicle for additional password recovery, trojan horse planting, and further compromise of the NT environment. Bug Conclusions --------------- If you have loaded the HackerShield product (including the demo) then you have installed the Service User, and the two services called HackerShieldAgent and HackerShieldSniffer. If this system is not physically secure, or has Server services running, you have the potential for compromise via the Service User. Solution/Workaround ------------------- Do not install HackerShield on non-physically secured systems. If you have loaded HackerShield onto an NT host only to perform a localhost scan, it is recommended you uninstall the product using the HSUninstall.exe program once you have completed the scan. Bindview has developed a patch for the Service User password to be machine specific. It can be downloaded from http://www.bindview.com/products/HackerShield/HS_Patch2.zip. In the Readme file with the zip, Bindview has a reference to the following page: http://www.bindview.com/products/HackerShield/HS_Patch2_advisory.html. Comments -------- We'd like to commend Bindview in their response to our contact. An email was sent to them with our concerns, giving them an opportunity to respond. The email was sent at 9:30AM on August 30, 1999 to a generic support address, and a real human being replied within an hour, and confirmed our findings later that day. They stated this is a bug as they never intended to have non-unique passwords for the NetectAgentAdmin$ account. The fact that Service Users' passwords can be recovered is reason enough to upgrade to the latest patches, although Microsoft has still not addressed the pwdump2 issue. Despite the fact that you have to be a local administrator to recover the hashes, it still illustrates the danger of using Microsoft's own authentication methods when trying to deliver a secured solution to NT. For this we would like to issue our strong distaste for Microsoft's built-in authentication measures, and how they are (un) protected. We do understand why Bindview (or technically, Netect) did it -- they are in the business of delivering products to market as quickly as possible -- but when you deliver a security product you must ensure that the product itself is secure. Personally, we like the anti-virus styled model as far as security scanners go, but if you build your security application on a shaky and flawed security model then your security application is only going to be as good as that flawed model. This scenario is probably in existence in any number of other products that use Service Users. Bindview is not alone here, we just happened to look at their product. _______________________________________________________________________________