the virus authors strike back

Computers & Security, 11 (1992) 602-606

The Virus Authors Strike Back

Some people might be running AV (anti-virus) software which is inef- fective, either because it has been switched off by the virus, or patched by the virus, or else the virus works in a way that the AV sofmare didn’t expect. This paper looks at the various attacks on AV software and how they work. Each kind of attack considered has been used in a virus at least once: these are not just theoretical possibilities.

Three Kinds of Anti-Virus Products

There are three kinds of AV product. The most widely used is the scanner, accounting for about 90% of AV software being used. A scanner is a program that knows how to find viruses; mostly by looking for a fixed sequence of bytes, but sometimes needing a more sophis- ticated approach. Most products include a scanner. A new virus, in general, will not be detected by a scanner, unless the virus is heavily based on an old virus. The chal- lenge to virus writers, therefore, is not to write a virus that a particular scanner cannot detect, but to write a virus which will always be diffi-

cult to detect with a scanner. A close relative of the scanner is the memory resident scanner, which is essentially the same program, but permanently in memory.

The second main type of AV software is the integrity checker. This is a program which is run from time to time, and which notices changes in executables. A virus needs to make a change to an es- rcutable to work (we’ll see exceptions to this later), and the integrity checker spots these changes. It doesn’t detect viruses, it detects changes, and not all the changes will be viruses.

It is this class ofsoftware that forms the basis for vendors’ claims “De- tects all possible future viruses” and “Never needs updating”. As we will see soon, these claims are spurious (but you probably already &messed that). Some 10%~ of users run this kind of software.

The third kind of AV product can be implemented in hardware or software - this is the behaviour blocker. It has a list of permitted classes of behaviour, and anything that breaks its rules causes some

sort of alert to the user. Again, vendors make claims like “Never needs updating” and “Detects all possible viruses”. Again, these claims are spurious. Typically, a behaviour blocker monitors the interrupts on the PC, and thereby for example can spot attempts to lvritc to COM and EXE files, to go memory resident, or to write to system areas. Only a very tiny number of users have this kind of product installed.

Detecting viruses is easy. Here’s a proofofthat proposition. It consists of a batch file that detects all past, present and future viruses.

Echo ‘%11 contains a virus !!!

It is also, of course, completely useless as a working tool, as it flags everything as a virus. But it serves to illustrate that the detection of viruses is only part (and a very easy part) ofthejob. A product must also give very few false alarms, or it will make the computer unusable.

Definitions

Let’s have some definitions. We can’t use the word ‘virus’, because I>r Cohen has defined that word in

602 0167-4048/92/$5.00 0 1992 Elsevier Science Publishers Ltd

Computers & Security, Vol. I 1, No. 7

such a way that the Diskcopy program is included as a virus. Instead, we’ll define the term ‘Real Virus’, which is a program that replicates, without the user’s awareness and cooperation. Diskcopy is not a threat, because we know that we are using it to copy itself. Real Viruses are a threat, because we don’t know that they are there. From now on, we’ll use the abbreviation ‘virus’ instead of the term Real Virus.

Next, let’s define Useful AV Soft- ware. Software that merely detects viruses is not useful (see the batch file above). Useful AV Software dis- criminates between viruses and non-viruses. From now on, we’ll use the abbreviation AV to mean Useful AV Software. Remember - AV software is for discrimina- tion between viruses and non-viruses, not just for virus detection.

Means of Attack

Now that we know what we are trying to do with AV software, and we have defined the classes of AV software, we can consider the ways that virus authors attack the AV First, we’ll look at generic attacks on AV software of whatever kind.

An AV is just a program, stored in a file, usually on the hard disk. It is therefore vulnerable to being modified by a virus. We looked at one scanner on the market, found the strings COM and EXE, and modified these to DOC and TXT. The scanner then happily scanned all TXT and DOC files instead of the ones that could get infected. There are viruses that aim to do a similar thing; one of them patches

90h (no operation) in places in the AV program, so that whatever was supposed to happen at that point in the code, no longer happens. The obvious defence against this kind of tampering is to run the AV from a write protected floppy diskette. Maybe 1% of users can be per- suaded to do this on a regular basis. The other 99% have to be protected in some other way.

The other obvious solution is that the AV should check itself for changes before it does anything else, and refuse completely to run if there are any changes. It is as- tounding how many AV products do not take this elementary pre- caution. You can very easily test your product for this; make a change to part of the file, and see if it notices, and what it does. It would be nice if the product could repair itself if it is damaged, but remember that a virus might dam- age the program in such a way that the repair is disabled. Replacement of the AV program is very easy. and is safest.

Because some AV programs now self-check, some of the viruses are written to notice that files with certain names should not be infected, so that the scanner will not detect this new virus by the fact that it has changed. Often, it is looking for SCAN???, or any fiie- name with SC in it. or VIR.

The Polymorphic Virus

Since scanners are the most widely used AV software, we’ll now look at attacks on scanners. You can assume that any new virus is likely to evade detection by scanners. So you have to continually update the

scanner to account for this - not a problem, as you expected that. But the virus authors have come up with a class of viruses called Poly- morphic (after the Greek, many forms). Mark Washburn wrote the first polymorphic virus, 1260. This is a modification of the Vienna virus, taken out ofthe Burger book. The principle that it uses is as follows.

You encrypt the virus, using vari- able keys (time, date, file size, all of these). But a totally encrypted fde cannot run, and needs to be de- crypted first. A scanner can choose bytes from the decryptor to scan for. A Polymorphic virus aims to make this impossible. The decryptor can have some of its instructions in a different order without changing the effect. It can have non-useful instructions scat- tered among the significant ones - NOP (No operation), CL1 (Clear interrupts), ST1 (Set the Inter- rupts) and so on - which introduces variability into the search string. The virus author can choose different registers for the various functions - where the DI register is used, for example, the SI register can be substituted. Many of the Russian and Bulgarian viruses are polymorphic; Slovakia, An- dryushka, PC-Flu, Wordswap. The Mutation Engine (MtE) is a mo- dule that a virus author can link in with his virus, to add polymorphism. Of course, if he is foolish enough to do so, every scanner that has detection for MtE will auto- matically detect his virus, so not many of them are using it. Any new virus means that the AV vendors have to examine the virus to find a constant sequence of bytes that is always in the virus, and (hopefully) is never in any clean file.The choice

603

Alan Solomon/The Virus Authors Strike Back

of scan string (often called a ‘signature’) is a matter of skill and judgement.The most notoriousin- cident came about when a newsletter published a scan string for the Gosia virus, that occurred in ahnost every copy of COM- MANDCOM in the world; AV researchers call this “the mother of all false alarms”.

The problem that polymorphism gives to AV vendors is to add diffi- culty to the choice of signature. Some polymorphic viruses leave as many as five to eight constant bytes - some scanners need no more. but most scamiers want a couple of dozen bytes. For many polymorphic viruses, the longest possible signature is hvo or three bytes, which is obviously useless for dis- crimination. The virus V2P2 has at most two byte signatures, V3P6 has only single bytes.Many AV vendors deal with such viruses by hard- coding an algorithm in the scanner executable - this means pro- gramming, which means a worse maintenance problem, bugs, beta testing, quality control. It is all much harder than simply adding a string to a database. The other approach is to use some form offuzzy logic, so that most polymorphic viruses can be detected with a database entry. This means less dificulty for the vendor. and therefore less likelihood of bugs.

When we look at AV scanners, we see a surprising number ofscanners from large vendors that are not capable of detecting polymorphic viruses that are more than a year old - this suggests that they have decided that these viruses are too difficult to deal with. A great many users are running scanners that cannot detect these old viruses,

which probably means that they never will. It also means that they probably will never detect the large number of polymorphics that are coming out now.

Uy the way, you probably assumed that a TSR scanner from a vendor will detect the same viruses that his on-demand scanner detects. Far from it. There could be a great many viruses not covered by the TSR, and they will mostly be the polymorphics. Ifyou want to know in detail, of course, ask your vendor for a list of what is left out of the TSR. If he says none, ask for that in writing, as you might try to depend on that statement. Poly- morphics are often left out ofTSRs because of the need for hard coding.

Another problem that polymorphics bring, is false alarms. If an AV product attempts to detect a com- plex polymorphic, and makes the net too fine, then it will detect normal files as infected bv the polymorphic. This has given &e to a number of rumours about the commonness of the Whale virus, for example (a virus that can barely survive out of water, as it hangs almost every time it tries to run).

Viruses Written in C, Pascal, Basic

Another attack on AV scanners, is the virus written in C or Pascal (or Basic). It is very simple to Lvrite an overwriting virus in a high level language (HLL), and so budding virus authors sometimes use this. The threat to scanners is that it is very easy to fail to notice that the virus is written in a HLL, and the vendor might choose his scan

string from that part of the file that is the compiler library -as a result, the scamler gives a false alarm on a great manv normal files.

Of the failures in scanners that \vc observe, about a third arc false alarms on viruses written in HLLs, about a third are false alarms or failures to detect polymorphics.

Stealth

Nest, we’ll consider the attacks on integrity products. The earliest attacks on these used Stealth. If a virus is using Stealth techniques, then any attempt to access the infected object is diverted, and a clean object is shown to the program reading it. Stealth is not a new idea - the Brain virus (vintage 1986, Pakistan) used stealth. The NOINT virus that got through Novell’s Quality Control processes was a stealth virus, and so is Frodo, which \vas accidentally distributed xvith 130 000 diskettes by a French computer magazine.

With a full stealth virus, the integrity checker must find some way to detect the virus in spite of the stealth. One method used, is to tell the user to cold-boot from a clean 110s disk. This might work with the 1 ‘X, of users that will actually do it. The other 99% still need protec- tion from stealth. Another way is to scan memory for known viruses. This can work, as memory is accessed directly (whereas the disk is accessed indirectly via the interrupts). But it puts us back in the position ofnreding updates,so isn’t really satisfactory. Another way is to get underneath the virus’s tricks, either by writing code to do INS and OUTS to the ports to control

604

Computers & Security, Vol. I I, No. 7

the hard disk (very difficult indeed) or by searching for and using the firmware (quite difficult) or by tracing back the interrupts until the firmware is found (not too difficult). Integrity checkers use many of these techniques. But some integrity checkers use none of these techniques, and instead rely on the cold-boot from a clean floppy disk. This is not wise, as it is relying on users doing something that they simply do not do.

Further Evasions

Stealth is not the only attack on integrity products. There has been considerable discussion on the underground bulletin boards, of a technique that will evade integrity products without the virus needing to be in memory. The method works as follows.

When DOS loads the system files (lO.SYS and MSDOS.SYS) it does so by the position that they occupy on the hard disk. But when a program reads those files, it does so via DOS consulting the FAT about where they are. If you move a cluster of the file, and change the FAT to reflect that, then any checksum- mer that merely reads files will not notice this. Then, there is a cluster of the file that is loaded in at start up, and which could be the virus. To deal with this situation, an integrity product must check these fixed areas on the disk, and report if there is any change. One vendor dealt with this problem by making ‘a minor change in the documen- tation’.

Sparse Infection

Sparse infection is another tech-

nique. Suppose a virus only infects one file each month. Your integrity product will tell you about this, but if your scanner doesn’t detect the virus, you’ll probably ignore it. Speak to someone running an integrity product, and ask what they do if one file changes.

Companion viruses (also called Spawning viruses) use the fact that when you type a command, DOS looks for a COM file with that name before an EXE file,so a companion virus creates a COM file with the name of the EXE file, and the integrity product doesn’t see the EXE file change.The COM file runs, does whatever the virus author intended, and then loads (spawns) the EXE file, so the user sees nothing amiss.

Starship

Starship virus takes a different approach. It infects boot sectors, but when it infects a hard disk, it changes neither the partition program, nor the DOS boot program. So any integrity product that checks those, will see no changes. Instead, it makes a change to the partition data record, so that the pointer to the active boot partition is elsewhere, at the end of the partition. Thus, Starship creates a new partition with its own boot sector, and the DOS boot sector is left completely intact.

Starship also infects files, and does so in a way that also evades integrity checkers. First, consider two very old viruses;Virdem (Germany, 1986) and Brain. Both of these viruses only infect floppy disks. I’ve never seen anyone using an intr- grity checker to monitor floppy

disks, and I think that it would be impractical to do so. In theory, an integrity product could detect Brain. In practice, it isn’t feasible.

If a virus only infects floppy disks, does that mean that we don’t have to worry much about it, as there is never much of great importance on a floppy? Unfortunately we do have to worry. Suppose a virus just infects floppy disks, but on March 6th, it overwrites the hard disk. Or worse; every time you accidentally boot from an infected floppy, it makes a small corruption in your data. Integrity products cannot protect data, as they rely on detecting changes, and data changes all the time. So, to protect the data on the hard disk, we have to keep viruses off the floppies. The same is true, of course, for networks. It isn’t good enough to keep viruses off the files on the server - you have to keep viruses off the workstations, othenvise the virus on the work- station can tamper with the data on the server.

Starship waits until you are creating a file on a floppy, and attaches itself to that file. Imagine the effect of such a virus. Suppose you have a virus that works in that kind ofway, and you have an infected file on the hard disk. It never infects any other file on your disk, but when you copy a file to a floppy, it adds itself to that. If it is also stealthing, you won’t notice that they are different, but even if it isn’t stealthing, you aren’t likely to notice; COPY /V wouldn’t spot this. Then you take that file to another machine, and copy it on. Your integrity product tells you that you have a new file. “Yes, I know that”, you say, “kindly checksum it for me and make sure that it doesn’t change.” And it

605

Alan Solomon/The Virus Authors Strike Back

never does change, and nor does any other executable on the hard disk. And now you have another infected machine. And so on.

Behaviour Blocker

The third class of AV product is the behaviour blocker. The main problem with this class of product is the number of false alarms it generates. But there is another problem. Many behaviour blockers assume that anything that writes to the hard disk, must go via the interrupts. But many viruses (for example, Tequila, and many of the Bulgarian viruses) use one of the techniques described above for penetrating stealth viruses. Indeed, the viruses pioneered the technique that is now being used to counter them.

Some behaviour blockers have a convenient way for the user to switch them off, such as a handy key sequence. A virus can use this also. One popular anti-virus product even provides an interrupt to communicate with it, and a great many viruses are using this interrupt.

Some viruses use behaviours that the blocker didn’t anticipate. For example, Sylvia (Holland Girl) doesn’t write to a COM file; it writes to a new file with an inno- cuous ftiename, and then renames it.

Summary

So, we have attacks on all classes of AV software, and some of the attacks are successful. What can be done about this!

Here’s a game. Player A names a number, and player B has to name a bigger number to win. With this kind of game, the advantage is with the player who takes the last turn. The defender puts up the best possible defence, but then the attacker can put as much time and effort into breaking the defences as he wishes. In the case of integrity products and behaviour blockers, the fixed defender is the product, and the attacker is the virus author. However, in the case of scanners, because they are frequently up- dated, the advantage of last turn is with the scanner vendor. The virus author does the best he can with

his virus, but then the AV vendor can put as much time and ettort as is necessary into dealing with that virus. Whatever card the virus author plays, the fixed products cannot respond, but the scamler can.

The biggest weakness that scanners have is with vendors that don’t bother to incorporate detection of the more difficult polymorphic viruses.

So do the weaknesses in AV products mean that they cam7ot be used? Of course not - it just means that they have to be used appropriately, and with knowledge of their weaknesses. Did you think that AV products were infallible? Probably not, but perhaps you didn’t realize that they had quite so many holes.

And next time a salesman tells you that his product detects all past, present and future viruses with no need for upgrades, see if he will bet you $100 on that notion, and then ask how it will detect viruses that only infect floppies, such as those that were around six years ago!

606

the virus authors strike back

Documents