COMPUTER FORENSIC ANALYSIS — COMPUTER CRIMES AT THE COMPUTER
U NIX AND O THER N ON DOS C OMPUTERS
We’ve discussed DOS computers. There is really only one difference between a DOS computer and a Unix computer for the purposes of forensic analysis. We need to get the Unix equivalent of SafeBack to get a physical image. Because there are various types of Unix, there is more than one approach to analyzing Unix disks.
In this section we will discuss three different approaches. The first uses SafeBack and is the preferred approach. The second and third use Unix utilities, available with most Unix versions. We won’t go into the details of these two because they are not consistent in their results. They merit a brief mention, though, if only as a warning to avoid them. We’ll begin with the preferred approach.
Start by removing the Unix drive from the computer, if the computer is not an Intel-based PC. Some versions of Unix, such as BSD and Linux, run in an Intel environment. This allows you to boot to DOS from your prepared SafeBack floppy, just as you would with a DOS PC. If your Unix is not running on an Intel platform (for example, Sparc or RISC platforms), you will need to place the Unix disk in an Intel PC. For Intel-based Unix, keep the disk in the Intel machine for the moment. Use great care to ensure that, when you boot this machine, you boot from your floppy. If the CMOS is set to boot the hard drive first, you may corrupt the Unix disk. When you boot, the PC may not, immediately, recognize your Unix disk. Go to SETUP, using whatever mechanism your PC provides during boot, and configure the CMOS to recognize the new drive. Generally, it is a good idea to remove other drives and make your Unix drive the primary hard drive. Remember that you must set the jumpers on the drive itself to make it the primary master drive. You may need a reference from the manufacturer to know how to set the jumpers of the drive correctly.
Once you have the PC recognizing the new drive, reboot to the DOS floppy containing SafeBack and any drivers needed to run your Jaz or other backup device. Perform your physical backup exactly as you would on a DOS PC. This creates the bitstream backup that you can use to create a mirror.
You can also perform a direct physical copy using SafeBack, bypassing the bitstream backup. The result of this disk-to-disk copy is that you create a mirror in one very fast step. I don’t recommend using this process until you have a good bitstream backup on separate media to use as evidence, in case something goes wrong later in the process.
Performing a direct copy can be tricky because of the quirks of drives and PCs. The rule of thumb is that you must configure the CMOS to recognize a primary master drive and a primary slave. The drives themselves must have their jumpers set accordingly. The source drive contains your original data. The destination will contain your mirror. The destination must be at least as big as the source. Bigger is okay. We use 10 GB disks for mirrors. Most DOS machines will only recognize the first 8.3 GB without special drivers. Forget the drivers. If the mirror needs them, it will get them from the source disk.
Another caution, when performing a direct mirror, is that you can sometimes become confused as to which disk is the source and which is the target. Be sure you know which disk is which. The consequence of not knowing is that you overwrite
your original disk. Perform your mirror using the SafeBack COPY selection. You may have to set the ADJUST PARTITIONS selection to “NO” to get the mirror to work. If “AUTO” works, however, that is your best choice. You can use this same direct mirror technique on any disk, not just Unix.
Once you have a mirror of the Unix disk, you’ll want to begin analysis. Because the concepts of slack and unallocated space differ on different Unix versions, we’ll look at analysis two ways. First, we’ll assume we have an Intel, compatible Unix, such as BSD or Linux.
There is about an even chance that your mirror will boot. Unix uses several different drivers to boot the machine. These drivers must be compatible with the hardware devices on the computer running from the disk. If your disk contains a boot sequence using drivers that are not compatible with the computer into which you placed the disk, the machine may not boot. In this case, your best bet is to have a bare bones version of the same Unix on another disk and boot from that disk. Let’s examine that a bit more carefully; we will use this technique again if we must analyze a non-Intel Unix.
First, we need a bare bones version of the same Unix on a hard disk set up as the primary master. Free BSD and Linux are easy to get and set up. I keep backups of these two Unix variants available to restore to a machine in my lab so that I can perform this procedure. Set up your mirror as the primary slave. Boot from your good Unix disk and configure the device drivers to recognize your mirror as a second (or other) volume. For example, if your boot disk is set up using the device driver /dev/hda1, you would set up (assuming that there are no other volumes, such as a swap volume, in use) your mirror as /dev/hda2. The exact procedure varies with the distribution of Unix you are using.
Once you have rebooted and your mirror is being recognized, you can wander through it and analyze it as if it were on its original computer. If your Unix is not Intel-based (such as Sun, IBM, or H-P), use the same procedure as above but load your mirror as the second (or greater) volume in a platform with which it is com- patible. For example, if you have mirrored a Solaris disk, place it in a Sparc computer as a second (or greater) volume. Make sure that the computer is using the same Unix to boot from.
If your Unix is Intel-based, you usually can perform slack and unallocated space analysis exactly as you would with a DOS PC. Always run your tools from a bootable DOS floppy. When you use the NTI Text Search tool, you must use it to examine physical space. If you boot from a DOS floppy, you will not be able to see the logical Unix drive. Text Search will see the physical sectors and will include all slack and unallocated space. You can also take your mirror of non-Intel-based Unix variants, place it in an Intel PC, and use Text Search in the same manner as if you were looking at DOS. Again, use the physical search because DOS will not recognize the Unix formatting.
There are other ways to examine Unix computers. For example, Unix machines use swap space on hard drives in much the same ways that Windows uses swap space. Swap files must be recovered, if available, by booting the machine from an image of the kernel. This is usually done from a CD-ROM distribution of the
operating system, or an “emergency” boot disk. The swap file must then be offloaded to an external device to avoid causing any change to the actual disk.
Some analysts suggest the use of the CPIO or DD utilities to create images of Unix disks. While those approaches can work, we recommend against them since results can be inconsistent and testifying about the procedure difficult. Because these two utilities vary somewhat in their functionality from Unix to Unix, your best bet is to control your environment using tools you know. Law enforcement specialists have successfully used the SafeBack approach and it has a history of acceptance in court cases.
The contents of Unix memory can be of additional use to the investigator. Unix memory can be accessed by causing a core dump and analyzing the resulting file. We discuss core dump analysis in more detail later in this book. Another way to get an image of the memory is to take a copy of the kmem (kernel memory) file, or its analog, on Unix versions, which do not use kmem. The only drawback is that kmem may not have in it the most current memory information.
Remember that the image offers us three sets of test possibilities. First, it is an environment that we can examine as if it were the original machine. Second, we can actually operate the system to see how it responds without damaging the original environment. Finally, we can examine the ASCII portions of the file prior to restoring it to a test machine. This allows such analysis as keyword searching in an open ASCII environment.
We can treat NetWare machines similarly. As long as we have a DOS partition, we can run our tools and see, if not use, the NetWare partition. NT, using a non- DOS partition, may offer some challenges. Booting DOS and then trying to see the NT partitions is not successful unless the machine has been set up using a standard DOS file allocation table (FAT).
We can, of course, still create a mirror image, but we may not be able to do much with it in terms of restoring to a test machine. We can, however, still analyze the ASCII image file to some extent. This is where smart keyword search engines, such as TEXTSEARCH, shine for us. We can also run the TEXTSEARCH tool against the physical sectors of the mirror.
If the NT machine has been configured using NTFS (the NT File System), as most NT computers are, there is a freeware utility called NTFSDOS that allows us to read the disk as if it were DOS. We boot the NT computer from a DOS floppy containing NTFSDOS and our TEXTSEARCH tool. Once we have booted, we run NTFSDOS. It will assign a virtual drive letter to the DOS representation of the NT file system. On a simple machine, with just an A:\ (floppy) and C:\ (hard drive), the virtual DOS disk representing the C:\ drive will be D:\.
Once we have that representation, we can run TEXTSEARCH on the physical sectors and retrieve a great deal of information. However, remember that NT does not, even with NTFSDOS, use slack and unallocated space the way DOS does; therefore, limitations exist on what you can see.
Another hint: the NT passwords are contained in the c:\winnt\win32\config\sam file. If you boot DOS and run NTFSDOS, you can access this file, copy it to your floppy, and run a password cracker, such as L0phtCrack, against it to recover passwords.