WORM vs. WORM - The ICSI Networking and Security Group

More documents

Recommendations

Info

ing. We call this an application-specific intrusion detection system. The system intercepts and inspects all messages sent to the application. Messages that match the signature of the current worm are not forwarded to the vulnerable application. The anti-worm code must also send itself to the originators of attacking worms for immunization and disinfection. Our current prototype uses an external payload for this purpose. While simple, it has a serious drawback: The extra traffic generated by the downloading of the payload may lead to network congestion. It may also lead to denial of service at the download site. Downloading the payload can always be done through a Content Delivery Network (e.g., Akami) which can reduce greatly the network traffic. A better way is to have the anti-worm re-generate itself. The anti-worm residing on a host has the complete information (code and data) as an entity; it may be possible for it to assemble network messages that are an exact replication of itself. The re-generation algorithm is quite sophisticated and requires further investigation. 4.3 Experimentation with Real Worms Our process is evaluated through tests against the following well studied worms: Code-Red I, MSBlaster, and SQL Slammer. The OS platform used in our experiments is the Microsoft Windows 2000 Server with Service Pack 2, Microsoft SQL Server 2000, and Microsoft Internet Information Server (IIS) 3 . Tools were developed to simplify the experiments but some tasks were still performed manually (e.g., restarting and reloading of the virtual machines). More work will be required to completely automate the process. Code Red I. Code-Red utilizes a buffer overflow in the indexing IIS plug-in, idq.dll. The worm utilizes an HTTP post request for default.ida containing a query parameter designed to overflow the buffer in this plug-in and overwrite the stack return address. The body of the post contains the worm’s payload, which is allocated and stored in the heap and can be of any practical size. Because of this the Code- Red worm message may contain the entire worm malcode and there is no need for an external payload. The worm message causes the return instruction pointer (EIP) to be overwritten with 0x7801,CBD3 which points to a piece of code in msvcrt.dll, a critical dll to the function of IIS. This code when disassembled is ”call ebx”, where EBX at this point contains a pointer to the posted data (the worm’s payload) [22]. The length of the payload is 3,569 bytes, and the exploit vector is 470 bytes, totaling 4,039 for the entire message. The worm is transmitted in a single TCP flow. A simple heuristic based algorithm can easily guess the location to start replacing the worm code with the anti-worm code to be at α equal to 470. Since the protocol is HTTP and a post request is being made the generation may assume that the payload falls after the end of the HTTP header, which is always ended with 0x0D0A,0D0A. This case will yield a successful anti-worm in a single test. In the case where the generation is not capable of using such a heuristic the worm generation would require 470 trials, if using a sequential search from α = 0. 3 Microsoft Windows 2000, Microsoft SQL Server, and Microsoft Internet Information Server are registered trademarks of the Microsoft Corporation MSBlaster. MSBlaster utilizes a buffer overflow in the Distributed Common Object Model (DCOM) Remote Procedure Call (RPC) service, which is always enabled by default [30]. This vulnerability was addressed by Microsoft Security Bulletin MS03-026 shortly after the vulnerability was discovered by LSD [16]. This vulnerability was widespread since many systems were not firewall protected and the common use of RPC by many applications. The DCOM exploit consists of two TCP messages with destination port 135. The first message, 72 bytes, is a RPC bind request which contains no malcode, it simply set up the system for the second request. The second TCP message, 1,704 bytes, consists of RPC request containing the buffer overflow intended to write a jump address pointing to a call which executes the malcode now stored in the heap, similar to Code-Red’s exploit. α is somewhere within 908 and 1,036 of the second message. A heuristic capable of locating this value can look for a series of ”nop” (0x90, no operation) instructions commonly found prior to the exploit code, used as padding for jump offsets that may not always start execution at the same place. Secondly the heuristic can also search for other sequences of what would be useless single instructions like ”inc eax” (0x40, increment a register.) The list of useless instructions is limited to only a small set of single byte instructions. Single byte instructions are required since multi-byte instructions will not be interpreted correctly if the instruction stream is not executed starting from the first byte of the instruction. SQL Slammer. The MS-SQL Worm, also known as the Sapphire or Slammer Worm, was the fastest spreading worm ever released. The worm uses a vulnerability reported in Microsoft Security Bulletin MS02-039 to target the Microsoft SQL Server Resolution Service which listens on UDP port 1434. This service is used to manage multiple instances of the SQL Server but is always enabled even in single instance configurations. The stack based buffer overflow is caused by a UDP packet starting with a 0x04 byte which tells the service to resolve a name. This name is str-copied into a stack allocated buffer of 16 bytes and not checked for length. The result is a stack based buffer overflow in the strcpy() function in msvcrt.dll [3]. Its small size (a single UDP packet total 404 bytes) and simple transport mechanism combined made it one of the fastest spreading worms ever. The worm was released at 05:30 UTC on January 25, 2002, and it is estimated that 90% of the susceptible hosts (∼75,000) were infected in a little more than 10 minutes [18]. The small size of Slammer posed an interesting challenge. Our prototype anti-worm code is about 700 bytes, which is far larger than Slammer’s 404-byte single UDP packet. The α value for this worm is between 117 and 171. A second constraint is that the exploit vector and payload of the antiworm must fit within a 1,000 byte buffer used by the recv() socket call in the target application. Currently, we append the 700 bytes of the anti-worm code beginning at α, making the resulting UDP packet twice as large as the original one. While this works for Slammer, it clearly shows that an antiworm should be no larger than the original worm in order to achieve its goals. This is one of the major reasons that we split our anti-worm into two parts, the bootstrap and the external payload.
Other Worms. We have yet to experiment with multivector worms such as Nimda. In these cases, an anti-worm would need to be created for each attack vector. The propagation payload of the anti-worm can be extended to contain multiple vectors in a single payload, in order to bridge networks with mixed vulnerabilities. Otherwise, if the propagation payload contained only a single vector per vector detected at the IDS level, crossing into firewall protected networks may be more difficult for our anti-worm as opposed to a hand crafted worm. Worms with variable messages (not re-playable messages), for example a worm that needs to negotiate a connection or change the jump address of the attack vector (i.e., the address is computed from values only known during the network exchange,) currently will not produce successful antiworms. More investigation is required to determine how these complex network interactions may be captured. One possibility may involve simulating the worm in a sand-box environment and learning the protocol from the simulated worm. Meanwhile, current-day worms do not appear to be using such sophisticated network communications, and as these communications become more and more complex the slower the scanning rate of the worm and the smaller the worm threat becomes. 5. PROPAGATION SCHEMES Once an anti-worm is developed, immunization becomes a race against the malicious worm. Ideally, we would want the anti-worm to spread to all vulnerable hosts as soon as possible, not only preventing the malicious worm from compromising other hosts but also working against it in an effort to rid the network of the worm threat. We have shown that with adequate resources, an anti-worm can be developed in a reasonable amount of time once a worm has been detected. In this section, we discuss several anti-worm propagation schemes and evaluate the schemes using simulation: • A Passive Anti-Worm listens on a host and waits for attacks from the original worm. It spreads itself (i.e., counter-attacks) to an attacking worm only. The propagation scheme minimizes additional network traffic. The CRClean anti-worm uses this mode. • An Active Scanning Anti-Worm randomly scans the available IP address space and transfers itself to those compromised or vulnerable hosts for immunization and disinfection. This scheme can quickly counter the original worm attack but may incur large amount of extra scanning and message traffic and cause undesirable network congestion. • An Active-Passive Hybrid Anti-Worm combines the features of the two schemes above. It starts as an active scanning worm initially and switches to passive mode when sufficient number of hosts have been installed with the anti-worm. • An IDS-based Anti-Worm involves the use of dedicated intrusion detection sensors throughout the Internet, scanning suspected packets and identifying the sender and receiver for immunization. This scheme was proposed and simulated in [20, 24]. In the remainder of this section, we first describe our simulation methods, and then present simulation results for the anti-worm propagation schemes. 5.1 Simulation Method We first discuss some related work in worm propagation simulation and then present our method. In the early 90’s, scientists from IBM adapted mathematical models of epidemiology to computer viruses [10, 11, 12]. In a simple epidemic model, a host is either infected (I) or susceptible (S). Once a host is infected, it is assumed that it stays in that state. This model is used in a number of research areas, usually slightly modified to simulate different phenomenon [33, 32, 28]. In the General Epidemic Model [35], a host is in infected, susceptible or removed state. Removal can be interpreted as immunizing the host or blocking it from the network. In either case, the host cannot be reinfected. Recent studies have used the spread of Code-Red as a comparison basis for their simulations [36, 28, 2]. In the epidemic models, parameters such as the pairwise infection rate are often adjusted to fit the data. Zou et. al. [37] have studied the effect of dynamic quarantine of hosts on worm propagation. Moore et. al. [19] have studied two methods for containing malicious code and their effect on worm propagation: address blacklisting and content filtering. We have developed an iterative simulation that allows us to simulate different scanning modes for both the malicious worm and the anti-worm. Our simulation parameters include: the percentage of online hosts, the number of the susceptible hosts, the TCP timeout value, the number of threads the worm runs on a host, and the percentage of infected susceptible hosts when the anti-worm becomes available. From the first three arguments we calculate the average scanning rate for the worm. The simulator tracks the number of infected and cured hosts. At every iteration, for each infected host, a random host is chosen from the available IP address space, and a random number is generated to determine the state of the target host. A host can be in one of the following states: offline (OL), infected (I), cured (C), susceptible (S) or notsusceptible (NS) state. An iteration is a single scan by every infected host. A second in simulation time consists of scan rate number of iterations. After each iteration, the infected, susceptible and cured host numbers are updated, along with the probabilities associated with them. If the anti-worm spreading scheme scans IP addresses as well, then the same steps are applied to every cured host too. Our simulator uses the complete (2 32 ) IPv4 address space. To realistically evaluate the different anti-worm propagation strategies, we use Code-Red I version 2 (CR-Iv2) as the base worm for simulation. CR-Iv2 runs 100 threads, 99 of them performing random IP scanning using TCP with a time out value of 21 seconds. Assuming that only 25% of the IP address space is online (similar percentage is used in [32]), we calculated the average scanning rate of a host to be around 6 scans per second. This complies with reports that approximate this value to be between 5 and 11. We used an approximated vulnerable host number of 360,000, the estimated number of vulnerable hosts for Code-Red I [17]. Figure 3 shows our simulation results for the propagation of Code Red Iv2 starting with a single infected host. The figure shows that the Code Red Iv2 spread in about 10 hours to all vulnerable hosts without any immunization. Network measurement in Moore [17] shows the real worm reach full coverage in about 14 hours. However, many systems were patched during the measurement period and hence slowed
Page 1 and 2: WORM vs. WORM: Preliminary Study of
Page 3 and 4: probably serious limitations, we st
Page 5: worm message. For a new worm that h
Page 9 and 10: 5.4 Active-Passive Hybrid Anti-Worm
Page 11: [34] N. Weaver, V. Paxson, S. Stani

WORM vs. WORM - The ICSI Networking and Security Group

Create successful ePaper yourself

Delete template?

Save as template?