Malicious Mobile Code | O'Reilly Media

Content preview·Buy PDF of this chapter|Buy reprint rights for this chapter

Chapter 1 is an introduction to the world of malicious code and its authors. You will learn there is a lot more to the rogue program world than computer viruses and worms. The chapter discusses what malicious mobile code is and its classifications. It summarizes the very active virus-writing subculture and the laws written to protect us.

I had been called to a company because it appeared that one of their Windows 98 computers had been hacked. The computer was connected to the Internet and was used for web surfing and email. The only symptom they reported was a significant slowdown in processing. Sure enough, even though the PC had more than enough processor power to run its applications, it was running very sluggishly. The day before it had been a fast and responsive machine. Now, it seemed to struggle with every mouse click and screen change. The mouse cursor hesitantly flashed during operations -- an indication of slow processing. They had already run an antivirus scanner with an updated signature database file. It had found nothing. Still, everyone was suspicious. Malicious mobile code is coming out so fast these days than even the most accurate scanners can't track all of the new ones.

The first thing I did when I arrived was to disconnect the PC from the Internet by unplugging its network card cable. That way if the machine was being attacked or monitored from the Internet, no more damage could be done. I then hit Ctrl-Alt-Del to see what program processes were running. There were a few that I didn't recognize, but that by itself is not surprising. Then I used the SYSEDIT.EXE command to examine the system startup files. The SYSTEM.INI file definitely had something suspicious. There was a line under the [boot] section, shell=explorer.exe Netlog1.exe , that was loading a strange file into memory every time Windows started. First, I used the Task menu to remove Netlog1.exe from memory, and then I examined it using a file text editor.

Quickly scanning the file for anything out of the ordinary, I noticed text strings pointing to a public Internet IP address and port number (explained in Chapter 6,

Additional content appearing in this section has been removed.
Purchase this book now or read it online at Safari to get the whole thing!

Content preview·Buy PDF of this chapter|Buy reprint rights for this chapter

I had been called to a company because it appeared that one of their Windows 98 computers had been hacked. The computer was connected to the Internet and was used for web surfing and email. The only symptom they reported was a significant slowdown in processing. Sure enough, even though the PC had more than enough processor power to run its applications, it was running very sluggishly. The day before it had been a fast and responsive machine. Now, it seemed to struggle with every mouse click and screen change. The mouse cursor hesitantly flashed during operations -- an indication of slow processing. They had already run an antivirus scanner with an updated signature database file. It had found nothing. Still, everyone was suspicious. Malicious mobile code is coming out so fast these days than even the most accurate scanners can't track all of the new ones.

The first thing I did when I arrived was to disconnect the PC from the Internet by unplugging its network card cable. That way if the machine was being attacked or monitored from the Internet, no more damage could be done. I then hit Ctrl-Alt-Del to see what program processes were running. There were a few that I didn't recognize, but that by itself is not surprising. Then I used the SYSEDIT.EXE command to examine the system startup files. The SYSTEM.INI file definitely had something suspicious. There was a line under the [boot] section, shell=explorer.exe Netlog1.exe , that was loading a strange file into memory every time Windows started. First, I used the Task menu to remove Netlog1.exe from memory, and then I examined it using a file text editor.

Quickly scanning the file for anything out of the ordinary, I noticed text strings pointing to a public Internet IP address and port number (explained in Chapter 6, Trojans and Worms). Then I saw it, a text string saying, "The victim is online!" A legitimate company didn't write this file. I did a search for all files that had been modified or created in the last few days. There were a dozen or so. I removed all the ones I didn't trust. One was a password file, evidencing that a hacker had entered into the system and set up his own logon accounts. The root directory contained a

Additional content appearing in this section has been removed.
Purchase this book now or read it online at Safari to get the whole thing!

Content preview·Buy PDF of this chapter|Buy reprint rights for this chapter

Malicious mobile code (MMC) is any software program designed to move from computer to computer and network to network, in order to intentionally modify computer systems without the consent of the owner or operator. MMC includes viruses, Trojan horses, worms, script attacks, and rogue Internet code. The intentional part of the definition is important. Design flaws in the Microsoft Windows operating system are responsible for more data loss than all the malicious code put together, but Windows wasn't intentionally designed to destroy your data and crash your system. And it certainly doesn't sneak on your hard drive without permission to get there. MMC used to mean DOS computer viruses, Trojans, and worms. Today, you have to add all harmful programs created with scripting languages and empowered by Internet technologies: macro viruses, HTML, Java applets, ActiveX, VBScript, JavaScript, and instant messaging. There are even viruses that infect Windows help files. Today, simply scanning executable files and boot sectors isn't enough.

There is a technological war going on. There are good guys and bad guys. Every second of every day, tens of thousands of pieces of MMC are trying to break into some place they shouldn't be, delete data, and mess up the day of many fine people who are just trying to work. Mischievous hackers write malicious code and release it in to the unsuspecting world. People lose data and productive time as bugs are discovered and removed. Antivirus researchers and security experts take apart the latest creation to learn how to detect and remove it. The public is educated, security holes are closed, and software scanners are updated. But this does little to stop the next attack. The next one is a slight variation (called a variant ) from the older exploit or maybe even something completely different. In either case, the maliciousness occurs again with the same results. The defense steps most of us are taking are not enough.

It's a real war. If the general public knew what was possible, they might not want to get on the Internet. There are automated malicious programs, bots, and scripts, all designed to fight it out with the good guys. They look for weaknesses in control and then automate the attack. So many new malicious programs are being developed that most of them don't even interest the good guys. Only the ones that do something new invoke curiosity. Antivirus researchers have automated bots that scour the Internet, much like a search engine would, looking for MMC. It would be too time consuming for humans to do it. When found, the viruses, worms, and Trojans are fed into software tools that automate the process of disassembly, debugging, and identifying the catch. Some antivirus companies are cataloging 200-400 new malicious programs a month, with some vendors saying their products now catch over 54,000 different bugs.

Additional content appearing in this section has been removed.
Purchase this book now or read it online at Safari to get the whole thing!

Content preview·Buy PDF of this chapter|Buy reprint rights for this chapter

The next section will attempt to summarize the legal implications of writing and distributing malicious mobile code within the boundaries of the United States. I have no formal training as a lawyer, and this section is included here only as a summarization of my understanding. Please consult legal counsel before relying on my advice.

"There ought to be a law!" At least that's what you should be thinking as you read about all the malicious code attacks. Well, there are laws that make causing intentional damage using malicious mobile code a criminal act. If you write or distribute rogue code, which causes damage to someone else's computer system, you can be charged with breaking the law. The hard part for the security expert is tracking down who wrote and distributed the code, and proving malicious intent. And to be truthful, there is so much hacking going on and MMC being distributed every second of every day, no law enforcement group could begin to investigate even a small part of the cases.

But as the Melissa virus author, David L. Smith, can tell you, if the malicious mobile attack gets enough media attention and the law officials can catch the perpetrator, he will go to jail. The 31-year-old New Jersey macro virus creator was arrested on April 1, 1999 and charged with several federal and state crimes. He was released on a $100,000 bond and accepted a plea agreement in court. He was found guilty and faced up to 10 years in prison and fines of up to $150,000. FBI officials used AOL records, phone records, and a "hidden" identification code embedded in every MS Word document to trace the virus's origination to Smith's PC. When Smith knew the FBI was on to him, he destroyed the PC he wrote the virus on. That tactic apparently didn't stop law enforcement officials from collecting enough evidence.

Christopher Pile (a.k.a. the Black Baron) became the first person arrested in the U.K. for writing computer viruses. The author of the Pathogen , Queeg , and Smeg viruses, Pile plead guilty to 11 charges in May 1995 and was sentenced to 18 months in prison under the U.K.'s

Additional content appearing in this section has been removed.
Purchase this book now or read it online at Safari to get the whole thing!

Content preview·Buy PDF of this chapter|Buy reprint rights for this chapter

The television idea of an isolated hacker sitting alone in a room, surrounded by Cheetos™ and empty Dr. Pepper™ cans in front of the midnight glow of a computer screen is a bit outdated. Well, at least the isolated part. Hackers today are more often adolescents and young adults with an entire cyber support system. They hang out in Internet chat rooms, newsgroups, and mailing lists, ingesting anything they can learn about their computer interests. They are out to learn everything they can about stretching their own abilities and their computer's abilities, while only a few individuals mean real harm. Twenty years ago it might have been hard for a hacker to name a dozen people who shared their same interest. Today, there are thousands of online resources, and the hacker can name a dozen people in his school who like to hack.

Why do people write malicious programs? Richard Skrenta was a ninth grader when he wrote the first PC virus, Cloner, in 1981. Now, a CEO for an impressive Internet company, his virus-writing days have been over for nearly 20 years. I asked him what motivated him to write a computer virus? Here's what he said:

I had played a trick on a classmate by altering a disk with a hot new pirated game to self destruct after a few boots. I gave him the disk, which he eagerly accepted, and he got to play [it] a few times before my booby trap sprung and the game erased itself. I enjoyed the success of this trick, but clearly it couldn't be repeated, since he would be wary of my gifts from that point.
It then occurred to me that I could load something into a booted Apple II in the school, which would hide in the background, and then alter the next disk that was put in and used. The point was to get my booby trap onto a disk that a classmate wouldn't let me handle. Even though I couldn't handle his disk, I could leave behind code that could get its "hands" on it.
At this point I made the jump that if the booby trap was the infection code itself, it could be self-propagating. The tricked classmate would be unwittingly brought into service infecting others with the self-propagating booby trap. There was no telling how far it could go.

Additional content appearing in this section has been removed.
Purchase this book now or read it online at Safari to get the whole thing!

Content preview·Buy PDF of this chapter|Buy reprint rights for this chapter

Here are some other malicious mobile code terms used throughout the computer security industry that you will need to understand while reading this book.

Antivirus: Antivirus (AV) programs, research, and researchers are dedicated to preventing the unknown spread of malicious mobile code. Whereas, the term AV is used to explicitly describe researchers working against computer virus programs, the lines of battle now include viruses, worms, Trojans, malicious Java applets, and other intentionally written rogue programs. An antivirus researcher rarely deals only in viruses, and it is the rare antivirus program that only detects viruses. However, because viruses are the most prolific type of malicious code, the term AV is often used when the intent is to describe all malicious code.
Backdoor: A backdoor is a subroutine within a malicious program that allows hackers to access previously secure computer systems without the knowledge of the owner/user/administrator. Many sophisticated Trojans today (such as Back Orifice, The Thing , or NetBus ) are backdoor programs.
Construction kits: Today, many malicious code creators don't even know how to program. Other hackers have created construction kits that allow nonprogrammers to make up their own viruses and Trojans by simply choosing a few options. The kit compiles the code and produces the harmful bug.
Exploit: An exploit is a rogue code action that takes advantage of a security flaw in a particular system or language. Exploits are considered by most experts to be examples of talented code writers. A Trojan that deletes files or formats hard drives isn't considered an exploit, whereas, a virus that spreads via email and uses an undocumented operating system API would be.
False-positive: A false-positive means a virus scanner reported that a rogue program was present, when one was not. This result can be more frustrating than finding a virus. The opposite outcome, not detecting a rogue program when one is present, is called a

Additional content appearing in this section has been removed.
Purchase this book now or read it online at Safari to get the whole thing!

Content preview·Buy PDF of this chapter|Buy reprint rights for this chapter

Chapter 1 gave a generalized overview of malicious mobile code and the world of malicious code writers. You should now be familiar with viruses, worms, Trojans, malicious ActiveX and Java applets, and Internet scripting attacks. Subsequent chapters will cover each type of malicious mobile code in detail. Chapter 2 starts the first lesson by covering DOS viruses and computer virus technology.

Additional content appearing in this section has been removed.
Purchase this book now or read it online at Safari to get the whole thing!

Content preview·Buy PDF of this chapter|Buy reprint rights for this chapter

This chapter will cover DOS-based computer viruses and basic file-structure mechanics to set the stage for the other types of malicious code. When you finish reading this chapter, you should be able to detect, remove, and prevent DOS-based computer viruses.

Ten years ago, many computer experts predicted the pubescent fad of writing computer viruses would fade away. Virus after virus was just redoing the same thing. What adrenaline rush could there be in creating something that a thousand others had already done? But like bell-bottom jeans and bad disco, malicious mobile code is growing ever popular.

There are a lot of other types of non-DOS, platform-specific viruses (Macintosh, Linux, OS/2, etc.) in the computer world, but it was the worldwide acceptance of IBM-compatible personal computers with Intel™ microprocessors running DOS-based programs that provided the richest growth medium for malicious mobile code. There were already several other PC platforms in existence prior to the release of the IBM PC in October 1981, but none captured widespread public interest. As IBM-compatibles became ubiquitous, so did writing rogue programs.

The sheer number of DOS computer viruses easily account for a large portion of malicious programs in existence, in spite of the fact that some dominant form of the Windows operating system has been in use for the last ten years. DOS-based computer viruses are so plentiful that they are considered by many to be the default malicious code model. To really understand malicious mobile programs, you must understand DOS-based computer viruses.

Computer viruses are nothing more than software programs intentionally written to use other host files or boot areas to spread themselves around without the computer owner's permission. They travel around on infected disks or across networks waiting to infect new PCs. People rarely know their disks or programs are infected until the virus has been around awhile. The infection may or may not be outwardly visible, as the virus may not want to be found. The virus may or may not mean to cause intentional damage. In either case, viruses increase the risk of system or data corruption by modifying the host file or boot area. Computer programs aren't all that stable without unauthorized modifications being made. Depending on the type of virus, it may or may not increase the size of the host file. Viruses slow down the processing of your computer, and sometimes distinctively so.

Additional content appearing in this section has been removed.
Purchase this book now or read it online at Safari to get the whole thing!

Content preview·Buy PDF of this chapter|Buy reprint rights for this chapter

Ten years ago, many computer experts predicted the pubescent fad of writing computer viruses would fade away. Virus after virus was just redoing the same thing. What adrenaline rush could there be in creating something that a thousand others had already done? But like bell-bottom jeans and bad disco, malicious mobile code is growing ever popular.

There are a lot of other types of non-DOS, platform-specific viruses (Macintosh, Linux, OS/2, etc.) in the computer world, but it was the worldwide acceptance of IBM-compatible personal computers with Intel™ microprocessors running DOS-based programs that provided the richest growth medium for malicious mobile code. There were already several other PC platforms in existence prior to the release of the IBM PC in October 1981, but none captured widespread public interest. As IBM-compatibles became ubiquitous, so did writing rogue programs.

The sheer number of DOS computer viruses easily account for a large portion of malicious programs in existence, in spite of the fact that some dominant form of the Windows operating system has been in use for the last ten years. DOS-based computer viruses are so plentiful that they are considered by many to be the default malicious code model. To really understand malicious mobile programs, you must understand DOS-based computer viruses.

Computer viruses are nothing more than software programs intentionally written to use other host files or boot areas to spread themselves around without the computer owner's permission. They travel around on infected disks or across networks waiting to infect new PCs. People rarely know their disks or programs are infected until the virus has been around awhile. The infection may or may not be outwardly visible, as the virus may not want to be found. The virus may or may not mean to cause intentional damage. In either case, viruses increase the risk of system or data corruption by modifying the host file or boot area. Computer programs aren't all that stable without unauthorized modifications being made. Depending on the type of virus, it may or may not increase the size of the host file. Viruses slow down the processing of your computer, and sometimes distinctively so.

Additional content appearing in this section has been removed.
Purchase this book now or read it online at Safari to get the whole thing!

Content preview·Buy PDF of this chapter|Buy reprint rights for this chapter

A DOS PC boots up, places DOS in control, and then runs a myriad of possible files and programs. Booting is the group of processes a PC executes to check itself for basic configuration errors and to load the operating system. A lot is happening during the first minute a PC is turned on.

The following explanation is going to assume an Intel PC running MS-DOS with one hard drive.

On every PC, many processes and checks must be made prior to any program or user being able to execute the first command. Much of the initial boot sequence, as shown in Figure 2-1, is dedicated to performing simple hardware self-checks and is the same regardless of the operating system. Once the operating system (OS) begins to boot, the sequence differs according to the particular needs of the OS.

Figure 2-1: Normal PC boot sequence (regardless of operating system)

After you flip the power switch, the power supply does a quick self-check and sends a signal to the CPU to start. The CPU initializes itself and starts executing hardware self-check code located in the read-only memory basic input/output system ( ROM BIOS) chip located on the motherboard. The ROM BIOS chip contains instructions that are "burned into" the chip and aren't normally changed. Early on, it took special equipment using ultraviolet light to write to the ROM BIOS chip. Today, the "burn-in" process can be as simple as running a specially-designed program to write the BIOS code to the chip.

The ROM BIOS is used for three functions:

To remember hardware and configuration settings (i.e., enable or disable booting from drive A, enable shadow RAM cache, remember the PC has a slave CD-ROM drive on IDE port 1, etc.).
Contains interrupt code subroutines that allow the operating system or software to access hardware devices. For example, software can initiate an interrupt 13h (h indicates hexidecimal notation) to access the hard drive.
Lastly, contains the instructions to find and start the operating system boot process.

The CPU always executes the first instruction located at the ROM address FFFF0. ROM chip manufacturers and CPU makers have agreed that the first instruction will always be located in the same memory address location. The first instruction then runs the rest of the ROM code. The code begins testing video memory and looking for other ROM chips (e.g., SCSI controller cards) to initialize. The CPU then checks a scratchpad location in system memory to see whether the PC was powered down (i.e., cold booted) or just warm booted by using the keyboard. This check will become more important later on. The former results in a test of system random access memory (RAM) and a further set of ROM self-checks, often referred to as the

Additional content appearing in this section has been removed.
Purchase this book now or read it online at Safari to get the whole thing!

Content preview·Buy PDF of this chapter|Buy reprint rights for this chapter

After learning how to do it, the first thing a virus writer must do is decide what type of virus to write. A boot virus is often the choice because it loads before any other software and is in complete control before the operating system even gets loaded. File viruses are a little bit easier to write and can accomplish more. What either type can do is only limited by the virus writer's creativity. He has to decide how obvious his bug will be, when it will spread, and what it will do when it decides to execute its payload.

Writing a virus isn't as hard as most people think. You certainly don't have to be a programming genius, as is popularly thought by most computer users. In fact, if all you do is write malicious code, then it's easier than writing productive, legitimate applications. As a virus writer, the subset of applicable programming commands is smaller, and the time-consuming process of writing bulky error-checking routines can be thrown away. What they need to know is found in bland technical manuals filled with arcane detail. How else can you find out what track and sectors hold the disk partition table, or at what memory address DOS stores the interrupt vector table? Writing viruses takes as much patience as creativity.

Once the basic tenets of DOS and low-level programming are understood, writing a simple virus is straightforward. Don't get me wrong. There are highly intelligent, gifted, malicious code writers in the world. Fortunately, most are not. All a file virus has to do is look for a host file, open it, write itself to the host file, and then close it. Four things. That's it. All file viruses are nothing more than sophisticated variations of the same four routines. When mischievous programmers learn how easy it is to write a virus, it doesn't take long for the malicious experiments to begin.

One of the smallest working viruses, Define , is a mere 30 bytes long. It doesn't work well, but it works. Early viruses were usually, but not always, written in low-level assembly language . This is because assembly programs are small and quick, and can do anything the hardware is capable of. Other languages, such as Basic or Pascal, have been used to write viruses, but their built-in routines end up bloating code and limiting functionality.

Additional content appearing in this section has been removed.
Purchase this book now or read it online at Safari to get the whole thing!

Content preview·Buy PDF of this chapter|Buy reprint rights for this chapter

DOS computer viruses (we are purposely ignoring macro viruses for now) can be classified in the following major categories:

Boot or file infector
Memory-Resident or nonresident
Appending or overwriting or companion
.COM or .EXE infector

In order for a pure boot virus to infect a hard drive, the PC must have attempted to boot with an infected floppy diskette. I run into people all the time with PCs that are infected with boot viruses and are convinced they did not boot, even accidentally, with a floppy diskette. But it had to have happened! What these people mean is they did not intentionally mean to boot with a floppy diskette. Often they don't understand that a boot virus can be present on any diskette. It doesn't have to be bootable. Every DOS-formatted diskette contains a limited boot sector containing error messages and other miscellaneous code. And a virus can hide in there without the disk having the necessary operating system files needed to boot a PC.

Most of the time, a friend or coworker gives someone an infected floppy diskette to transfer some datafiles to his computer. After he retrieves datafiles from the diskette, he forgets to remove it from the floppy drive and shuts down his PC. The next morning he turns on his PC, gets the familiar, "Nonsystem disk or disk error. Replace and strike any key when ready..." error message. He spends a few seconds trying to figure out why his system isn't starting as expected, then realizes the mistake, pops out the floppy diskette, and restarts the computer. Too late! If the diskette was infected by a boot virus, it has been transferred. The PC hard disk is infected. Every time the PC starts, the virus gets loaded into memory. Every floppy disk put in the PC can now be infected, and the whole cycle starts over again. This process is shown in Figure 2-8.

Figure 2-8: Boot virus life cycle

Pure boot sector viruses can only spread if you boot from an infected floppy diskette. You can retrieve and save files all day long to an infected diskette, but as long as you didn't boot with it, you're safe. In the past, to eliminate the biggest threat of computer viruses all you had to do was not boot from a diskette. Boot sector viruses replace a PC's normal boot code and take control during the initial stages of the PC's start sequence, although there are several different places where it can insert itself in the process.

Additional content appearing in this section has been removed.
Purchase this book now or read it online at Safari to get the whole thing!

Content preview·Buy PDF of this chapter|Buy reprint rights for this chapter

When viruses began to gain popularity, so did antivirus programs. The first holistic program to fight MMC was Flushot by Ross Greenberg in 1987. It attempted to prevent viruses and Trojans from making unwarranted changes to files and the disk. While hopelessly outdated today, it offered hope in the early battle against computer viruses and Trojans. There were a few programs that would search for and eradicate a particular type of MMC. But it was not until 1989 that John McAfee released his VirusScan™ program, which could detect and repair several viruses at once, that the antivirus scanner became popular. Initially scanners minimized the potential threat of MMC, and some AV researchers thought the threat of computer viruses would be over.

The typical life cycle of a DOS computer virus went something like this:

A virus gets created and released.
The virus infects a few PCs and gets sent to an antivirus company.
The antivirus company records a signature (covered in Chapter 14) from the virus.
The company includes the new signature in its database.
Its scanner now detects the virus, and the threat of the virus is lessened.

If you're a DOS virus writer, your creation can't spread all over the world if it's being detected and cleaned within a few weeks of its release.

Virus writers started fighting back with more sophisticated virus defense mechanisms to go undetected longer. Thus, the war of the virus writers against the antivirus vendors began. In a sense, the antivirus industry created more, faster, and smarter viruses. It is a war that couldn't be avoided or stopped. Virus writers try their best to make their viruses harder to detect, remove, or prevent. Many virus writers concentrate more time on their virus' defenses than the writing of the infecting code. Virus defenses include encryption, polymorphism, stealth, and armoring.

Virus writers saw that the best way to stop or slow down antivirus scanners was to make sure there was no constant string of bytes that could become an antivirus signature. For our purposes, encryption is the process of a virus rearranging its code so that it no longer looks like its former self in order to defeat antivirus scanners (see Figure 2-12). The virus executes, decrypts itself, does its thing, then rescrambles its bytes before saving itself back to the disk. Virus authors on the forefront of technology started to research and utilize professional encryption techniques. In order to be able to use encryption, a virus must be able to decrypt the encrypted code (called

Additional content appearing in this section has been removed.
Purchase this book now or read it online at Safari to get the whole thing!

Content preview·Buy PDF of this chapter|Buy reprint rights for this chapter

There are so many kinds of DOS viruses that I often feel that mischievous minds have tried every imaginable trick. DOS viruses can infect during bootup or warm booting, across a network, when running programs, when copying files, when you scan files for computer viruses, or when you list the files on your hard drive. They have been known to use modems to dial long distance numbers when unsuspecting users left their PCs on at night. They can display elaborate graphics, sounds, and games. They can corrupt programs, data, and hardware settings. Although most virus payloads wait for a particular activation date or time, they can be computationally random or key off some other event (such as hitting Ctrl-Break). Others lie in wait for the user to unknowingly type in a particular keyword to set off some sort of damage routine. Computer viruses can taunt people and display questions the end user must answer in some twisted form of a quiz show. If you answer incorrectly, they do more damage.

The Cascade virus infects .COM files and makes the letters you were typing fall to the bottom of the screen. The Jerusalem virus infects .COM , .EXE , .BIN , .PIF , and .OVL files. It displays a "pong" black box that floats around the screen and it will delete any executables run on Friday the 13. The Flip virus horizontally flips the screen image between four and five o'clock. The Keypress bug randomly interferes with keyboard typing so that a user thinks she is continually making mistakes. The Sunday virus admonishes users for working on Sundays as it deletes data. The Joshi virus pops up a message each July 5 asking that the user type in "Happy Birthday Joshi." Users who follow the instructions are allowed to work again, otherwise the system will hang. The Holland Girl virus contains a woman's name and address and asks the infected user to send a postcard. The virus is believed to have been written by an ex-boyfriend.

Viruses work for and against each other. The

Additional content appearing in this section has been removed.
Purchase this book now or read it online at Safari to get the whole thing!

Content preview·Buy PDF of this chapter|Buy reprint rights for this chapter

If you suspect you have a DOS-based computer virus, but you are not 100 percent sure, try the following steps.

1. Scan with a good antivirus program after cold booting with a write-protected, clean boot diskette.: There is no better way to detect and remove DOS viruses than running a good antivirus program. Use a reliable antivirus scanner with an up-to-date signature database. When you scan for DOS computer viruses, always cold boot the PC from a known clean, write-protected, bootable diskette. This makes sure that no computer virus is in memory when you scan. If a virus is in memory when you search, it can use various subroutine tricks to hide from antivirus programs or cause more damage.
Virus scanners are getting better and better all the time at detecting viruses that are in memory at scan time, but you'll get best results after cold booting with a clean diskette. I find that my scanning success and removal rate, after a cold boot, is even higher with viruses that aren't employing stealth defense mechanisms. Less code in memory lets the scanner do its job more efficiently.
When rebooting, make sure you turn the power off instead of pressing Ctrl-Alt-Del to warm boot. There are dozens of viruses, like Fish , Ugly , Joshi , and Aircop , which have no problem "living" through a warm boot, and thriving in memory when the PC restarts. These types of viruses monitor the keyboard input buffer or check the "warm-boot flag" in the BIOS data area waiting for the Ctrl-Alt-Del key sequence. They can then fake the normal reboot process and remain in control. The Ugly virus family tries to manipulate CMOS memory into thinking there is no floppy disk drive. Thus, when the PC reboots, it boots to the hard drive first, runs the infected virus code, and then the virus reenables the floppy disk drive and runs the floppy-based boot process. The PC appears as if it has booted up on the floppy diskette, but the virus is already in memory. Sneaky buggers, aren't they?

Additional content appearing in this section has been removed.
Purchase this book now or read it online at Safari to get the whole thing!

Content preview·Buy PDF of this chapter|Buy reprint rights for this chapter

A good antivirus scanner will clean up the bug without harming your system. Just make sure you remember to cold boot with a known, write-protected, clean diskette first. If you have this option, use it first. When an antivirus program finds a virus it will offer to disinfect the file or disk, if possible. If I don't trust the antivirus program to remove the virus without affecting the structure of the original host, I will make a copy of the host first and run the cleaning process on the copy. For example, many antivirus programs cannot remove a macro virus from a document without removing any other legitimate macros that may be present. In some cases, removing the virus can make a small problem worse.

If you don't have a good antivirus program handy, here are some other hints:

1. Use FDISK /MBR to remove a hard disk virus.: FDISK.EXE is a utility that helps logically partition hard drives. If you have a virus that infects only the partition table, you can use FDISK to delete and recreate all DOS partitions. This effectively rewrites the partition table and overwrites the first few tracks of the hard drive. Unfortunately, this effectively destroys all data on the hard disk, too. Most hard drive boot viruses infect the MBR or boot sector. Rewriting the partition table does not recreate the MBR. Any virus hiding out in the MBR would still be able to infect the newly formatted disk. This is why somebody who formatted his hard drive will rightly claim the virus lived through the reformat.
FDISK has an undocumented (well, it's been written about so many times now that it's hard to call it undocumented anymore) command line parameter, /MBR. Using this command, FDISK /MBR, will rewrite an MBR and remove an MBR virus from a hard disk. I've used it several times with great success. However, caution must be used and the exact type of virus identified ahead of time. FDISK /MBR rewrites the MBR, but not the partition table. There are several viruses that manipulate the MBR and partition table in such a way that using FDISK /MBR will cause more damage, including

Additional content appearing in this section has been removed.
Purchase this book now or read it online at Safari to get the whole thing!

Content preview·Buy PDF of this chapter|Buy reprint rights for this chapter

After every virus cleanup comes the process of preventing it from happening again in the first place. For DOS viruses, try the following steps.

1. Disable booting from the floppy diskette drive.: Go into your ROM BIOS and disable booting from drive A. It's the easiest, single biggest thing you can do to decrease your risk of boot virus infection. If your PC can't boot from the floppy drive, it can't get an infection from a pure boot virus. And since most boot viruses don't come in from dropper or multipartite infectors, you've just about eliminated the threat. When I first tell people to do this step, they almost always ask what should they do if they need to boot from the floppy drive in the future (e.g., to scan for a computer virus)? Easy. Just reenable it. It takes 15 seconds.
2. Use ROM BIOS to write-protect the hard drive's boot areas.: Today, most ROM BIOS chips allow you to write-protect your hard drive's boot areas. I've seen it called "Virus Protection" or "Boot Sector Write Protection." It's an easy feature to turn on and off. Typically, you don't need to modify a PC's boot records unless you are repartitioning the hard drive or upgrading the operating system. I have seen a few cases where legitimate programs (e.g., Norton Disk Doctor) needed to write to the MBR or operating boot sector and were prevented by the ROM BIOS. It's a little disconcerting to see a "Possible Virus Attempting to Modify Your Hard Drive's Boot Sector" error message when you are installing a new program, but typically after I assess what I'm attempting to do, or more accurately, what the legitimate program is attempting to do, I allow the modification to take place. However, if you are installing a new game or utility off the Internet and it tries to modify your boot sector, it's probably best if you don't allow it.
3. Never run an untrusted executable.: Friends send me joke executables all the time in emails. I'm supposed to run the attached program and be hilariously entertained. I never run an untrusted executable. I cannot tell whether or not the attached program is a file containing a virus or Trojan program. By untrusted, I mean that the source who sent me the file didn't write it or hasn't independently verified its entire functionality. That includes nearly every executable I'm sent by a friend over the Internet. Hearing your friend say that it hasn't formatted his hard drive yet isn't conclusive proof of safety. I've been to many companies who didn't take this advice seriously until it was too late. Never run an untrusted executable! Make it a habit. Don't make exceptions. Later on in Chapter 12 you'll learn how to automatically prevent untrusted code types from entering via email.

Additional content appearing in this section has been removed.
Purchase this book now or read it online at Safari to get the whole thing!

Content preview·Buy PDF of this chapter|Buy reprint rights for this chapter

If I had published this book three years ago, I would have ranked DOS viruses as a medium to high risk. But times have changed and DOS viruses no longer compromise the majority of malicious code. As recorded in the June 2001 edition of the Wild List, only 14 DOS viruses were noted out of the 214 reported programs. However, none made the top 20 of anybody's list, and they only accounted for 3 percent of malicious code reported to the ICSA Labs in their Computer Virus Prevalence Survey . If you disable booting from drive A, the chances of getting a DOS virus are remote. As DOS becomes history and Windows and other systems take over, DOS viruses will fade way.

Additional content appearing in this section has been removed.
Purchase this book now or read it online at Safari to get the whole thing!

Content preview·Buy PDF of this chapter|Buy reprint rights for this chapter

DOS viruses were the real start of the war with antivirus vendors. As scanners detected viruses better, malicious coders worked harder and faster to make smarter bugs. There are thousands and thousands of DOS viruses and the only thing that's decreasing the risk they pose is that DOS itself is disappearing. Windows has been around for over 10 years and malicious coders have learned how to code 32-bit Windows viruses for Windows 9x and NT. The next two chapters will discuss the affects of computer viruses on Microsoft's Windows operating systems.

Additional content appearing in this section has been removed.
Purchase this book now or read it online at Safari to get the whole thing!

Content preview·Buy PDF of this chapter|Buy reprint rights for this chapter

Many PC users thought Microsoft Windows would spell the end of, or at least decrease, the amount of computer viruses. And while Windows initially made the job of writing malicious mobile code (MMC) harder, even DOS viruses haven't received a knockout punch. Microsoft has always maintained a strong commitment to DOS-compatibility in Windows in order to run older applications. Customers demand it. That legacy obligation, coupled with the newer data and application-sharing features, have made it easier than ever for warped code writers to create and distribute malicious programs. With every release, Microsoft makes Windows more network-aware, easier to program in, and extendable. This ease of use has often been at the expense of security. Damaging file and operating system manipulations can be accomplished remotely with a minimal amount of effort. Viruses written 10 years ago have no problem destroying Windows 98 or NT, although Windows 2000 is starting to make the job harder.

Chapter 3 begins a two-chapter discussion of Windows and (DOS and Windows) viruses in a Windows environment. In this chapter, the Windows operating systems and their related technologies are covered, including Windows 2000™ and Windows ME™. To understand MMC in a Windows environment, you must understand the key differences between the different platforms. You will probably learn more about the innards of Windows than you bargained for. Chapter 4 builds upon that knowledge by discussing two topics: DOS viruses in a Windows world and Windows viruses in a Windows world. It will give examples of Windows viruses, and finish up with tips on detection, removal, and prevention.

Microsoft Windows started out strictly as a shell menu to hide the roughness of DOS, but it is slowly lessening its reliance. Microsoft has two core Windows platforms: 9x and NT. Although they look alike, they are significantly different under the hood. For the purposes of this book, unless specifically separated, the 9x platform includes Windows ME, and NT includes Windows 2000. The next section explains the evolution of Windows and the different programming and security constructs each version uses.

Additional content appearing in this section has been removed.
Purchase this book now or read it online at Safari to get the whole thing!

Content preview·Buy PDF of this chapter|Buy reprint rights for this chapter

Microsoft Windows started out strictly as a shell menu to hide the roughness of DOS, but it is slowly lessening its reliance. Microsoft has two core Windows platforms: 9x and NT. Although they look alike, they are significantly different under the hood. For the purposes of this book, unless specifically separated, the 9x platform includes Windows ME, and NT includes Windows 2000. The next section explains the evolution of Windows and the different programming and security constructs each version uses.

Since 1996, it has been Microsoft's stated development path to converge the 9x platform's ease of use with the stability and security of NT's operating kernel. Every 9x release is supposed to be Microsoft's last, but the two OS platforms are different enough that migrating users was tougher than Microsoft originally bargained for. Although the 9x and NT platforms may look alike (the 9x interface was given to NT in version 4.0), underneath they are completely different animals. Programming for any of the Windows platforms is significantly harder than programming for the DOS world. For that reason, and the greater hardware requirements, the first Windows viruses didn't appear for years after the popular acceptance of Microsoft's new operating systems. Initially, some believed Windows had defeated computer viruses, but that wasn't the case.

Much of what Microsoft introduced in Windows 3.x is still used in the today's versions. During this next section, we will discuss the technologies and terms relevant to our discussion of malicious mobile code (for example, we won't talk about Plug and Play or the significance of the Start button). There will a bit of jumping around from topic to topic, but everything will fall into place when we see each Windows platform's booting process and its exploits in Chapter 4.

Application Programming Interface (API) is the way a high-level language (e.g., C++, Visual Basic) interacts with a lower-level language or operating system. The Windows API is a core set of routines that contain the basic system calls needed to manipulate the Windows operating system and file subsystem. For instance, the

Additional content appearing in this section has been removed.
Purchase this book now or read it online at Safari to get the whole thing!

Content preview·Buy PDF of this chapter|Buy reprint rights for this chapter

Both Windows ME and Windows 2000 contain features and components helpful for diagnosing and preventing malicious mobile code. This section of the chapter will cover only the new features related to malicious mobile code security.

Windows Millennium Edition was released on September 14, 2000, as the last version of the 9x platform. It is designed for home users, and isn't as reliable or secure as Windows NT. Containing a slew of new multimedia enhancements, it sports a user desktop and TCP/IP stack borrowed from Windows 2000.

Section 3.2.1.1: System restore

A new System Restore feature backs up important system files every 10 hours, by default, and can be used to restore earlier system states in the event of system corruption. It attempts to replace damaged system and program files without overwriting user data and personal settings. It compresses and stores files changed in the Windows or Program Files folders for later restoration purposes. The System Restore wizard (Start → Programs → Accessories → System Tools → System Restore) can be used to automate recovery from many malicious code attacks, instead of the manual methods we rely on in the older versions.

For good or bad, Microsoft removed the ability to boot to MS-DOS from the Startup menu. Fortunately, the Windows ME startup disk will allow a boot to DOS when such access is needed.

Section 3.2.1.2: System file protection

Windows ME and 2000 have new mechanisms that although not built specifically to defeat malicious mobile code, can prevent many types from spreading. Called System File Protection (SFP) in Windows ME and as Windows File Protection (WFP) in 2000, it can prevent many system programs and crucial .DLL files from being replaced, modified, or deleted. If a virus or Trojan attempts to mess with a protected file, the original file is restored. And although both file protection versions (I collectively identify them as

Additional content appearing in this section has been removed.
Purchase this book now or read it online at Safari to get the whole thing!

Content preview·Buy PDF of this chapter|Buy reprint rights for this chapter

Not only did Windows fail to prevent DOS viruses from causing harm to PCs, but the newer functionality of Windows significantly increased the ways a computer system can be exploited. A computer user has to stop both DOS and Windows viruses from attacking their PC. It is yet to be seen if Windows ME or 2000 decreases, or increases, the instances of malicious mobile code. Chapter 4 builds upon the Windows knowledge we learned by examining different DOS and Windows viruses, and shows how to detect and prevent them.

Additional content appearing in this section has been removed.
Purchase this book now or read it online at Safari to get the whole thing!

Content preview·Buy PDF of this chapter|Buy reprint rights for this chapter

This chapter builds on the knowledge learned in Chapter 3 by covering viruses and their effects on the Windows. It covers the effects of DOS viruses running under Windows and discusses viruses specifically created to infect Windows executables.

Internet scripting viruses will be covered in Chapter 8, Chapter 9, and Chapter 12.

In a PC world where Windows is king, there is still a significant population of functioning DOS viruses. They do not understand how to manipulate Windows executables and the newer file storage types, so their overall ability to spread on a Windows system is decreased in most cases. Still, some do work, and the ones that don't, can still cause bootup and runtime errors. Under a DOS Virtual Machine (DVM) session, DOS is emulated well enough to allow most DOS viruses lots of opportunity to do damage.

This section will summarize the overall effects DOS viruses have on Windows, followed by specifics for each platform.

Section 4.1.1.1: Boot virus infections

After the POST routine of a PC is finished, the first boot drive is checked, and the Master Boot Record (MBR) is located. The MBR then tells the PC where to locate the primary boot sector of the default operating system. This process is identical for every PC regardless of the operating system. Thus, a boot virus located on a booted floppy will be able to successfully infect the boot area of all hard drives. When an infected PC boots, the infected boot sector is given control. During this stage of the booting process, the virus can execute its payload damage regardless of the operating system. In many cases, boot viruses check for particular dates or events to initiate damage routines or display messages. These damage routines are usually accomplished using ROM BIOS interrupts (e.g., 13h) and they will be successful.

If the newly infecting boot virus declines to initiate a payload routine during the first stage of the bootup, usually its next priority is to locate the default boot sector and replace it with viral code. Most boot viruses will be successful here, too. Next, a boot virus must turn over control to the original boot sector, start the default operating system, and place itself in memory (so it can infect accessed diskettes). Depending on the boot virus mechanism and the operating system, it may or may not be successful. The virus might not understand how to correctly infect the new type of boot sector, or it won't understand the new file subsystem, or the operating system in control may prevent its future actions. In any case, the boot virus may not be successful in its later attempts. And if it isn't, the boot virus will not spread far. However, its misguided attempts can easily disable a PC from booting properly and cause data loss.

Additional content appearing in this section has been removed.
Purchase this book now or read it online at Safari to get the whole thing!

Content preview·Buy PDF of this chapter|Buy reprint rights for this chapter

In a PC world where Windows is king, there is still a significant population of functioning DOS viruses. They do not understand how to manipulate Windows executables and the newer file storage types, so their overall ability to spread on a Windows system is decreased in most cases. Still, some do work, and the ones that don't, can still cause bootup and runtime errors. Under a DOS Virtual Machine (DVM) session, DOS is emulated well enough to allow most DOS viruses lots of opportunity to do damage.

This section will summarize the overall effects DOS viruses have on Windows, followed by specifics for each platform.

Section 4.1.1.1: Boot virus infections

After the POST routine of a PC is finished, the first boot drive is checked, and the Master Boot Record (MBR) is located. The MBR then tells the PC where to locate the primary boot sector of the default operating system. This process is identical for every PC regardless of the operating system. Thus, a boot virus located on a booted floppy will be able to successfully infect the boot area of all hard drives. When an infected PC boots, the infected boot sector is given control. During this stage of the booting process, the virus can execute its payload damage regardless of the operating system. In many cases, boot viruses check for particular dates or events to initiate damage routines or display messages. These damage routines are usually accomplished using ROM BIOS interrupts (e.g., 13h) and they will be successful.

If the newly infecting boot virus declines to initiate a payload routine during the first stage of the bootup, usually its next priority is to locate the default boot sector and replace it with viral code. Most boot viruses will be successful here, too. Next, a boot virus must turn over control to the original boot sector, start the default operating system, and place itself in memory (so it can infect accessed diskettes). Depending on the boot virus mechanism and the operating system, it may or may not be successful. The virus might not understand how to correctly infect the new type of boot sector, or it won't understand the new file subsystem, or the operating system in control may prevent its future actions. In any case, the boot virus may not be successful in its later attempts. And if it isn't, the boot virus will not spread far. However, its misguided attempts can easily disable a PC from booting properly and cause data loss.

Additional content appearing in this section has been removed.
Purchase this book now or read it online at Safari to get the whole thing!

Content preview·Buy PDF of this chapter|Buy reprint rights for this chapter

To date there is no such thing as a Windows boot virus, although theoretically NT is ripe for such an exploit. Windows executable viruses, however, are able to spread on different Windows versions depending on how they were written and the platform they land on.

The first native Windows virus, WinVir, didn't appear until April 1992, a full two years after Windows 3.0 was released. Although it infected Windows .EXE files, it contained no Windows API calls and instead resorted to DOS interrupts, which showed even two years later that virus writers didn't really understand the Windows environment. When WinVir was run, it would infect every Windows .EXE in the current subdirectory, and at the same time disinfect the program it was initially launched from. Virus writers didn't wait as long to develop a 9x virus, although Windows NT proved a tougher nut to crack.

Released in Internet newsgroups in February 1996 by the Australian VLAD virus writing group, Boza was the first Windows 95 virus. When run, the direct infection (nonresident) virus would look for three 32-bit executables to infect

Table of Contents

Section 3.2.1.1: System restore

Section 3.2.1.2: System file protection

Section 4.1.1.1: Boot virus infections

Section 4.1.1.1: Boot virus infections