Antivirus Software Turned Upside Down

Stop Virus Attacks: Antivirus software exists because viral code and malware exist. Malware signature databases coupled with antivirus (a/v) software provide what I'll call
"matter of fact, after the fact" security. It is a matter of fact that bytes matching an a/v vendor's malware signature must have malicious potential resembling a known virus, worm, Trojan, or other code analyzed in the past by the a/v software vendor and labeled as harmful. While false positives do occur in practice, a irus scanner wouldn't be useful if it constantly failed to distinguish between malware and user data or desirable code. Therefore, a/v software becomes the best proof, in practice, that particular bits are hostile.

Antivirus software vendors are in the business of selling virus signature updates. They sell content more than software, and it is content updates that drive
their profits. Updates to virus definitions occur after the fact, so everyone is always out-of-date and must keep paying in order to feel protected. This
makes for a good business, but it doesn't make for very good security. In fact, it's completely backwards. Think about it for a moment, why should anyone go through the expense and the trouble of keeping a running list of all bad code ever encountered? We can prove that something is good just as easily as we can prove that something is bad, but publishing a list of all known good software wouldn't be very profitable. Few people would ever have a need for the entire database. Most people would have no need for updates unless they planned to install more software.

Restricting the execution of code by a CPU to a small list of known good programs that the owner of the computer chooses to trust would basically
kill the antivirus industry. Such a deny-first security policy would give computer owners the kind of control over their boxes that the introduction of
automobile ignition keys gave to early motorists. The fact is that today's computers are still designed to accommodate arbitrary drivers as though the absence of security is a feature demanded by the marketplace.

This brings to mind the purportedly true story of the evolution of the automobile seatbelt. Consumers apparently resented the addition of seatbelts, and
manufacturers didn't want to install them because they gave the impression that there was danger involved in driving a car. Compared to the seatbeltless horse or bicycle, a car with a seatbelt looked scary, and car manufacturers weren't in the fear business, they sold convenience and other delightful things. Whether this version of automotive history is indeed accurate, the point is still valid:

Computing can't continue without seatbelts. We should not let our CPUs continue to execute whatever happens to come along each day. If you've ever tried to assemble a list of the processes normally executed by one of your Windows boxes, so that you might be able to spot a suspicious process that wasn't there before, you've probably realized that a malicious process can come and go faster than the Windows Task Manager will refresh. And Task Manager doesn't bother to keep a record of past program executions, so you'll only spot a suspicious process in this way if it happens to be long-lived or if you audit process execution at just the right time. Putting aside for a moment the obvious need for better low-level hardware-based controls over code execution, is there really any reason for Windows to allow programs to execute without first requiring the end-user or an administrator to authorize them in advance using a simple software control?

If we add even the simplest software seatbelt to the boxes we drive every day, we can turn antivirus software upside down, replacing it instead with
anti-software software. Not unlike the anti-driver purpose served by automobile ignition keys, or the anti-death purpose served by seatbelts, we must redesign our infosec safety precautions around the idea that the bad things that can happen are worse than the protections we must have to guard against them. Nobody would accept an out-of-date list of ways in which one can die in an automobile in lieu of a seatbelt, so why do we accept that an out-of-date list of bad code is a viable way to protect ourselves while we drive a computer?

To complete what turned out to be a three-part-series on using hash algorithms for code authentication and containment, I offer a working prototype of a
software seatbelt for Windows (available online at ftp://ftp.wdj.com/pub/webzip/newsletters/20031017sec_listing.txt ). The last two articles in this newsletter laid the foundation for forensic hash sets produced using the MD5 or SHA-1 hash algorithms and comprehensive, full-file hash digests as a replacement for digital signatures. Software vendors should communicate hash sets to users, and users should assemble and periodically verify hash sets of code modules installed on Windows boxes.

But we also need runtime verification of hashes against our trusted hash sets. That's what the prototype available from download is designed to accomplish, albeit very crudely. The best way for runtime hash verification to occur is doubtless with the assistance of hardware enhancements to CPU and motherboard architecture. No add-on, after-the-fact technique to inject hash verification (or antivirus scanning, for that matter) into Windows will ever be as good as a simple kernel modification. Still, the code provided in the download isn't a complete waste of time. I've been using a precursor to this code for a while, without the hash verification feature, and feel that it gives a valuable log of executable modules that are invoked on a box, if nothing else. By adding hash code profiling and verification based on the work shown in the last two newsletters, this code begins to look more promising--at least as a source of ideas and code.

The code in the download compiles into a DLL. If you prefer to use the MD5 hash algorithm instead of SHA-1, simply adjust the value of the ALGORITHM #define as shown. Installation is done by placing a copy of the binary in the Windows System directory and editing the following Registry value located in the specified HKLM\Software Registry key. Type the name of the DLL without its path when you edit or create the "AppInit_DLLs" Registry value.

HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Windows\AppInit_DLLs

Next, create a folder under the Windows System directory named "AppInitProfile" such as: c:\winnt\system32\AppInitProfile
Finally, place an empty text file in the AppInitProfile directory named "ProfileMode." The presence of this file indicates that the code should operate in
profile mode rather than protect mode. No process will be terminated while the ProfileMode file is present. Instead, each process that launches and that links either statically or dynamically with user32.dll will generate a corresponding text file in the AppInitProfile directory. The hash code of the executable module responsible for creating the process is stored, with winsha1sum-compatible formatting, for later use. Delete, or rename, the ProfileMode text file to switch to protect mode, where any executable module not previously profiled will be hashed, logged in a text file beginning with the word BLOCKED, and its process will be abruptly terminated. Although there are many limitations to the AppInit_DLLs feature of user32.dll (you can read more about them with a search through the Microsoft Knowledge Base) there is certainly nothing wrong with having a little more control over the code that executes under Windows. And having a record of code that executed in the past, or tried to execute and was blocked, is as basic to information security as any safety feature in a car is to driving, and arriving alive, when you're on the road.

Download the source code for the DLL at ftp://ftp.wdj.com/pub/webzip/newsletters/20031017sec_listing.txt
---------------------------------------------------------------------
Jason Coombs works as forensic analyst and expert witness in court cases involving digital evidence. Information security and network programming are his areas of special expertise. He can be reached at jasonc@science.org. Read previous newsletters online at http://www.windevnet.com/newsletters.
---------------------------------------------------------------------