chapter 14. network-level defense strategies

8/14/2019 Chapter 14. Network-Level Defense Strategies

http://slidepdf.com/reader/full/chapter-14-network-level-defense-strategies 1/20

Chapter 14. Network-Level Defense Strategies

" Attack him where he is unprepared; appear where you are not expected."

Sun Tzu, The Art of War

The previous chapters have discussed defense techniques that focus on host-based solutions. This short chapterntroduces 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

n this chapter, I will focus on worm behavior patterns with several network-level worm captures and relateddetection and prevention technology. I will avoid giving too much background information, which could easilymake 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 itomes 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 up1.

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

hat are accessed locally. You also can see the possible placement of a few honeypot systems 2, which arediscussed 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 oftenmplement 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, buts you will see, they are highly important in dealing with network attacks against individual hosts on your

network 3.

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

14.2. Using Router Access Lists

Network routers transfer packets from one network to another, look into network packets, and make decisionsbout 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). Evenhough 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 frompecific 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 primarilyesponsible 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 severalimilar 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 toprogram the device. The boot process of a router is very similar to a PC, but it loads the OS from flash memory,

uch as Cisco IOS (internetwork operating system).

During this process, the router also loads the configuration file, which can include statements to an access list orset of access lists. The configuration file is managed by the router's administrator. Access lists are used to

ontrol the flow of the packets on some of the router's network interfaces, such as an Ethernet interface. Anccess list is a simple text file with a set of statements that permit or deny packets to flow on a network interfacef a statement matches the characteristics of the packet. There are standard and extended access lists in Ciscoouters.

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

ccess-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 onepecific host but allow any other traffic, you would do the following:

ccess-list 1 deny host 150.50.1.2

ccess-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

xample, if you wanted to allow traffic to your Web server only on port 80, you would use the followingtatement:

ccess-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 becausemany 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 computerworm, the attack can be very effective against your systems, so you would certainly want to deny thispossibility. You could use the following statement to stop such unwanted traffic:

ccess-list 101 deny icmp any any eq 8

CMP type 8 is an echo request, but there are a dozen other ICMP types, and you should definitely considerblocking 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 TCPntercept, 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 followingommands. (Note that the interception is related to an access list, so the first line is a definition of that.)



ccess-list 101 permit tcp any host 155.30.40.1 eq 80

p tcp intercept list 101

f you have the rules set, what can go wrong? A number of attacks target Internet routers. For example, anttacker might decide to use packet fragmentation, so when the router looks at the incoming packet, the headernformation is fragmented among packets, which could result in a failure in applying the access rules. It is

xtremely important to disable packet fragmentation at places with top security. Because fragmentation canoccur on a network under normal circumstances, such a rule might result in some conflict by accidentallyiltering out important traffic on the networkso be sure to use it with care. The following command will disableny noninitial fragments:

ccess-list 111 deny ip any any fragments

Another important attack against routers is source spoofing. This kind of attack works with packets that appearo 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 aboutmplementing rules against such attacks, and your perimeter protection is the best place for these. Alsoemember that a router will not stop a CodeRed worm from getting to your Web server if it is vulnerable to anttack. 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,o you also need to take care of this kind of attack. Don't forget about the patch level of your routers, either,uch as the exact IOS version, because the router itself might become a target of computer worm attacks in theuturewith devastating effects.

14.3. Firewall Protection

There are three basic kinds of firewalls: stateful, nonstateful, and proxy4. Stateful firewall solutions, as thename implies, track the state of network traffic (such as connections) and compare it against a policy. Sometateful firewalls, such as Cisco PIX, also can inspect some application-level protocols to see whether onlyegular commands are used on some known protocols, such as SMTP. If your SMTP server receives non-SMTPommands, 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 morepplication-context-specific. Firewall implementations can vary according to the specific needs of each

orporation and individual.

Firewalls can prevent worm infections and other attacks on your network in a number of ways. Typically, themost effective firewall feature against worms is simply to use your firewall to block any ports that you do notneed 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,or a number of reasons. You do not want to let your Web servers become Web browsers. If you do, a wormuch as CodeRed might get into your network, and it will also be able to leave on port 80, as it came in. Select airewall 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



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 yourirewalls (making sure not to block any ports that are used by actual services behind the firewall).

Another common pitfall is when corporations rely on a single perimeter firewall on their network. Suchprotection might be bypassed in a number of ways by computer worms and other malicious attacks. Forxample, 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 willhave less chance to blow up internally. Personal firewalls can control malicious ICMP traffic and network haring, just to name a few.

As you can see in the preceding examples, most attacks can be blocked by denying access to certain destination

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

Name of Threat Exploited Vulnerabilities Ports to Block

W32/CodeRed worm MS01-033 ("IIS") TCP 80

W32/Blaster worm MS03-026 ("RPC/DCOM") TCP 135, TCP 4444 (andif not used UDP 69)

W32/Slammer worm MS02-039 and MS02-061("MS-SQL")

UDP 1434

W32/Sasser worm MS04-011 ("LSASS") TCP 445, 5554, and 9996

W32/Dabber worm Exploits vulnerability in "FTPServer" of the Sasser worm

TCP 5554 (Sasser)

TCP 8967, 9898-9999

W32/Korgo worm MS04-011 ("LSASS") TCP 445, 113, 3067-3076, and 6667

W32/Welchia worm MS03-026 ("RPC/DCOM")

MS03-007 ("WebDav")

TCP 135 and TCP 80when not used

W32/Welchia.D worm MS03-026 ("RPC/DCOM")

MS03-007 ("WebDav")

MS03-049 ("Workstation")

MS03-001 ("Locator")

+Mydoom backdoor

TCP 80, 135, 445 (whennot used)

TCP 3127 (Mydoom)

Linux/Slapper worm CAN-2002-0656

OpenSSL vulnerability

TCP 80, 443, and UDP2002

W32/Witty worm ISSSA ICQ parsing

vulnerability

Source port UDP 4000



network ports; however, the Witty worm demonstrated that in some cases, port blocking might need to be doneon the source port because the actual vulnerability in BlackIce can be exploited via any destination port. Wittylso demonstrates very clearly that firewalls with vulnerabilities are increasingly becoming a target for attackersin fact, exploitable vulnerabilities have been found in several Firewall implementations). Thus firewalloftware 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 GETequest (and the worm), given that it is not valid in GET requests. (But, well, what if the attacker is using a

POST request?)

t is of vital importance to use personal firewalls on workstations to prevent worm, backdoor, and spywarettacks. After a computer worm is running on your system, however, it might have the opportunity to kill your

personal firewall software with a retro attackreducing your protection. This is why the combination of ppropriate protections is crucial.

Another increasingly common risk of personal firewalls is a backdoor that implements an HTTP tunnelingttack. 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 spaceof your browser.

n 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 proceedwith a default option set by the user. The danger in this is that the registered, legitimate Web browserpplication will be allowed to communicate with the network after this option has been selected, and an HTTPunneling 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 anynotification from your personal firewall. For that reason, modern personal firewalls must protect themselvesrom 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 typicallyhave better performance, they do not have the ability to deal with all application-level security concerns, whichproxy firewalls can provide with a little slower performance. Unfortunately proxy firewalls are typically moreusceptible 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, whichre 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 he 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 protocolnomaly 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 headers5 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. Forexample, a giant protocol analyzer module can have knowledge of the most relevant protocols, such asHTTP, FTP, SMTP, and so on, and match any anomalies in the protocols. For example, a protocolanalyzer can detect the CodeRed worm as an overly long URL. Similarly, a protocol anomaly analyzercan 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 somefield of network protocol structures, causing a buffer overflow condition on the target.

f a firewall comes with a performance penalty on your network, so does a NIDS. A good NIDS must use apacket 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

ollowing major components6:

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

Preprocessor: This module is very important because it handles some of the common attacks that can be

executed using simple signature insertion attacks7. 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 thesequence numbers in the packets. Because reassembling is very costly, some intrusion-detection systemstry to become faster by simply pretending that they only need to analyze normal traffic. This obviouslyreduces IDS's capability to detect advanced attacks precisely. Although normal traffic rarely getsfragmented, 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 detectionengine 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, suchas a log file. Because intrusion detection systems might produce many alerts, it is becoming increasinglypopular to outsource IDS monitoring, in case a corporation does not have enough trained resources to dothe 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 youhave 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 otherecurity events on your networkto help eliminate duplicate alerts or to escalate lower-level alerts to higherevels.

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 andblocking. In logging mode, an IDS might be hooked up on a port of a network switch that receives replicatedraffic. In this mode, the IDS will generate an alert but will not be able to drop the packet to prevent the attack.n this mode, the malicious packet might hit the target, but at least your "smoke detector" might alert you aboutt so that you can respond appropriately at once. Needless to say, an IDS works much faster in logging mode.



n blocking mode, the IDS will stall the network traffic and inspect it before the malicious traffic can arrive athe target. This solution allows the malicious traffic to be dropped, but it is usually much more performance-ntensive 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 IDSignatures can help to refine an attack and provide better security for protocols not yet supported by thenomaly detection engine. A hybrid solution is usually the best, combining the two techniques for increasedecurity.

Later in this chapter, I will introduce several network captures of computer worms and discuss IDS signaturedevelopment 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

ypically has low security inbound but higher security outbound, even novice attackers can compromise themasilynot to mention computer worms, which will be even more excited about them. As a result, the motivesnd 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 honeypotystems 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 BillCheswick's "An Evening with Berferd." Not surprisingly, it was Fred Cohen who introduced the first publicly

vailable honeypot solution, the Deception Toolkit in 19972.

Spitzner distinguishes between two basic kinds of honeypot systems: low and high interaction. A low-

nteraction honeypot simply emulates some network services. It might be able to capture some parts of thettack, but because the attack might not have a chance to complete, it might not be captured and understood. Onhe other hand, high-interaction honeypots might be vulnerable, real systems or a set of vulnerable systems

mong different operating systems. (In addition, some high-interaction honeypot solutions such as Collapsar8 re implemented with both real and virtual machines, and the attacks against individual honeypots in the systemre correlated.) A high-interaction honeypot might get compromised completely, and the attacker might be ableo 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 willbe 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 becauseCodeRed simply sends a GET request to a random target. So if the previous command is executed on a systemwithout a firewall to block incoming traffic, CodeRed will be captured in the http.log file as soon as CodeRedends 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



vulnerable Microsoft SQL Server without any fingerprinting involved.

Note

Existing literature suggests that Slammer pings its target first, but this is not the case.

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 aew 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 itgainst 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 thematching 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 communicationneeded to capture new variants of the worms is in place.

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

[View full size image]

Another example of a low-interaction system is Honeyd (http://www.honeynet.org) by Niels Provos9. Honeydan interact with attackers and computer worms a little better than the previously mentioned solutions because it

an pretend to be many different systems. Honeyd can capture ARP (Address Resolution Protocol) requests10 hat 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 withoutny 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 interactmore extensively with the attacker system. Not only does Linux/Slapper fingerprint the target (as explained inChapter 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 calledesearch honeypots.

Another interesting solution is LaBrea, a so-called "sticky honeypot" developed by Tom Listonhttp://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 DigitalMillennium Copyright Act (DMCA); as a result, Tom Liston pulled its sources in 2003 (seewww.hackbusters.net).

Throughout this chapter, the worm captures will have many examples of ARP requests generated by computerworms 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 theylso 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)-mail is received on more than one or a very large number of decoy accounts. The system can collect the datarom the decoy accounts and use it directly to generate spam filter rules, effectively preventing classified spamrom 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 remoteystem 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. Asxplained 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 anunacceptable method for several obvious reasonsand 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 thathe 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 firewallogs and use NC (NetCat) to send a short attack ("cure") packet to each system suspected as a CodeRedttacker.

Note



Do not forget that all IP addresses must belong to you, and the permission should be given to you by thenetwork administrators. (Ideally, you are the administrator.)

The attack packet can contain exploit code similar to the one built into CodeRed, but a return address should beet 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

xample.

When the zero return address hits, it generates a page fault in the process address space of vulnerable MicrosoftIS, 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, theounterattack would not be so simple in the case of worms involving files or vulnerabilities that cannot bexploited more than once.

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

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

Also note that some network-level vulnerability assessment tools might have a side effect that can be used tolean up worm infections in a similar fashion to the previous examplebut such tools might have similarmplications. For example, a possible implication is data loss as a result of exploitation of a remote system (fornstance, 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. Thelerts are processed and correlated, and an appropriate warning is generated. Symantec generates alerts usinghe DeepSight early warning system. In DeepSight alerts, you also can see the correlation of a possible newttack with a set of known vulnerabilities that were previously logged into the BugTraq database, as well as the

ppropriate 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 beeneen on other systems. In many cases, you have a chance to respond to an attack before it reaches your

networkthus early warning systems do not directly protect your system. Instead, you supply data to suchystems 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 oneomputer to another. Detailed examination of such captures is useful in seeing how typical exploitation can be

xperienced on the wire when the network traffic is examined with a packet sniffer, such as tcpdump11. Alwaysuse such tools with the network administrator's permission because you might accidentally capture sensitivedata from the network.

4.8.1. Capturing the Blaster Worm

n the first example, shown in Figure 14.3, I browse a network capture of the W32/Blaster worm using

Ethereal12.

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


really like to use Ethereal, a popular sniffer and network traffic analyzer tool to browse network captures. Iuggest 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



ystem, which is already compromised by Blaster. The IP address 192.168.0.3 (also on a local test network) isurrently 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 on92.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 alreadyuns a command prompt on 4444/tcp. Notice that 192.168.0.3 runs the TFTP command and downloads from92.168.0.1, where the Blaster attacker system waits with a "TFTP server" thread of the worm to fulfill thisequest. 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 ownnetwork. In this example, the two machines reside on a test network used for natural infections. (Chapter 15 xplains more about natural infection strategies and analysis techniques and introduces a few more network aptures of worm attacks.)

Next, in frame 82 of Figure 14.3, you can see that the attacker system again communicates with its shell on thenewly 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 because92.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 fewpackets, which allows you to log attacker systems on your network quickly. Another possibility is simply toook 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 thevulnerability exploited by the worm.

4.8.2. Capturing the Linux/Slapper Worm

As Chapter 10 discusses in detail, the Slapper worm exploited an OpenSSL vulnerability on Apache Webervers 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 exploitsOpenSSL, so it is interesting to double-check whether or not the worm is encrypted on the wire. In some of thexisting computer security literature, the Slapper worm is already discussed as a worm that "cannot beffectively detected with NIDS because someone would need to compromise the security provided by SSL." As

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 bySlapper and attacks 206.129.254.254. Of course, all of this happens on our lab network, just like any otheraptures, 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. Whenhe worm exploits the target the first time, the target leaks valuable information, which is used in the second

xploit 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, thiswould be the case, and Ethereal would be right. However, the worm exploits the target before the encryption isstablished 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 encryptionstablished between the two systems.

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

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

lert tcp any any -> any 443 (msg:"Linux/Slapper Worm Propagation";

ontent:"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, whichhould not be the case. An SSL connection would always transmit cipher text in normal circumstances, and theilename 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 thisype of detection as a generic intrusion signature. Figure 14.5 shows a network capture of Linux/Slapper with aarge 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 genericallywithout dealing with the specifics of each individual attack.

n the real world, it is important to identify an attack more precisely. You really want to know whether theNIDS alert is related to a Slapper worm or is coming from an individual attacker. Therefore, modern NIDSystems include two-phase detection: One phase detects attacks generically and quickly, and a second detection,riggered by the first, further identifies the attack. Because NIDS engines are hard-pressed to work fastotherwise 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

uch attacks are ADM_Mutate, libSchellCode, S-poly, and JempiScodes13.

4.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 aMicrosoft LSASS vulnerability. In Figure 14.6, you can see the worm send its code from the alreadyompromised 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 sentlone and shows as Len=1 in frame 90 of Figure 14.6. In the lower pane of Ethereal, you can see an M characters 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

Len=1460 bytes is sent, typical on Ethernet networks.

ndeed, the worm sends itself byte by byte on the network, but without specifying an immediate sending, the IPtack 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 shortpacket boundaries.

Although Sasser does not attack NIDS directly, it demonstrates that worms can indeed split their exploit code tobyte-per-payload style of transfer if they specifically ask to do so. Not all NIDS have proper packet

eassembling abilities, as mentioned earlier. As a result, the IDS signature of the attack might not match becausehe 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 he worm could send its code with randomly split payload sizes, as shown in Figure 14.7B, challenging IDSmplementations that do not have traffic reassembling.

Both of these methods could work correctly. Depending on the packet reassembling and signature enginebilities of a NIDS, however, the signature of the worm might not be matched correctly. This examplellustrates 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.



4.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 donot really know how to use such tools to look for worm infections. As a result, they do not perform this kind of ogging 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 tcpdumpool, 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.

n the capture shown in Figure 14.8, you can see the Welchia worm ping the destination address 169.254.189.84

rom the 169.254.56.166 address. Before Welchia attempts to exploit a new target, it wants to get a positivenswer 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 fillerbyte to preinitialize the data structure for the ping request, instead of using zero bytes. This allows you to tracehe worm's ping request with a network-capturing sniffer tool, such as tcpdump or windump (which relies on

winpcap14).



f you want to track Welchia infections based on the special ping request data, use the following command15:

cpdump -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 echoequests, 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.

4.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 wormequires is to send a datagram to the actual port. Vulnerable installations of Microsoft SQL Server will execute

he 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 intoSlammer requires a special ID in front of the worm's code. This special byte, 0x04, would be normally followedby a short string, but there is no bound checking in the code, and the stack is overflowed when a large string iseceived. Notice the number of filler (0x01) bytes in the worm, which shift a return address value to the properpot.

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


will use this dump to demonstrate exploit detection using NIDS software. Normally, you could use a worm-pecific 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 Hybridignature, which pretty much follows the format of a Snort signature in this example:

lert udp any any -> any 1434 (msg:"W32/Slammer Worm Propagation";

ontent:"|68 2E 64 6C 6C 68 65 6C 33 32 68 6B 65 72 6E|";

ontent:"|04|"; offset:0; depth:1;)

We generate an alert whenever any traffic targets any IP address with a 1434/udp port. We alert with themessage "W32/Slammer Worm Propagation" whenever we find the h.dllhel32hkern string anywhere in thedatagram. 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 thexploit code, you could use the following signature to do so:

lert udp any any -> any 1434 (msg:"MS02-039 exploitation detected";

ontent:"|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-pecific 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 beunder attack since a 128-byte buffer is overflowed. There are two constant strings used by SQL Server to build

Registry key when the server receives this request (as discussed in Chapter 10), hence a dsize larger than 60will always result in an overflow conditionand at least a DoS attack.

Note

The 60 comes from 12840271=60 (size_of_buffer-string_size1-string_size2-terminating_zero= 60).

Of course, you could argue that such signatures are more prone to false positives, but you can also see that theyre 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 iswhy more specific IDS signatures always cause fewer false positives.

Such signatures, however, can be very helpful. Imagine if Slammer were polymorphic or even metamorphicnoctual 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 andepresent itself as a long-enough string. Thus the preceding generic IDS signature would also cover the

polymorphic version of the worm.

n fact, modern IDS detection languages support programmable signatures. For example, such signatures use ahistogram to check quickly whether there are any zero bytes in a range of the stream. Indeed, it would be bettero use such filters in the preceding signature to reduce false positives further. Slammer cannot use a zero bytenywhere in its body because the worm's body is processed as a "string." Similarly, any exploit code targetinghis 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 thexploit.

14.9. Conclusion

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

malicious programs.

References



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

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

. 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 , InsideNetwork Perimeter Security, New Riders, Indianapolis 2003, ISBN: 0-73571-232-8 (Paperback).

. 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-3-140733-3 (Paperback).

7. Thomas H. Ptacek and Timothy N. Newsham , "Insertion, Evasion, and Denial of Service: Eluding Network

ntrusion 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,"3th 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, RobLee, Costas Magkos, Patrick McCarty, Doin Mendel, Yannis Papapanos, Richard P. Salgado, Lance Spitznernd Jeff Jtutzman , "Know Your Enemy," The Honeynet Project, 2nd Edition, Addison-Wesley, Boston 2004,SBN: 0-321-16646-9 (Paperback).

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

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

2. "Ethereal: A Network Analyzer," http://ethereal.com/ .

3. Elias Levy , private communication, 2004.

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

5. Frederic Perriot , private communication, 2004.

chapter 14. network-level defense strategies

Documents