8.8.5 Companion Virus

Filenames in DOS have the format name.extension. Typical extensions are .DIR, .COM, .EXE, etc. For added convenience, users do not have to specify the full filename of a program they want to execute and can omit the extension. If a user calls a program in this fashion, then DOS first looks for a .COM file with this name, then for a .EXE file, then for a .BAT file. A companion virus exploits this default searchpath. If the original program is a .EXE file, then a .COM file with the same name and containing a virus could be created and the infected program would be executed. This technique was used by the AIDS 2 virus.

Default searchpaths are convenient but dangerous. The same type of attack is possible in Unix by placing an infected file which has the same name as the target of infection in a directory which is searched first according to the PATH environment variable.

8.8.6 Macro Viruses

A virus that inserts itself into the boot process will be written in machine language and all early viruses operated at this level. However, this does not imply that every virus has to be written in machine language. As early as 1989, Harold Highland mentioned the possibility of a macro virus that attaches itself to a spreadsheet worksheet, a data file [67]. Macro viruses are particularly interesting, and damaging:

• The virus is attached to a data file. Therefore, it will bypass integrity protection mechanisms targeting 'normal' executables (operating system, programs).
• The virus is written in ahigh-level language. Therefore it is much more platform independent than a machine language virus.
• Text documents are widely exchanged by email. This is an excellent medium for a virus to spread.

Macro viruses became reality in 1995. Microsoft's word processing system, MS-Word, allows users to tailor the environment their documents are displayed in. Formatting information, definitions for function keys and icons are all included in a macro file that comes with a text document. When this text document is opened the instructions in the macro are executed by MS-Word. When a new document is created the file NORMAL.DOT is used as a template for its macro.

A macro may seem to be simply an attachment to a data file but in reality it is a piece of executable code. However, users opening a file may not even he aware of the fact that they are running a program. All instructions available to write macros arc also available to virus writers who now can hide viral code in a macro file. The Concept macro-virus does exactly this. It infects .DOC and .DOT files. Once NORMAL.DOT has been infected. every newly created DOC file will automatically be infected.

A strict separation between program files and data files is an excellent basis for maintaining integrity in an environment where programs (to not change. A wordprocessor is a good example of such a program.

• Data files may change but do not contain executable code, so they cannot damage the system.
• Program files contain executable code but need not change. Integrity check values can be computed for all programs, saved in ROM, and any program can be checked before it is allowed to run

Macros were introduced to offer customers a more flexible word-processing system. At the same time, macros blur the distinction between data and program and create a new security problem.

8.8.7 Redirection of Interrupts

A virus is most damaging when it is executing in a privileged mode. To get into the privileged mode of a microprocessor, an interrupt (trap) has to be generated. The operating system then finds the address of the interrupt handier from the interrupt table. The interrupt table, and any similar structure, is therefore a prime target of attack. By changing the address of the interrupt handier, the operating system can be redirected to execute the virus, The virus makes itself memory resident as a TSR (terminate-and-stay-resident) program and is executed whenever the corresponding interrupt occurs.

This attack is particularly effective as it does not change the original interrupt handler and no integrity control mechanism checking this interrupt handier will detect the attack. A similar attack can be mounted by modifying entries in the file allocation table. An entry in the file allocation table (FAT) is modified so that it points to a virus, which in turn contains a link to the original file.

Removing a virus of this type may cause further damage. The virus is part of the link between table and file. If the virus is deleted, the link is broken and the file cannot be retrieved, at least not through the operating system.

8.8.8 Camouflage

A virus can try to avoid detection by various means. It can compress the infected program so that infection does not result in an increased use of memory. A stealth virus hides in a sector marked as bad in the FAT. Thus, other programs will nor-malty skip this sector when reading the disk. The virus can intercept interrupts to detect an attempt to detect its presence, e.g. an attempt to read the length, date, or checksum of a file it has infected. The virus will then return the original values. A polymorphic virus encrypts itself and uses a new key on each new infection to avoid detection by pattern recognition scanners. A multi-partite virus combines different types of infection to make detection more difficult. Slow infection viruses control the rate of infection to avoid immediate detection.

8.9 Anti-Virus Software

Viral attacks exploit a lack of integrity controls. To defend yourself, you therefore have to add those controls. Some of the available protection mechanisms are virus specific but mostly they address integrity in general. Your defensive strategy will have the following components:

• Prevention: stops a virus from infecting your system.
• Detection: detects a virus that has infected your system.
• Reaction: restores your system to a clean state.

Administrative measures and user awareness are essential for successful virus protection.

8.9.1 Physical and Administrative Controls

Physical and administrative controls are an excellent way of preventing a virus from entering your system. Some of these measures are surprisingly simple. If you do not want to write to a floppy disk, put the write protection tab on and no virus will be able to infect it. If the operating system provides access control, use it properly. For example, set file permission on all applications on network servers to read and execute only.

Place controls at the point where a virus could enter your system. Test new software on quarantine machines where anti-virus software has been installed. Do your testing from an account with as few privileges as possible, e.g. Guest. Even better, use a sheep-dip (gateway) machine to run a virus scanner, checking all floppy disks entering an organization. If it decides that a floppy disk is clean, the disk receives a label and is now cleared for internal use. If the label is a sticker on the disk, it is up to user awareness to detect unauthorized disks within their organization. If an electronic label is written on the disk, then the machines within the organization can check for its presence and refuse unauthorized disks. Nowadays, fire-wall products often are equipped with a virus scanner to look for viruses coming in over the network.

Conduct regular virus checks and keep your anti-virus products up to date. Anti-virus software can be included in each user's login script. System utilities can automatically perform checks at predefined times. For example, in Unix the system manager can tell the cron utility when to run integrity check programs. Do not rely on a single protection mechanism; use a combination of techniques.

Contingency plans should be in place to know how to react to a virus incident. It is often claimed that inept reactions to a virus attack create more damage than the virus itself. Obviously, clean backups are essential when restoring your system after an attack. However, it is not uncommon that by the time a virus is detected, it has already found its way into all the backups kept.

8.9.2 Cryptographic Checksums

Cryptographic checksums are a standard integrity protection technique. A checksum is computed for a clean version of the file to be protected. This checksurn is stored in a secure place, ideally in a ROW e.g. on a CD. Whenever this file is used, the checksurn computed for its current version is compared with the stored checksum. Thus, any change to the original will be detected. Clearly, a checksummer does not have to know about a virus to detect its presence.

Checksummers are vulnerable whenever the checksum has to be recomputed, e.g. when a file changes or when the clean checksums have been lost. They are therefore more suitable for environments where only a fixed set of software tools is used than for organizations developing their own software. Also, checksummers do not indicate which virus caused the infection, making it more difficult to plan further actions once an infection has been detected....