accesses since August 1, 2006
copyright notice
accesses since August 1, 2006
THE JURASSIC DESKTOP
In the Jurassic Period of desktop computing (circa 1980), the typical end-user was likely a techie as well. This was the pre-IBM PC days when a desktop computer came in pieces and had to be assembled after delivery. We're not talking plugging a keyboard PS/2 connector into a KVM switch – we're talking about linking the disk controller to the motherboard and the disk to the disk controller with connectors that weren't always marked correctly and instructions that might not have coincided with the parts list. Those were the days, my friend! The smell of overloaded power supplies, the sticky feel of melting circuit boards, the metal-against-metal sounds of the ‘massive' 10 MB disk drives. No end-users ate quiche in those days – it was Mountain Dew and Pringles! For those of you who want to enjoy a momentary flashback, check out http://nelsonit.net/~jon/info-cpm/1982/11/.
Where is this headed?, I hear you cry. Well, in the Jurassic Period there was a tool that was simply indispensable: a disk editor (aka hex editor), the most popular version of which was Peter Norton's Disk Editor that some of you may remember was bundled with Norton's Utilities for DOS and later Windows 3.1. In those days disk editors were the “Swiss Army Knife” for desktop computer enthusiasts enabling the user to do everything from modifying the operating system to thwarting copyright protection. As I'm writing this I have to smile at some of the ideas that were proffered as breakthroughs at the time. One of which was to write data on disks beyond track 80 on the old double-sided, double-density floppy disks so that the disk controller, but not the operating system, could read the data. In retrospect, it is difficult to imagine how anyone with an IQ above room temperature could come up with something this silly as a means to prevent piracy, but for awhile it looked like this technique might become a standard!
In any event, this Swiss Army Knife has now evolved to the modern computer forensics toolsets. Although the sophistication of the modern tools like Encase, X-Ways Forensics, Forensics Tool Kit, etc. are light years beyond the original disk editors, the principle remains the same: to enable the user to customize the presentation of binary information read directly from a disk, bit-by-bit.
COMPUTER FORENSICS IS MORE THAN THE WHOLE ENCHILADA
Figure 1 is a typical Windows Explorer view of the contents of a memory stick that I have plugged into the USB port of the computer I'm using to type this column. One can see a folder named <G&L> (the directory for the word and graphic files I'm editing), <STunnel-SSL> which contains a software VPN installer that I use from time to time, the <System Volume Information> that Bill want's us to retain, and two files: a setup file for the latest version of the packet sniffer, Ethereal, and the draft of a book that I'm working on. That's the whole enchilada. Or is it?
Figure 1: Windows Explorer View of the Contents of a Memory Stick
It turns out that there's a lot of data that isn't reported in Windows Explorer. Look at the list in Figure 2. The “$_” files are called metadata files in Window's New Technology File System (aka NTFS, or the file system used in Windows 2003 server, XP, etc.), and are used by the operating system to manage the disk environment. The following table is provided for the curious. Skip this Table if you're having a bad hair day or are prone to migraines.
Figure 2: Basic Forensics View of the Contents of a Memory Stick
$MFT = the Windows Master File Table for this disk (memory sticks are disks as far as Windows is concerned)
$MFTMirr = a partial backup of the $MFT that is maintained in case the original gets corrupted
$BadClus = list of unusable clusters on the disk surface(s)
$AttrDef = file attribute definitions
$Volume = the name of the disk volume, volume serial number, creation date, etc.
$Secure = unique file security descriptors for all files within a volume
$Boot = the drives boot sector
$BitMap = a map of the directory content
While we're on this topic, I should mention that Windows hides this NTFS metadata from the Windows APIs (Application Programming Interfaces). You may not remember this, but it may some day come back to bite you! The reason has to do with the way that Windows interfaces with software applications. The fact that Windows hides NTFS metadata means that no Windows API will ever be able to read and compare the NTFS metadata report of the disk's contents with the actual disk contents. Think about this for a moment. Applications programs can't actually get the lowdown on the disk metadata, they have to rely on the periodic summary of this metadata as reported by the operating system. This is the disk management equivalent to the mark-to-market accounting method that helped make Enron the corporate giant that they are today.
ROOTKITS ARE NOT TOOLS TO UNCLOG YOUR SEWER
Why is this a problem? In a word, “Rootkits.” Rootkits are logic bombs that take over control of the operating system. They hide themselves by capitalizing on the fact that application programs can't actually recover disk metadata, but have to rely on the reports of the operating system. If a rootkit could just intercept and substitute a false report every time an application asked for specific data, it could hide itself forever. And that's just what rootkits do – and the way that Windows metadata is handled make them especially difficult to uncover. For that reason, the most effective rootkit discovery systems on Windows work by comparing the NTFS metadata reported by Windows with that recovered by some other operating system like Linux that doesn't have to rely on the Windows API.
If you want to get really, really scared, do a Google search on “root_040” – a widely available rootkit for Windows. Remember what you told your toddlers: “Look with your eyes not your fingers (on the mouse).” Word to the wise: don't download anything!
For the sensible, risk-averse executives among you, here's a quote from the root_040 author:
“NT ROOTKIT has stateless TCP/IP stack. It works by determining the state of the connection based on the data within the incoming packet. This works fine for all tests we have performed on the local segment. This has not yet been tested over great distances of Internet.”
“The ROOTKIT has a hardcoded IP address to which it will respond. As delivered, this IP address is 10.0.0.166 – if you have a client machine that is configured with a 10.X address, it should be able to telnet to the rootkit. Keep in mind that the rootkit is using raw connections to your ethernet so it can do some amazing things. First you will notice that the target port does not matter. You can telnet to any port and it will work. Second – you will notice that multiple people can log into the rootkit at once. The sessions are not kept separate but testing has shown that it seems to work quite well as long as two people aren't typing commands at exactly the same time.”
In other words, the author is pointing out just how democratic this rootkit is: once the computer is infected, everyone can hack into it. And to make it easier for the neophytes, you can even gain access without knowing how it works. The quote above is not hubris: root_040 actually delivers on these promises.
COMPLETING THE CIRCLE
Well, writing the previous three sections has sure been therapeutic for me. I hope you've had some fun reading it. As Jimmy Durante used to say, “It's time to get to the purnt.”
Figure 3 shows a disk that has been sanitized by one of the popular disk cleaning products. You can find these on the shelves of most electronics stores under labels like “disk cleaner,” “disk wiper,” “data destroyer,” and so forth. Note the residue remaining after the disk sanitizer has done its magic. Arthur Andersen shredded the Enron data better than this.
Figure 3: Forensics View of Disk Residue after “Sanitization”
What went wrong. Well, it has to do with our old friend, Windows metadata In a recent test that we conducted in my lab, only one disk sanitizer effectively dealt with disk residue in the metadata files, the most critical of which is $MFT and $MFTMirr. While the larger data files were removed, the smaller files and all of the file names and data paths were left behind untouched. Ask yourself if you would like all of the filenames on organization's Windows workstations made public. Leaving telltale signs of intellectual property, trade secrets, legal documents and the like behind is an invitation for snooping.
Let me be quite specific about the vulnerability of inadequate disk sanitization to your organization: the data that most modern disk sanitizers leave behind may be recovered by any commercial or shareware/open source forensics tool with under a half-dozen mouse clicks.
So it might be worth reviewing the specific procedures your organization uses to sanitize disks with your CSO. Are you really sure that your disks are sanitary?
Hal Berghel is (among other things) Director of the Center for Cybersecurity Research (ccr.i2.nscee.edu) and Co-Director of the Identity Theft and Financial Fraud Research and Operations Center ( www.itffroc.org ). He also owns a security consultancy, Berghel.Net.