Chapter 14. Network-Level Defense Strategies

The previous chapters have discussed defense techniques that focus on host-based solutions. This short chapter introduces worm behavior patterns on the wire and related technology that can detect and prevent worms and network intrusions, backdoors, and some types of DoS attacks.

The following key defense techniques will be discussed:

• Access lists using routers

• Firewalls

• NIDS (network-intrusion detection system)

• Honeypots

• Counterattacks

• Early warning systems

• Worm-capturing techniques

In this chapter, I will focus on worm behavior patterns with several network-level worm captures and related detection and prevention technology. I will avoid giving too much background information, which could easily make this chapter the length of several books!

14.1 Introduction

Figure 14.1 illustrates a typical corporate network with security zones. You can follow the network flow as it comes in from the Internet and first hits the router. Then the flow arrives at the firewall, and there are a number of points where a NIDS (network-intrusion detection system) might also be hooked up¹.

Figure 14.1. A high-level view of a typical corporate network with security zones.

There is a clear separation between the systems that are publicly accessible from the outside world and those that are accessed locally. You also can see the possible placement of a few honeypot systems², which are discussed further later in this chapter. Assume that antivirus and related content-filtering systems such as spam detection are in place, even though they are not shown in this particular example. For example, firewalls often implement antivirus interfaces so that they can scan the content of e-mail messages for malicious traffic. Personal firewalls and host-based intrusion detection and prevention systems are not shown in this picture, but as you will see, they are highly important in dealing with network attacks against individual hosts on your network³.

In the following sections, I will discuss these important network-level defense techniques and their relationship to early-warning systems.

14.2 Using Router Access Lists

Network routers transfer packets from one network to another, look into network packets, and make decisions about packet flow. Routers also create and update routing tables, and they can use more than four dozen different network protocols, such as RIP (router information protocol) and OSPF (open shortest path first). Even though this definition says nothing about security, network routers represent your network's first line of defense.

Routers are often described as firewalls, but I will discuss firewall protection and distinguish routers from specific firewall solutions in the next section. This is because routers are primarily responsible for directing the network flow, and as the result of rules, they implement a policy. Firewalls, on the other hand, are primarily responsible for securing network access by definition. Nevertheless, many modern routers implement stateful packet filtering, such as Cisco routers with the CBAC (context-based access control) feature, as well as several similar features, so they can indeed be called firewalls.

A typical router is a diskless system with some communication ports that let you hook up a workstation to program the device. The boot process of a router is very similar to a PC, but it loads the OS from flash memory, such as Cisco IOS (internetwork operating system).

During this process, the router also loads the configuration file, which can include statements to an access list or a set of access lists. The configuration file is managed by the router's administrator. Access lists are used to control the flow of the packets on some of the router's network interfaces, such as an Ethernet interface. An access list is a simple text file with a set of statements that permit or deny packets to flow on a network interface if a statement matches the characteristics of the packet. There are standard and extended access lists in Cisco routers.

For example, consider the following statement of an access list:

access-list 1 permit host 150.50.1.2

This access list would allow a packet coming from host 150.50.1.2 to flow through your router to your network. Access lists have statements like this in a top-down order. For example, if you prefer to deny traffic from one specific host but allow any other traffic, you would do the following:

access-list 1 deny host 150.50.1.2
access-list 1 permit any

Extended access lists also allow you to specify ports and the type of traffic, such as TCP, UDP, or ICMP. For example, if you wanted to allow traffic to your Web server only on port 80, you would use the following statement:

access-list 101 permit tcp any host 155.30.40.1 eq 80

You might want to disable any ICMP echo messages from getting to your network. This is a good idea because many worms use ICMP echo messages to check whether the target is available before they hit it. Furthermore, DoS attacks can be performed simply by pinging a target ceaselessly. When this is performed by a computer worm, the attack can be very effective against your systems, so you would certainly want to deny this possibility. You could use the following statement to stop such unwanted traffic:

access-list 101 deny icmp any any eq 8

ICMP type 8 is an echo request, but there are a dozen other ICMP types, and you should definitely consider blocking ICMP type 13 (timestamp requests) and ICMP type 17 (address mask requests).

To stop some popular DoS attacks such as a SYN flood, modern IOS versions support a module called TCP intercept, which can be used to deal with such attacks in two modes: watch mode and intercept mode. The default is intercept mode, which blocks attack attempts. You can enable TCP intercept with the following commands. (Note that the interception is related to an access list, so the first line is a definition of that.)

access-list 101 permit tcp any host 155.30.40.1 eq 80
ip tcp intercept list 101

If you have the rules set, what can go wrong? A number of attacks target Internet routers. For example, an attacker might decide to use packet fragmentation, so when the router looks at the incoming packet, the header information is fragmented among packets, which could result in a failure in applying the access rules. It is extremely important to disable packet fragmentation at places with top security. Because fragmentation can occur on a network under normal circumstances, such a rule might result in some conflict by accidentally filtering out important traffic on the network—so be sure to use it with care. The following command will disable any noninitial fragments:

access-list 111 deny ip any any fragments

Another important attack against routers is source spoofing. This kind of attack works with packets that appear to come from a trusted zone, such as from the internal network. This allows an attacker or a worm to send a UDP packet, for example, and specify a source address from your network to get in. So you need to think about implementing rules against such attacks, and your perimeter protection is the best place for these. Also remember that a router will not stop a CodeRed worm from getting to your Web server if it is vulnerable to an attack. After you open up a port, the malicious traffic can hit your vulnerable host and exploit the vulnerability.

Similarly, DoS attacks that are based on regular GET requests going to a Web server will also hit your server, so you also need to take care of this kind of attack. Don't forget about the patch level of your routers, either, such as the exact IOS version, because the router itself might become a target of computer worm attacks in the future—with devastating effects.

14.3 Firewall Protection

There are three basic kinds of firewalls: stateful, nonstateful, and proxy⁴. Stateful firewall solutions, as the name implies, track the state of network traffic (such as connections) and compare it against a policy. Some stateful firewalls, such as Cisco PIX, also can inspect some application-level protocols to see whether only regular commands are used on some known protocols, such as SMTP. If your SMTP server receives non-SMTP commands, the firewall will pretend to the sender that the bogus commands were accepted.

Nonstateful firewalls do not keep track of connections and thus are unable to correlate protocol information.

Proxy firewalls are closer to the actual protocols and can provide better security because they are more application-context-specific. Firewall implementations can vary according to the specific needs of each corporation and individual.

Firewalls can prevent worm infections and other attacks on your network in a number of ways. Typically, the most effective firewall feature against worms is simply to use your firewall to block any ports that you do not need to use on the systems behind it. You also can control the flow that goes back outside of your network. Corporations often allow their Web servers to initiate port 80/tcp access. This is not a good practice, however, for a number of reasons. You do not want to let your Web servers become Web browsers. If you do, a worm such as CodeRed might get into your network, and it will also be able to leave on port 80, as it came in. Select a firewall that allows you to control such flow, controlling the situation both ways.

Be sure to prepare your firewall in advance and maintain it continuously. By maintenance I don't mean blocking a port each time a worm targets a new port, but changing the firewall according to your changing requirements.

Table 14.1 illustrates some infamous worms that can be denied access by simply blocking ports on one of your firewalls (making sure not to block any ports that are used by actual services behind the firewall).

Table 14.1. In-the-Wild Worms, Related Vulnerabilities, and Ports to Block

Another common pitfall is when corporations rely on a single perimeter firewall on their network. Such protection might be bypassed in a number of ways by computer worms and other malicious attacks. For example, an infected home system will easily tunnel the infection in your network via a VPN (virtual private network) connection. It is imperative to use personal firewalls on workstations; once the attack is inside, it will have less chance to blow up internally. Personal firewalls can control malicious ICMP traffic and network sharing, just to name a few.

As you can see in the preceding examples, most attacks can be blocked by denying access to certain destination network ports; however, the Witty worm demonstrated that in some cases, port blocking might need to be done on the source port because the actual vulnerability in BlackIce can be exploited via any destination port. Witty also demonstrates very clearly that firewalls with vulnerabilities are increasingly becoming a target for attackers (in fact, exploitable vulnerabilities have been found in several Firewall implementations). Thus firewall software is just as likely to be exploitable as any other software, so it is mandatory to implement patches for it.

A proxy-based firewall, such as Raptor, can reduce a CodeRed worm attack to a minor DoS attack against the vulnerable IIS server. This is because an appropriately configured firewall cuts the request body of a GET request (and the worm), given that it is not valid in GET requests. (But, well, what if the attacker is using a POST request?)

It is of vital importance to use personal firewalls on workstations to prevent worm, backdoor, and spyware attacks. After a computer worm is running on your system, however, it might have the opportunity to kill your personal firewall software with a retro attack—reducing your protection. This is why the combination of appropriate protections is crucial.

Another increasingly common risk of personal firewalls is a backdoor that implements an HTTP tunneling attack. When such a backdoor is executed on a target system (for instance, via a downloader kit that exploits a Web browser vulnerability as you surf the Web), the backdoor might inject code into the process address space of your browser.

In their normal operations, personal firewalls alert on network access, so each time you run your Web browser, you get an alert from your personal firewall. It is a common option to allow a particular application to proceed with a default option set by the user. The danger in this is that the registered, legitimate Web browser application will be allowed to communicate with the network after this option has been selected, and an HTTP tunneling backdoor could easily inject code into the already registered application. This would allow the backdoor to use the privileges of the Web browser to tunnel information back to an attacker without any notification from your personal firewall. For that reason, modern personal firewalls must protect themselves from such attacks, which are possible in a number of different ways.

As with all security solutions, firewalls come with a performance penalty. Although stateful firewalls typically have better performance, they do not have the ability to deal with all application-level security concerns, which proxy firewalls can provide with a little slower performance. Unfortunately proxy firewalls are typically more susceptible to vulnerabilities caused by the introduced complexity of protocol parsing in which most vulnerability resides. This is a general problem for network-intrusion detection systems as well, however, which are discussed in the next section.

14.4 Network-Intrusion Detection Systems

Network-intrusion detection systems (NIDS) are becoming an important part of network security. NIDS sniff the network traffic and inspect both the traffic flow and its content.

There are two basic kinds of NIDS: network signatures-based and those based on network flow and protocol anomaly analysis. Some NIDS combine both methods.

1. The signature analyzer module matches signatures in the network data. Signatures can be written to analyze network protocol headers⁵ or to match a sequence of bytes in the data within the network packets. For example, signatures are matched in particular network traffic, such as HTTP, port 80 traffic only.
2. The network flow and protocol analyzer functionality of NIDS is practically a heuristics engine. For example, a giant protocol analyzer module can have knowledge of the most relevant protocols, such as HTTP, FTP, SMTP, and so on, and match any anomalies in the protocols. For example, a protocol analyzer can detect the CodeRed worm as an overly long URL. Similarly, a protocol anomaly analyzer can alert the user any time a particular field, in any part of a known protocol, is overly long. This allows NIDS to detect generically many possible exploitation techniques that are based on overflowing some field of network protocol structures, causing a buffer overflow condition on the target.

If a firewall comes with a performance penalty on your network, so does a NIDS. A good NIDS must use a packet reassembler, and this process can be very performance intensive.

For example, the intrusion detection system, Snort (www.snort.org), authored by Marty Roesh, has the following major components⁶:

• Packet decoder: This module picks the packets coming in from the various interfaces and passes them to the preprocessor.

• Preprocessor: This module is very important because it handles some of the common attacks that can be executed using simple signature insertion attacks⁷. This module also handles the reassembling of network packets, which is important because signatures can overlap between packets, fragmenting network traffic. In addition, packets can come out of order, and the reassembler must put the puzzle together using the sequence numbers in the packets. Because reassembling is very costly, some intrusion-detection systems try to become faster by simply pretending that they only need to analyze normal traffic. This obviously reduces IDS's capability to detect advanced attacks precisely. Although normal traffic rarely gets fragmented, attackers can force fragmentation to bypass NIDS systems.

• Detection engine: This component matches the rules against the reassembled network stream. It is vital to have a fast matching engine to allow more signatures to be matched. If this component of the IDS is slow, the IDS might start to drop packets when there are too many signatures to match. When the detection engine finds a known signature, it calls the alerting and logging module.

• Altering and logging module: This module generates an alert and places it in the appropriate output, such as a log file. Because intrusion detection systems might produce many alerts, it is becoming increasingly popular to outsource IDS monitoring, in case a corporation does not have enough trained resources to do the monitoring 24/7 in house.

An IDS can be placed in as many places on your network as you desire, but keep in mind whether or not you have the available resources to process all the alerts that will be generated. Several IDS products are capable of producing reports that can be imported into a database and can correlate the IDS alerts further with other security events on your network—to help eliminate duplicate alerts or to escalate lower-level alerts to higher levels.

A common place for a NIDS is the perimeter, somewhere close to your firewall, as shown in Figure 14.1.

Another important decision is how to hook up an IDS. There are two different basic modes for IDS: logging and blocking. In logging mode, an IDS might be hooked up on a port of a network switch that receives replicated traffic. In this mode, the IDS will generate an alert but will not be able to drop the packet to prevent the attack. In this mode, the malicious packet might hit the target, but at least your “smoke detector” might alert you about it so that you can respond appropriately at once. Needless to say, an IDS works much faster in logging mode.

In blocking mode, the IDS will stall the network traffic and inspect it before the malicious traffic can arrive at the target. This solution allows the malicious traffic to be dropped, but it is usually much more performance-intensive than logging mode. Performance can be much more effective for IDS solutions that deploy anomaly detection engines; there will be less need for signatures to match malicious traffic. However, specific IDS signatures can help to refine an attack and provide better security for protocols not yet supported by the anomaly detection engine. A hybrid solution is usually the best, combining the two techniques for increased security.

Later in this chapter, I will introduce several network captures of computer worms and discuss IDS signature development in both threat-specific and generic forms.

14.5 Honeypot Systems

Honeypots are decoy systems that attract attackers to attempt to compromise them. Because a honeypot typically has low security inbound but higher security outbound, even novice attackers can compromise them easily—not to mention computer worms, which will be even more excited about them. As a result, the motives and the tactics of the attacker can be learned. I especially enjoy the works of Lance Spitzner, who has spent many years running honeypot systems. Lance was among the first people to recognize the value of honeypot systems against computer worms and other malicious threats, and he is dedicated to sharing his research results.

The concept of the honeypot was introduced in 1990 by Clifford Stoll's “The Cuckoo's Egg” and Bill Cheswick's “An Evening with Berferd.” Not surprisingly, it was Fred Cohen who introduced the first publicly available honeypot solution, the Deception Toolkit in 1997².

Spitzner distinguishes between two basic kinds of honeypot systems: low and high interaction. A low-interaction honeypot simply emulates some network services. It might be able to capture some parts of the attack, but because the attack might not have a chance to complete, it might not be captured and understood. On the other hand, high-interaction honeypots might be vulnerable, real systems or a set of vulnerable systems among different operating systems. (In addition, some high-interaction honeypot solutions such as Collapsar⁸ are implemented with both real and virtual machines, and the attacks against individual honeypots in the system are correlated.) A high-interaction honeypot might get compromised completely, and the attacker might be able to download even more tools to the system, which can consequently be captured. Similarly, when computer worms penetrate a target, they can be captured and sent to an analysis center for automated processing. This will be discussed in more detail in Chapter 15, “Malicious Code Analysis Techniques.”

A very simple example of a honeypot can be illustrated with the use of NetCat (NC), which has already been used in various chapters of this book. The following command can capture HTTP traffic on a dedicated system:

NC –l –p 80 >http.log

This command instructs NetCat to listen on port 80 (HTTP) and redirect the incoming traffic to a log file. Although this is a fairly low-interaction honeypot, it is good enough to capture the CodeRed worm because CodeRed simply sends a GET request to a random target. So if the previous command is executed on a system without a firewall to block incoming traffic, CodeRed will be captured in the http.log file as soon as CodeRed sends itself to the IP address where NC listens. In fact, this is exactly what Ryan Russel did to capture CodeRed quickly and successfully. This method also can be used to capture a worm like Slammer, which uses UDP to hit a vulnerable Microsoft SQL Server without any fingerprinting involved.

The NetCat command would be the following:

NC –l –p 1434 –u >ms-sql.log

To take this one step further, some low-interaction honeypots, such as Back Officer Friendly, are listening on a few ports to capture attacks in a way very similar to the previous NetCat example. Figure 14.2 shows Roger Thomson's Worm Radar, which also uses the listening principle to capture interesting network traffic, match it against known signatures, and build statistics from all the deployed honeypot solutions. Roger captured several worms, including minor variants of CodeRed, which he noticed with the use of exact identification built into the matching engine of Worm Radar. Indeed, it is vital for all honeypot systems to identify already known attacks. Roger's program also tricks worms into revealing their body to Worm Radar. Thus the specific communication needed to capture new variants of the worms is in place.

Figure 14.2. Worm Radar showing the World view of captured attacks.

Another example of a low-interaction system is Honeyd (http://www.honeynet.org) by Niels Provos⁹. Honeyd can interact with attackers and computer worms a little better than the previously mentioned solutions because it can pretend to be many different systems. Honeyd can capture ARP (Address Resolution Protocol) requests¹⁰ that do not belong to any target system and act as if it were the system in question. As a result, a computer worm can have fun with Honeyd and communicate with it, but the services are emulated by Honeyd without any vulnerability (so not all worms can be captured by it completely without some special tricks in place).

Some computer worms, such as Linux/Slapper, are more difficult to capture because the target needs to interact more extensively with the attacker system. Not only does Linux/Slapper fingerprint the target (as explained in Chapter 9, “Strategies of Computer Worms”), it also exploits the target twice (as explained in Chapter 10, “Exploits, Vulnerabilities, and Buffer Overflow Attacks”) before it uploads its source code to the target. Such worms need a high-interaction honeypot solution to be captured successfully. Such honeypots are often called research honeypots.

Another interesting solution is LaBrea, a so-called “sticky honeypot” developed by Tom Liston (http://labrea.sourceforge.net). LaBrea can capture ARP requests on your network, very effectively slowing down or stopping computer worms on a network. Unfortunately, LaBrea quickly became a target of the Digital Millennium Copyright Act (DMCA); as a result, Tom Liston pulled its sources in 2003 (see www.hackbusters.net).

Throughout this chapter, the worm captures will have many examples of ARP requests generated by computer worms as they scan for new targets on a network.

Not only can decoy systems be useful to study and protect against computer worms and exploitation, but they also can be a useful technique against all forms of spam. For example, the Brightmail spam detection system utilizes millions of decoy e-mail addresses that are populated to attract spammers using a variety of techniques. E-mail received on decoy accounts are likely to be originated from spammers especially if the same (or similar) e-mail is received on more than one or a very large number of decoy accounts. The system can collect the data from the decoy accounts and use it directly to generate spam filter rules, effectively preventing classified spam from being transmitted at major Internet service providers (ISPs) around the world.

14.6 Counterattacks

An interesting opportunity for the defender is the possibility of counterattacking a worm-compromised remote system in an attempt to clean it. Several security professionals have experimented with using counterattacking worms to clean worms from a remote system; not surprisingly, some have been convicted as a result. As explained in Chapter 9, competition between various kinds of worms often results in a worm war: one worm killing another worm or set of worms. Although this kind of attack sounds like a beneficial worm attack, it is an unacceptable method for several obvious reasons—and it could result in criminal prosecution.

So what can you do when the idea crosses your mind to counterattack a worm that is clearly out of control on your network? You might be able to attack systems that are under your control; by “under control” I mean that the systems should belong to you.

For example, if your network administrator asks you to assist in cleaning up some in-house CodeRed infections, you could help him out. To solve the problem, you could collect a large set of local IP addresses from firewall logs and use NC (NetCat) to send a short attack (“cure”) packet to each system suspected as a CodeRed attacker.

The attack packet can contain exploit code similar to the one built into CodeRed, but a return address should be set to zero using the exploit, and of course, there is no need for worm code of any kind! The attack packets might be sent to each machine suspected to be infected with CodeRed, according to personal firewall logs, for example.

When the zero return address hits, it generates a page fault in the process address space of vulnerable Microsoft IIS, cleaning the CodeRed infection as a result. This is because the fault quickly restarts the vulnerable service without CodeRed. (As discussed in Chapter 10, CodeRed is only present in memory.) Of course, the counterattack would not be so simple in the case of worms involving files or vulnerabilities that cannot be exploited more than once.

Make sure that there are no mission-critical systems involved, so that this quick-and-dirty method can be used to clean a network effectively in seconds. Of course, you might need three repeated shots before the counterattack packets do their job.

Some people would argue that any infected system should be cleaned, so they counterattack remote systems that do not belong to them, without asking permission from the system's actual owner. This presents a dilemma: It would be great to stop the infections on all remote systems, but there is a chance that the counterattack might be harmful in some way to the infected remote system, resulting in data loss, so as a general advice, always think first before you proceed!

Also note that some network-level vulnerability assessment tools might have a side effect that can be used to clean up worm infections in a similar fashion to the previous example—but such tools might have similar implications. For example, a possible implication is data loss as a result of exploitation of a remote system (for instance, an unprocessed or partial transaction to a Web or SQL server).

14.7 Early Warning Systems

Early warning systems get data from a number of different network sensors, such as a firewall, network IDS, host IDS, antivirus protection, honeypot, or honeynet solutions, and place the alerts into a central database. The alerts are processed and correlated, and an appropriate warning is generated. Symantec generates alerts using the DeepSight early warning system. In DeepSight alerts, you also can see the correlation of a possible new attack with a set of known vulnerabilities that were previously logged into the BugTraq database, as well as the appropriate prevention suggestion to deploy patches and an exposure level to the possible or identified threat.

The alerts of such a system can be extremely valuable for quick response to a new attack that has already been seen on other systems. In many cases, you have a chance to respond to an attack before it reaches your network—thus early warning systems do not directly protect your system. Instead, you supply data to such systems and, as a result, better protect the community as a whole.

14.8 Worm Behavior Patterns on the Network

This section discusses a few interesting network captures of computer worms as they propagate from one computer to another. Detailed examination of such captures is useful in seeing how typical exploitation can be experienced on the wire when the network traffic is examined with a packet sniffer, such as tcpdump¹¹. Always use such tools with the network administrator's permission because you might accidentally capture sensitive data from the network.

14.8.1 Capturing the Blaster Worm

In the first example, shown in Figure 14.3, I browse a network capture of the W32/Blaster worm using Ethereal¹².

Figure 14.3. A network capture of a W32/Blaster worm infection with Ethereal.

I really like to use Ethereal, a popular sniffer and network traffic analyzer tool to browse network captures. I suggest that you use the exploit analysis of Blaster in Chapter 10 and match it with the behavior pattern of the worm in this network capture. In this particular example, the IP address 192.168.0.1 belongs to the attacker system, which is already compromised by Blaster. The IP address 192.168.0.3 (also on a local test network) is currently under attack by Blaster.

Notice the 1314 > 4444 TCP port communication between the attacker and the target (frame 42 in Figure 14.3). The attacker machine is communicating with the shellcode running on the newly compromised system on 192.168.0.3. Shortly after this (frame 48), you can see a TFTP read request for a file called msblast.exe.

This is the TFTP request that the Blaster attacker system sends to the newly compromised host, which already runs a command prompt on 4444/tcp. Notice that 192.168.0.3 runs the TFTP command and downloads from 192.168.0.1, where the Blaster attacker system waits with a “TFTP server” thread of the worm to fulfill this request. You can follow as the TFTP request is processed and the main worm body travels over the wire to the newly compromised system. Of course, all this might be less exciting to see when it happens on your own network. In this example, the two machines reside on a test network used for natural infections. (Chapter 15 explains more about natural infection strategies and analysis techniques and introduces a few more network captures of worm attacks.)

Next, in frame 82 of Figure 14.3, you can see that the attacker system again communicates with its shell on the newly compromised host and sends a “start msblast.exe” command (see the packet dump in the lower panel of Ethereal).

At that point, the worm starts to run on the newly attacked system. You also can see that action because 192.168.0.3 suddenly starts to send broadcast ARP requests such as “Who has 192.168.0.2? Tell 192.168.0.3,” “Who has 192.168.0.4? Tell 192.168.0.3,” and so on, as it scans the network for other machines. This behavior pattern is very typical of computer worms.

You can easily target Blaster with a NIDS system. One possibility is to check for exploit code in the first few packets, which allows you to log attacker systems on your network quickly. Another possibility is simply to look for the string “start msblast.exe,” to see when a new system gets compromised. When you see this request, you will know that your systems are still not patched with the new security updates required to eliminate the vulnerability exploited by the worm.

14.8.2 Capturing the Linux/Slapper Worm

As Chapter 10 discusses in detail, the Slapper worm exploited an OpenSSL vulnerability on Apache Web servers that involved exploitation on the heap. It is important to understand the specifics of heap exploitation to be able to build host-based intrusion prevention techniques similar to those discussed in Chapter 13, “Worm-Blocking Techniques and Host-Based Intrusion Prevention.” On the other hand, from the point of view of network-level defense, there are other interesting questions that you might ask. In particular, the worm exploits OpenSSL, so it is interesting to double-check whether or not the worm is encrypted on the wire. In some of the existing computer security literature, the Slapper worm is already discussed as a worm that “cannot be effectively detected with NIDS because someone would need to compromise the security provided by SSL.” As I will demonstrate next, however, this statement is false.

Figure 14.4 is a capture of the Linux/Slapper worm where the IP address 206.129.0.1 is compromised by Slapper and attacks 206.129.254.254. Of course, all of this happens on our lab network, just like any other captures, so the IP address does not have to do anything with real-world targets.

Figure 14.4. A network capture of the Linux/Slapper worm infection with Ethereal.

You can see the double-take action of the two “Client Hello” messages; Slapper exploits the target twice. When the worm exploits the target the first time, the target leaks valuable information, which is used in the second exploit phase to gain proper control of the target.

Ethereal also expects that the wire contains encrypted data in frame 53, shown in Figure 14.4. Normally, this would be the case, and Ethereal would be right. However, the worm exploits the target before the encryption is established on the wire. You can see in the lower Ethereal window that some of the worm's commands are passing in the payload as plain text instead of cipher text. This is a clear indication that there is no encryption established between the two systems.

You can see that the first command is rm (remove), followed by a cat command, which creates Slapper's UU-encoded source file on the target. The propagation of the worm is visible in plain text over the wire, so there should be no problem detecting the worm using standard NIDS.

A Snort NIDS signature to detect Linux/Slapper could be the following:

alert tcp any any -> any 443 (msg:"Linux/Slapper Worm Propagation";
content:"36 35 35 20 2E 62 75 67 74 72 61 2e 63";)

This alert is generated when the string 655 .bugtraq.c is detected in a packet transmitted on port 443/tcp, which should not be the case. An SSL connection would always transmit cipher text in normal circumstances, and the filename is unique.

Note, however, that the filename might be the first thing that someone would change in a new variant of a worm, so a more appropriate NIDS signature could also investigate the key argument length field and check whether that value is larger than eight, which is the maximum allowed (as discussed in Chapter 10). I define this type of detection as a generic intrusion signature. Figure 14.5 shows a network capture of Linux/Slapper with a large key argument length field set to 64.

Figure 14.5. A Client Master Key message with a key_arg length set to 64.

The detection of the overly large key_arg length makes it possible to alert on related exploit codes generically without dealing with the specifics of each individual attack.

In the real world, it is important to identify an attack more precisely. You really want to know whether the NIDS alert is related to a Slapper worm or is coming from an individual attacker. Therefore, modern NIDS systems include two-phase detection: One phase detects attacks generically and quickly, and a second detection, triggered by the first, further identifies the attack. Because NIDS engines are hard-pressed to work fast (otherwise they start to drop packets), it is vital to implement more exact detections only after a quick filter, which is the first detection.

Such logic can help to deal with polymorphic attacks that give shellcode polymorphic abilities. Examples of such attacks are ADM_Mutate, libSchellCode, S-poly, and JempiScodes¹³.

14.8.3 Capturing the W32/Sasser.D Worm

The W32/Sasser.D worm was released by a German virus writer and was interesting because it targeted a Microsoft LSASS vulnerability. In Figure 14.6, you can see the worm send its code from the already compromised 10.10.10.34 attacker system to the currently exploited system on 10.10.10.36.

Figure 14.6. A network capture of the W32/Sasser.D worm.

So what is the interesting part of this attack? It appears that the first byte of the executable worm body is sent alone and shows as Len=1 in frame 90 of Figure 14.6. In the lower pane of Ethereal, you can see an M character as the payload of the packet. This is the first byte of the PE file of the worm body that starts with the MZ header. The following part of the worm executable header will start with Z in frame 91, in which a payload with a Len=1460 bytes is sent, typical on Ethernet networks.

Indeed, the worm sends itself byte by byte on the network, but without specifying an immediate sending, the IP stack will be reassembled locally, and usually a complete payload will be sent to the target. There is no guarantee, however, that the reassembling will always happen, and this can split the worm body along short packet boundaries.

Although Sasser does not attack NIDS directly, it demonstrates that worms can indeed split their exploit code to a byte-per-payload style of transfer if they specifically ask to do so. Not all NIDS have proper packet reassembling abilities, as mentioned earlier. As a result, the IDS signature of the attack might not match because the signature is split on the wire into several packets, each with a payload a few bytes long.

As an example, the CodeRed worm is normally sent in the form shown in Figure 14.7A, but a trickier variant of the worm could send its code with randomly split payload sizes, as shown in Figure 14.7B, challenging IDS implementations that do not have traffic reassembling.

Both of these methods could work correctly. Depending on the packet reassembling and signature engine abilities of a NIDS, however, the signature of the worm might not be matched correctly. This example illustrates why packet reassembling is such an important module for a properly developed IDS.

Figure 14.7. The exploit code of the CodeRed worm in complete and split forms.

14.8.4 Capturing the Ping Requests of the W32/Welchia Worm

The sad reality is that many network administrators who have corporate permission to run sniffer tools often do not really know how to use such tools to look for worm infections. As a result, they do not perform this kind of logging routinely. Such logging techniques can be useful in preparing for a worm attack in advance or in helping to eliminate an already existing in-house infection. In this section, I illustrate the use of the tcpdump tool, which is included by default in many UNIX distributions. It has become the Swiss-army knife of intrusion detection; as you will see, it is also an effective honeypot tool.

In the capture shown in Figure 14.8, you can see the Welchia worm ping the destination address 169.254.189.84 from the 169.254.56.166 address. Before Welchia attempts to exploit a new target, it wants to get a positive answer to an ICMP echo request.

Figure 14.8. The ping request of the W32/Welchia worm.

Notice the content of the ICMP echo request data in the lower pane of Ethereal. The worm uses a 0xAA filler byte to preinitialize the data structure for the ping request, instead of using zero bytes. This allows you to trace the worm's ping request with a network-capturing sniffer tool, such as tcpdump or windump (which relies on winpcap¹⁴).

If you want to track Welchia infections based on the special ping request data, use the following command¹⁵:

tcpdump -qn icmp and ip[40] = 0xaa

You can do the same on a Windows machine (using windump):

windump -qn icmp and ip[40] = 0xaa

This command instructs the sniffer to log ICMP traffic but reduces the scope of logging to special ICMP echo requests, which have a 0xAA filler byte at position 40 inside their request. Similar tools, such as ngrep, also can be used to perform even more complicated string matching using regular expressions.

14.8.5 Detecting W32/Slammer and Related Exploits

The W32/Slammer worm targets vulnerable Microsoft SQL servers on port 1434/udp. The only thing the worm requires is to send a datagram to the actual port. Vulnerable installations of Microsoft SQL Server will execute the worm when processing the UDP request.

Figure 14.9 shows a snippet of the Slammer worm. As discussed in Chapter 10, the exploit code built into Slammer requires a special ID in front of the worm's code. This special byte, 0x04, would be normally followed by a short string, but there is no bound checking in the code, and the stack is overflowed when a large string is received. Notice the number of filler (0x01) bytes in the worm, which shift a return address value to the proper spot.

Figure 14.9. A snippet of a Slammer worm dump loaded to HIEW.

I will use this dump to demonstrate exploit detection using NIDS software. Normally, you could use a worm-specific signature to detect this attack, and it is certainly a good idea to refine your detection and have a clue whether the actual exploit you have detected is related to Slammer. So here is the Symantec ManHunt Hybrid signature, which pretty much follows the format of a Snort signature in this example:

alert udp any any -> any 1434 (msg:"W32/Slammer Worm Propagation";
content:"|68 2E 64 6C 6C 68 65 6C 33 32 68 6B 65 72 6E|";
content:"|04|"; offset:0; depth:1;)

We generate an alert whenever any traffic targets any IP address with a 1434/udp port. We alert with the message “W32/Slammer Worm Propagation” whenever we find the h.dllhel32hkern string anywhere in the datagram. We also have 0x04 as the first byte of the packet to double-check that we are dealing with the exploit. This signature will detect Slammer effectively, however. If you want to prepare a generic detection to detect the exploit code, you could use the following signature to do so:

alert udp any any -> any 1434 (msg:"MS02-039 exploitation detected";
content:"|04|"; offset:0; depth:1; dsize>60)

This alert is very similar to the first one. In fact, it matches the first byte of the datagram, just as the worm-specific signature does. I do not use the previous sequence of bytes, but the dsize command instead, to check whether the datagram is longer than 60 bytes. In this way, we know that a vulnerable SQL Server would be under attack since a 128-byte buffer is overflowed. There are two constant strings used by SQL Server to build a Registry key when the server receives this request (as discussed in Chapter 10), hence a dsize larger than 60 will always result in an overflow condition—and at least a DoS attack.

Of course, you could argue that such signatures are more prone to false positives, but you can also see that they are less prone to false negatives. Indeed, the remaining ambiguity is a general problem of NIDS. How could the NIDS tell whether or not the UDP port 1434 traffic is related to an SQL Server on the target system? This is why more specific IDS signatures always cause fewer false positives.

Such signatures, however, can be very helpful. Imagine if Slammer were polymorphic or even metamorphic—no actual bytes of the worm would be the same in different instances of the worm body on the wire. Unless the worm exploited several vulnerabilities, it would need to present the 0x04 byte in the front of the datagram and represent itself as a long-enough string. Thus the preceding generic IDS signature would also cover the polymorphic version of the worm.

In fact, modern IDS detection languages support programmable signatures. For example, such signatures use a histogram to check quickly whether there are any zero bytes in a range of the stream. Indeed, it would be better to use such filters in the preceding signature to reduce false positives further. Slammer cannot use a zero byte anywhere in its body because the worm's body is processed as a “string.” Similarly, any exploit code targeting this vulnerability would need to avoid using zeros long enough to exploit the overflow condition successfully. As a result, even a polymorphic or metamorphic worm would be detected via the “frame” conditions of the exploit.

14.9 Conclusion

This chapter presented network-level defense techniques that focused on prevention, defense, and capturing of computer worm attacks. You could learn many interesting details about computer worm propagation patterns from the network perspective. The next chapter takes this one step further, discussing techniques for analyzing malicious programs.

References

1. Stephen Northcutt and Judy Novak, Network Intrusion Detection: An Analyst's Handbook, 2nd Edition, New Riders, Indianapolis 2001, ISBN: 0-7357-1008-2 (Paperback).

2. Lance Spitzner, Honeypots: Tracking Hackers, Addison-Wesley, Boston 2003, ISBN: 0-321-10895-7 (Paperback).

3. E. Eugene Schultz, Ph.D, “The MSBlaster worm: going from bad to worse,” Network Security, October 2003, pp. 4-8.

4. Stephen Northcutt, Lenny Zeltser, Scott Winters, Karen Kent Frederick, and Ronald W. Ritchey, Inside Network Perimeter Security, New Riders, Indianapolis 2003, ISBN: 0-73571-232-8 (Paperback).

5. W. Richard Stevens, TCP/IP Illustrated, Addison-Wesley, Boston 1994, ISBN: 0-201-63346-9 (Hardcover).

6. Rafeeq Ur Rehman, “Intrusion Detection with SNORT,” Prentice Hall, Upper Saddle River, 2003, ISBN: 0-13-140733-3 (Paperback).

7. Thomas H. Ptacek and Timothy N. Newsham, “Insertion, Evasion, and Denial of Service: Eluding Network Intrusion Detection,” January 1998, http://www.insecure.org/stf/secnet_ids/secnet_ids.html.

8. Xuxian JiangDongyan Xu, “Collapsar: A VM-Based Architecture for Network Attack Detection Center,” 13th Usenix Security Symposium, 2004, pp. 15-28.

9. Ofrin Arkin, Edward Balas, Brian Carrier, Roshen Chandran, Anton Chuvakin, Michael Clark, Eric Cole, Yannis Corovesis, Jeff Dell, J. RaulGarcia Zapata, Max Kilger, Charalambos Koutsouris, Richard LaBella, Rob Lee, Costas Magkos, Patrick McCarty, Doin Mendel, Yannis Papapanos, Richard P. Salgado, Lance Spitzner and Jeff Jtutzman, “Know Your Enemy,” The Honeynet Project, 2nd Edition, Addison-Wesley, Boston 2004, ISBN: 0-321-16646-9 (Paperback).

10. Douglas E. Comer, Internetworking with TCP/IP, Prentice Hall, Upper Saddle River 2000, 1995, ISBN: 0-13-018380-6 (Hardcover).

11. The TCPDump public repository, http://www.tcpdump.org/.

12. “Ethereal: A Network Analyzer,” http://ethereal.com/.

13. Elias Levy, private communication, 2004.

14. Winpcap, http://winpcap.polito.it/.

15. Frederic Perriot, private communication, 2004.