PCHelp Tests LockDown 2000 2.0
Wednesday, 9 December 1998
Revised 26 January 1998
Note: I was earlier in error about the version number and that is the primary reason for this 26 Jan revison. This Lockdown, version 2.0 , was the one I first inspected, including the total contents of its very detailed helpfile instructions, at the time I wrote my first commentary about Lockdown. So it was first in line for testing.
A test and review of version 2.5.4 has been done as of July 1999. Versions up to 4.0 remain closely similar to 2.5.4 in functions and performance.
This test of 2.0 remains relevant and of interest. Version 2.0 is undoubtedly still in some use; and the claims for version 2.0 were substantially the same as those now made on the Harbor Telco sites.
The Test
I installed and ran LD2000 2.0. Its first action on startup was to display a dialog: "Lockdown 2000 System Check." It says, "Checking System..." and an indicator shows progress. Then it declares: "No Trojans Found."
There's no hint of this "trojan check" anywhere in the documentation for the program. Even a comprehensive text search for "trojan" and anything else relevant finds nothing. (So much for my reliance on that helpfile!)
It would appear that LD2000 2.0 does attempt to find trojans.
I shut down LD2000 and installed a default (non-configured) Back Orifice server. This is the widely-feared backdoor trojan. I then re-started LD2000. It yielded this dialog:
Then this:
It spotted the BO server. I chose to reboot, with thoughts of eating crow (I had earlier said I thought it would not).
On reboot, the trojan check again found the BO server and showed the same warning, and the same promise of removal and recommendation to reboot. The server had not been "removed from Windows start-up."
I rebooted again. Same result. Although LD2000 claimed to have removed the server, it had not done so.
I ran Regedit and found this:
As you see, the Back Orifice server's " .exe" entry remained where it was, untouched, and (this is rather funny) Lockdown had added its own brag to the Registry! There's an obvious but rather technical reason for this error; and an error it is. It is certainly not deliberate. The Registry assigns a default value to every key. It can be null, but it must be something. But it does not recognize this value by the name "Default." Someone has made a novice's error. They NAMED the value "Default" and rather than overwriting the default value, it created a new entry.
But let's be fair, Lockdown did sound the alert after all. The user may be frustrated, but at least he knows he's got BO. That's some help.
I tried another test. After removing the BO server and rebooting clean, I ran LD2000 again. It reported no trojans. Now, with LD2000 running, I again installed a default BO server.
The BO server installed uneventfully. LD2000 made no response.
I waited many minutes. Lockdown would not repeat its trojan search unless manually prompted, thusly:
Conclusion: Back Orifice in any form can be installed while LD2000 v2.0 is running and LD2000 will do nothing whatsoever about it until either its next restart, or the user manually performs a new trojan scan.
I got online. Using another machine, working via the Net for total realism, I accessed that BO server with the BO GUI client. I sent it a variety of commands, looked around on the drives for specified files, set up a redirect, telneted thru that redirect to a NetBus (trojan) server running on that second machine with success, set up a BO web server, and uploaded and downloaded files using that server. Not one peep from LockDown 2000. No indication of any activity. Nothing. It sat there monitoring resource shares, ignoring 100% of my activities.
I returned to the Lockdown machine, shut down LD2000 and re-started it. It did its trojan scan, and predictably, spotted the BO server as before. As before, it could not remove the server nor prevent it from running at next startup.
Conclusion: Lockdown is better than nothing where a default (non-configured) BO server is concerned. At least it sounds the alarm on startup. But it doesn't deliver as promised. LD2000 v2.0 does nothing on its own to detect or prevent a BO attack initiated while it runs.
Now I decided to get tricky. I configured a BO server with an illegal filename. As I have outlined here, this causes the BO server to behave a bit differently than usual.
I installed that BO server while LD2000 ran. As before, no response from LD2000. I accessed the server via the Net. I invaded that system using the BO trojan. I even shut down Lockdown using BO! By the way, the natural next act of any hostile hacker at this point would be to totally delete the Lockdown 2000 directory and remove what little protection his victim may once have had.
With that server still running, I then returned to the Lockdown machine, and re-started Lockdown. It did the System Check, and incredibly, it reported: No Trojans Found! I tried again. Same thing. All the while, my configured BO server was running happily and undisturbed.
Remember the above? When LD2000 found the default (unconfigured) BO server, it said:
If LD2000 were truly and fully checking memory, it would have found the second server. I can only conclude this is a misleading claim. Logic suggests the trojan check is not a scan of memory, but is limited to an inspection of the HKLM\...\Runservices key.
I tested the hypothesis. With no BO server running, I added an entry to the RunServices key as follows:
Then I re-ran LD2000. Nothing was detected. OK... So I placed the file " .exe" in the Windows\System directory.
I then ran LD2000 again. It found BO "in memory." Note the BO server was not running and therefore was not in memory.
This led me to another experiment. Clearly, Lockdown is inspecting the contents of the HKLM\...\RunServices Registry key, which is capable of executing a program at startup. There are two other Registry keys of which I know that will do the same thing. One of them is used by Lockdown itself. So I placed an entry in that key, pointing to a BO server that really existed. Here's that entry, right next to Lockdown's:
I ran Lockdown again. It found nothing! Is its inspection really limited to RunServices entries? So I rebooted, which caused the entry above to actually run the BO server. Lockdown fired up -- and found no trojans.
I checked with Wintop. The BO server was running happily. Again, as before, I got online and accessed that server from another online machine. This Back Orifice server was running, and was staunchly ignored by Lockdown.
Conclusion: Back Orifice can easily be set up to run undetected, continuously and with every reboot, while Lockdown 2000 v2.0 remains utterly oblivious of its presence. It can be freely accessed by a remote user without any protest from Lockdown.
I made this full log of the Back Orifice session; and tried some new things. It's a bit hard to read, but the log chronicles the following actions, all done from the remote machine using BO:
Wait! you say. NetBus v1.70 is brand new! What about the earlier versions?
Well, I tried them. I went back to the Lockdown machine and I loaded and unloaded, rebooted, ran Lockdown and re-ran it, while running NetBus version 1.53, version 1.60 and version 1.70. I ran them before and during Lockdown sessions. I ran two at a time. Lockdown 2000 v2.0 does not see NetBus in any version. It does not respond to any use of the server by a remote client.
Conclusion: NetBus and BO together probably account for 95% of all trojan attacks. Lockdown is useful only against some implementations of the BO trojan.
(Note: Later inspection of the Lockdown 2000 2.0 executable revealed that it contains absolutely no user feedback which identifies any other trojan than the Back Orifice server. The claim of trojan protection which was made for this product notably contained no mention of this rather severe limitation in its capablities.)
File Shares
What about monitoring and protecting shared resources? This is the central function claimed for Lockdown, and has been so ever since its inception as Hackerproof98.
First, with Lockdown running, I simply contacted shared resources on my Lockdown machine from one of the others on my household network. Lockdown sounded its alarm. I tried each resource. Same result every time.
On the Lockdown machine, I ran Netninja's Setup Trojan, which was and is specifically mentioned on the Lockdown site. This clever little program (I made some notes about it here) quietly creates a hidden system share when run, granting password-free access to drive C: to anyone on a share-enabled link who knows the shared resource is there.
Lockdown registered no protest when the Setup Trojan was run.
I rebooted. Still nothing. It was at this point that I realized something: Lockdown 2000 DOES NOT LIST SHARED RESOURCES. Unless a shared resource is contacted, it renders the user no information whatsoever about what resources are shared.
Lockdown 2000 v2.0 offers no means to view, change, add or delete shares and cannot alter or display settings, passwords or any other aspect of any shares. A brief look at 2.5 shows that this has changed in the more recent version, thankfully.
I deliberately configured my system to enable share access on the Dial-Up Adapter. This is the very misconfiguration that is the subject of many of the promotions for Lockdown. It is the "security hole" that is mentioned prominently on the Lockdown site.
Lockdown did not notice or respond to this change of the share status on the Dial-Up Adapter.
From another machine on the LAN I contacted that hidden system share which I had earlier created with the Setup Trojan, by mapping the drive on the second machine. Lockdown's siren went off. It correctly named the hidden share, C$, and named the machine that came calling. I repeated the process. Same result. I accessed files variously. Lockdown saw every contact.
For each contact, Lockdown said, "Kicked." Yet I saw no indication of having been "kicked" when working from the remote machine. It accessed the share apparently normally each time I moved, deleted, or otherwise accessed a file on the mapped drive.
I displayed many directory listings on my new F: drive. I transferred files both ways. Everything worked, and the connection was never effectively "Kicked;" and Lockdown at no time showed any current connections, except for logging the individual contacts. Drive F: was apparently still connected.
I transferred more files, and tried lots of things. I placed the user on Lockdown's Disconnect List. I tried repeatedly to disconnect the remote user using Lockdown's handy buttons, with apparent success on the Lockdown console but no evidence of any effect on the remote machine. I did all these same actions with ordinary, non-hidden shares with the same results. Full access, no apparent disconnect, lots of sirens.
This warranted further testing. From the second machine, I transferred a series of files of increasing size to and from the Lockdown machine; and I found the transfers began to be interrupted by Lockdown when they reached around a half megabyte in size.
My LAN runs, ostensibly, at 10MBits per second; which means it's taking Lockdown about half a second to act. In computer terms, this is an extremely slow response. On many LANs, a data rate of 100MBits is standard, which means file of someting like 5 megabytes would theoretically get by Lockdown before it could respond.
When my Windows 95 machines have a mapped drive which resides elsewhere on the network, they outwardly take no immediate notice of any disconnection, but simply re-establish the connection at need. If a file transfer has been successful and there's no further transaction, Windows ignores Lockdown's forced disconnection. Thus, from the viewpoint of the remote machine, Lockdown appears to do nothing; unless it actually interrupts the file transfer in process.
The dialup connection works in the same manner. But because a standard modem connection is typically very slow, Lockdown can successfully interrupt most data transfers. My testing was brief and I made no determination of what size files could be successfully accessed; but it intervened successfully on a few attempts to download files of no more than 30K or so.
However, the deletion of a file
is a very fast action. I created a dummy file. Over the dialup
link, I sent a simple one-line command:
del
\\[computer]\c\windows\delete.me
Lockdown responded with a siren, but the file was gone.
I was able to delete any file I pleased from the Lockdown-equipped machine via the modem link. I needed only know its name and location.
Incidentally, as I performed this test I found that Lockdown did a remarkably poor job of tracing those dialup contacts. Over the course of some dozen or so contacts, it obtained the "attacking" system's IP address just once.
Conclusions:
In Closing
The creators of Lockdown 2000 claim to be network security experts. In fact they do display detailed knowledge of some of the better-known vulnerabilities of Windows machines, even as they consistently overstate and sometimes misrepresent the nature of those vulnerabilites and the magnitude of the risks involved.
By their display of knowledge, masked though it is in marketing hype, they show clearly that they know enough so that they could, if they desired, have surely made Lockdown somewhere near effective as promised. That version 2.0 was so fatally flawed in so many ways is inexcusable.
Version 2.5 calls for additional tests before its merits can be properly assessed; but if it is based upon the model of 2.0 in any of the critical functions I tested above, it is at serious risk of betraying its users' trust.
In buying a security tool of this type, I offer this general advice: Look for products from established and recognized experts who make realistic claims for their software. Look for independent, informed comparisons with similar products by skilled reviewers. Don't allow alarming claims about security risks to stampede you into buying a product which may either fail to resolve those same risks or which is unnecessary to avoid them.
As I said originally, and this test I've done demonstrates, Lockdown 2000 2.0 is not a true firewall by any stretch. A firewall is a packet filter, a program which intercepts and examines incoming and outgoing data packets, and applies rules to the acceptance and forwarding of that data. Lockdown 2.0 does not function in this manner in any way whatsoever.
Aside from its flawed trojan detection, the primary function of Lockdown 2.0 is the monitoring of shared resources. Most ordinary Windows users don't have shared resources. No standalone Windows machine requires them and sharing needs not be enabled at all. And those who do share resources on a LAN need only ensure the dial-up link has sharing disabled and they'll usually have no reason to monitor anything!
The writers of the Lockdown site are incorrect when they say the shared-resources security issue issue is "new" and irresponsibly false to claim 60% of all Windows and NT machines are open to access! The actual problem has been known since late 1995, corrected in all Win95/NT versions since then, and has never applied to more than a small percentage of users.
The only significant category of persons who have any reason to use this product would be those on a moderate-to-large LAN who use share-level access, who share important resources AND who may share that network with untrusted users. If a noisemaker is worth $100 to a few such individuals, so be it. The product has that much merit.
Even if LD2000 delivered as promised, precious few people need even consider spending the money.
With the sole exception of its alarm-on-access feature (that's practically all it really does in the final analysis), every promised function of Lockdown 2000 (except the impossible claim of "total security") can be accomplished for free. Use of Windows' own built-in utilities such as Net Watcher and System Policy Editor, combined with the free anti-trojan BODetect together would out-perform Lockdown. Add to that any decent antivirus program and most people will enjoy adequate security against trojans and viruses alike, far in excess of Lockdown's capabilities.
Sharing inadvertently on the Dial-Up link? A single page of instructions takes care of any misconfigured share at the cost of a minute's work. A well-chosen password reduces the risk if for some reason you feel you MUST share on the public Net.
A hidden share? Just get Netninja's own ShareView. It safely displays all shares of all types and lets you unhide the work of the Setup Trojan. This Netninja guy isn't all bad. Lockdown can't even begin to do this.
If you already use Lockdown 2000 2.0, only do so while recognizing the limited nature of the service it provides; and place no trust at all in the outrageous and false claim of "total security."
The claims for Lockdown 2000 2.0 and now for its successor, v2.5, are so outrageous; so absolute is Lockdown in its promises of security; its website so calculatedly inaccurate in its presentation of the facts about the security risks this program purports to handle; that I frankly could never, ever recommend its purchase no matter how effective it is. Such impossible claims go beyond mere marketing hype to the point of dishonesty and deliberate misinformation. No product sold on such pretense warrants consumer support. But the product has undergone revision and may have improved. It does warrant further testing, so watch for my upcoming review of version 2.5. (That review is now done and may be seen here.)
 |
|