HostedDB - Dedicated UNIX Servers

-->
Internet Security Professional Reference:Viruses
Previous Table of Contents Next


Master Boot Record Viruses

The vast majority of Floppy Boot Record (FBR) viruses infect the hard drive’s Master Boot Record (MBR). In essence, the MBR virus is another form of the FBR virus that resides in the hard drive’s Master Boot Record rather than a floppy disk’s boot record. As with FBR and PBR viruses, the MBR must be loaded and executed during bootup before the virus can activate.

Master Boot Record infectors are much more common than Partition Boot Record infectors. Before a PBR virus can infect, it must look through the partition table to locate the active partition, then locate the boot sector for the active partition, and infect the boot sector. The MBR viral infection process is much less complex.

How the Master Boot Record Virus Gets Control

During hard drive bootup, the ROM BIOS boot program loads the MBR from the primary hard drive connected to the computer. It then verifies that the MBR has the proper signature at the end of the sector, and if so, transfers control to the MBR’s bootstrap program.

In an infected MBR, a viral bootstrap routine replaces the original bootstrap routine. The moment that the ROM BIOS boot program transfers control to the MBR bootstrap program, the virus gains control. The average MBR virus then installs itself as a memory-resident service provider, in the same manner as the FBR and PBR viruses (see fig. 15.17).


Figure 15.17  Bootup from hard drive with infected MBR.

Whereas the typical FBR virus attempts to infect the hard drive during bootup, the MBR virus has a different agenda. The MBR virus needs to use only the hard drive boot sequence to install itself as a resident driver, because it already resides on the hard drive.

How the Hard Drive MBR Becomes Infected

Assume that an infected floppy has been inserted into drive A: of the computer and a user reboots the computer. During floppy bootup, the ROM BIOS boot program loads the FBR into memory and checks the signature at the end of the boot record. If the signature matches, the bootstrap program in the FBR executes, launching the virus. The virus can then install itself as a memory-resident service provider. Finally, before the virus loads the original FBR and transfers control to the original bootstrap program, it attempts to infect the hard drive’s MBR.

The FBR virus loads the MBR of the first physical hard drive into memory. Next, it checks to see whether the MBR’s bootstrap routine already is infected. If so, the virus aborts the infection process and proceeds to boot the floppy disk. If not, it overwrites the existing MBR with an updated copy. The updated copy of the MBR usually contains the viral bootstrap routine, as well as the partition table from the original MBR.

Most MBR viruses maintain an exact copy of the original partition table in the viral MBR, because DOS and many applications need this information to determine the logical drives available on the computer. Some viruses might not maintain a valid partition table in the infected MBR, however. Anytime DOS or other programs request the hard drive’s MBR, the resident service provider installed by this type of virus hides the infection and provides the requesting program with the original, valid copy of the MBR and partition table.

Like the FBR and PBR virus infections, the typical MBR virus needs to save a copy of the original MBR elsewhere on the drive. Later, after the computer boots from the infected hard drive and the virus installs itself as a resident service provider, the virus needs to load the original MBR and transfer control to its bootstrap routine. The original MBR bootstrap routine can then load the active partition’s PBR and the bootup continues normally.

Some viruses don’t store the original MBR elsewhere on the drive; in this case, the virus contains the same bootstrap functionality as the original MBR. The virus loads and transfers control to the PBR of the active partition entirely on its own, completely bypassing the original MBR’s bootstrap program.

The disk partitioning software used on most hard drives (FDISK) leaves one full track of unused sectors following the MBR on the hard drive. The average MBR virus selects one of the sectors to store the original MBR, because these sectors are unused on most systems. Many of the Stoned viruses, including Stoned.Michelangelo, place the original MBR sector in track 0, head 0, sector 7 (recall that the Master Boot Record is located in track 0, head 0, sector 1).

Usually, a virus strain stores the original MBR at the same location in this slack area. The virus program is written so that it always stores and retrieves the MBR from a given sector in this slack space.

How and When the Master Boot Record Virus Infects New Items

The MBR virus installs itself as a memory-resident service provider in the same manner as its FBR and PBR cousins. As the disk service provider, anytime the user or operating system attempts to access any disk drive, the virus is given control of the computer. In the most common scenario, the virus waits for accesses to the floppy drives and attempts to infect floppy disks anytime they are used for other, legitimate purposes.

Potential Damage the MBR Virus Can Do

MBR viruses store the original Master Boot Record somewhere in the slack space of the hard drive’s first track because the virus assumes without checking that this space is available for its own devious purposes. Unfortunately, this isn’t always the case. Several different disk management and access control packages store their own bootstrap programs and data within this slack space. If the virus blindly saves a copy of the original MBR in this area, it can overwrite the disk driver and cause system crashes on subsequent bootups.

Stealth viruses may not maintain a copy of the original partition table within the infected MBR. As long as the virus is memory-resident, as it would be, for example, if the computer was booted from the hard drive or an infected floppy disk, this should not pose a problem for the user. The resident service provider installed by the virus monitors all disk requests to the hard drive MBR, and provides any requesting program with the original, uninfected MBR and partition table. When DOS or other programs examine the partition table, they are given the proper information and function normally.

If the user boots up from an uninfected floppy disk and tries to access the hard drive, however, doing so proves impossible. The virus cannot hide the modifications to the partition table in the MBR, because it isn’t resident. If the infected MBR doesn’t contain an appropriate partition table, DOS denies access to the drive. The Stoned.Empire.Monkey virus exhibits this behavior.


Previous Table of Contents Next