Combining Evasion Techniques to Avoid Network Intrusion

Combining Evasion Techniques to AvoidNetwork Intrusion Detection Systems

A. Samuel Gorton and Terrence G. Champion

Skaion Corporation, ? ??

51 Middlesex Street, Suite 114,North Chelmsford, Massachusetts, US 01863

email: [email protected], [email protected],WWW home page: http://www.skaion.com

Abstract. Three different Network Intrusion Detection System (NIDS)evasion techniques were combined into a three-dimensional testing space.These evasion techniques manipulated the TCP/IP protocol instead ofrelying on application-specific evasions. A modified version of theMendax program was used to send the ISAPI .printer attack in the clearto the target system. The evasion techniques used were segmentationof the attack into smaller packets, overlapping data in the packets, andthe presence of “presequence chaff”. Derived from Mendax, presequencechaff places garbage data in the first packet, with sequence numbers lessthan session start. The testing space was run against a sample NIDS atthree levels of sensitivity, showing regions where the combined evasiontechniques were not correctly detected.

Keywords: Intrusion Detection Sensors, Combining Evasion Techniques

1 Introduction

Many sites install an Intrusion Detection System (IDS) to monitor their hostsand networks for suspicious events. Many IDSs use a database of known eventsfor comparison, sending alerts when a match is detected. An attacker can evadean IDS in multiple ways, such as: using a previously unknown attack; concealingan attack in a hidden or encrypted channel; or exploiting features of the transportprotocol to confuse the monitoring system.

We began with a remotely-launched attack sent in the clear, and normallydetectable by the IDS. We used Transmission Control Protocol/Internet Protocol(TCP/IP) evasion techniques to obscure the actual attack. By combining threedifferent evasion techniques at a variety of different levels, we determined which(if any) of the permutations could be reliably used to bypass an example IDS.? This research was performed under Air Force Research Laboratory contract F30602-

99-D00-0001 Task 6. Opinions, interpretations, conclusions, and recommendationsare the authors’ and are not necessarily endorsed by the United States Air Force.

?? We thank Benjamin Gorton for creating the diagrams used in this paper.

2

Finally, we varied the configuration of the IDS in order to determine whetherincreasing the sensitivity of the detector - and thereby increasing the number offalse positives - improved detection of our attacks.

2 Background

Our research applies to IDSs with network-based input sources. A network-based IDS (NIDS) processes any clear-text traffic that crosses the monitorednetwork without degrading performance on the host computers; since a singleNIDS can monitor many hosts, less maintenance and monitoring effort isrequired. A network-based IDS cannot precisely know the target’s machine state;it must instead deduce the effects of traffic on the target system.

In contrast, a host-based IDS (HIDS) is installed on individual hosts, whichgrants knowledge of the target machine’s state and the ability to detect attacksfrom any point of entry. Network-based intrusion detection systems continueto be more prevalent and mature than their host-based counterparts, althoughpersonal “firewalls” such as ZoneAlarm on Windows computers have host-basedintrusion detection capability and are frequently in use.

Frequently, NIDS will only report whether a known attack was launched,without being able to determine whether the attack succeeded, or indeed whetherthe attack even applied to the target’s operating system.

A common frustration for NIDS operators is the high level of false positivestriggered on busy networks.[1] Sometimes the NIDS reports an attack that hasno applicability to the target, or that has simply failed, while other times, theNIDS confuses innocuous traffic with misuse.

Operators learn that they must tune their NIDS to reduce the number offalse positive alerts on their particular network. Sites vary NIDS sensitivity indifferent areas, reducing the sensitivity to decrease false positives.

3 Evading Network Intrusion Detection Systems

The “process model” [2] of Intrusion Detection Systems divides an IDS into threelayers: Information Source, Analysis, and Response. Diagram 3 illustrates ourexpanded, NIDS-specific, version of the process model as well as possible waysthe IDS can fail at each expanded layer.

A single failure at any layer will cause the NIDS to miss the attack. Whenthe state of the target machine is different from the deduced state, the IDS failsin the analysis layer. During our experiment, we attempted to find techniquesor combinations of techniques that will trigger a failure in the analysis layer.

The false positive problem creates an additional avenue for IDS evasion atthe alert layer. Even if the attack was not completely undetected, the IDS maybe tricked into reporting a less serious and accurate alert. This alert may fadeinto the background of false positives and be ignored by the human operator.

3

General IDSLayer

Response

Analysis

InformationSource

Signature-basedNetwork IDS

Layer

HumanResponse

Alert

Signatures

SignatureEngine

Protocol Analysis

NetworkSniffer

PossibleFailures

UnmonitoredSystem

IncompleteAlerts

Overly SpecificSignature

Case-SensitiveMatching

Out-of-OrderSegments Aren't

Reassembled

Packet DroppedUnder Load

Fig. 1. Expanded IDS Process Model and Example Failure Cases

3.1 Early NIDS Evasion Techniques

As NIDS began to be deployed the early and mid-1990s, evasion techniques wereoften discovered accidentally by their operators. The first techniques discoveredinvolved segmenting a signature into multiple packets, sometimes delaying thesecond part of the signature to trigger a NIDS time-out. Early NIDS evasiontechniques often assumed the use of a Unix command shell; as more attacks werediscovered that did not rely on interactive access, more emphasis was placed onprotocol-level evasion techniques.

Segmenting attacks is a simple mechanism for fooling a signature-basedNIDS; splitting the attack signature into multiple packets bypasses the simplestforms of string comparison. The CGI vulnerability scanner Whisker[3] includesseveral IDS evasion features, including segmenting the HTTP request into smallTCP packets and obscuring the request with alternate character encodings.

Time delay can be used in conjunction with segmentation to evade signaturedetection; a NIDS cannot remember every packet that has ever passed it, andcannot rely on every connection to terminate cleanly. Sending part of a signature,waiting until the NIDS times out, and then sending the rest of the attack canevade detection.

If the attacker utilizes a Unix command shell, the possibilities for evasion areendless. In 1997, Fred Cohen published a list of approximately fifty ways thatIntrusion Detection Systems could be evaded[4], often focusing on using Unix

4

command shell capabilities. These vulnerabilities highlighted the problems withthe then-current state of the art.

Chung et al[5] experimented with automatically changing a shell-basedexploit into a parallel attack. The different steps of the attack would be sentin different sessions from different hosts, fooling NIDS that tracked state insidea session or for a particular host.

During the 1998 DARPA IDS evaluation[1] some attacks successfully usedshell evasion techniques such as mimicking ROT-13 “encryption” using the trcommand. All traffic sent over the network were rotated thirteen ASCII charac-ters forward, and then rotated back thirteen characters on the target machine.The DARPA evaluation used other shell evasion techniques, including using shellvariables to store - and therefore mask - part of a signature. If the shell variable$FOO maps to the string “pass”, then the file /etc/password can be referred toas /etc/$FOOwd.

3.2 NIDS Evasion Toolkits

In 1999, Ptacek and Newsham[6] demonstrated that several commercial intrusiondetection systems had fundamental flaws at handling the IP and TCP protocolswhich allowed an attacker to trick them into incorrectly reconstructing sessionscontaining an attack. Ptacek and Newsham highlighted ways in which an IDScould be tricked into missing an attack that it possessed a signature for andwould normally detect.

The Fragrouter[7] - and later, Fragroute[8] - programs written by Dug Songimplement many of the techniques described in the Ptacek and Newshampaper. Release of these tools revealed widespread problems in commonlydeployed commercial and freely available NIDS.

When attacking a web server through HTTP, there are fewer possibilities forapplication evasion than in shell evasion. If the signature is flawed, an attackercan alter nonessential parts of the attack and avoid the signature. The core ofthe request cannot be altered, so evasion techniques must take advantage ofpre-existing but surprising web server features, or manipulate the underlyingprotocol layers.

Whisker[3], written by Rain Forest Puppy, was a proof of concept of HTTP-specific evasion techniques. Most of these techniques involved obfuscating theURL in question, since this was often the keystone of the NIDS signature.Whisker can also segment the attack request into multiple small packets in atechnique referred to as “Session Splicing”.

Min G. Kang’s NIDS evasion program Mendax[9] concentrates on TCP/IPprotocol evasion techniques instead of application evasion techniques. Mendaxtakes an arbitrary exploit from an input text file, performs a fixed set ofevasion techniques, and sends that restructured exploit to a target host overa raw TCP/IP connection.

5

4 Experimental Choice of Evasion Tool

To explore the effects of using multiple evasion techniques simultaneously weselected as our starting point the NIDS evasion program Mendax. TheMendax distribution did not document its techniques, although the source codewas publicly released with a license allowing modification and redistribution.

Attacker VictimNormal Three-way Handshake

SYN SEQ = 10,000

SYN + ACK ACK = 10,001

ACK SEQ = 10,001

PSH + ACK SEQ = 10,001

GET /bob.printer HTTP/1.1

Packet Legend:Flags Header

Data

Fig. 2. Normal HTTP Request

Normally, an entire HTTP request is sent in a single packet after sessionsetup, as shown in Figure 2. Our analysis of Mendax showed it was varying fromthat normal request by using a combination of four different TCP/IP evasiontechniques:

1. Segmentation of the attack into much smaller than normal data sections.These sections are guaranteed to split an attack signature into two or morepackets, which requires a NIDS to perform TCP stream reassembly in orderto detect the attack. Requiring reassembly through segmentation gives otherevasion mechanisms a chance to work.

2. Overlap data between packets by repeating the end of the last segment asthe beginning of the next. Since the data is correctly labeled this is perfectlylegal, although a NIDS may not correctly remove all duplicate data bytes.

3. Adding at least one byte of randomly generated Presequence Chaff. The chaffbytes are placed in the initial packet, prior to the data bytes, and labeledas occurring before the agreed-upon start of the connection. This chaff is

6

usually ignored by target systems, but may confuse a NIDS at the protocollayer or signature engine layers. We have not seen this technique used otherthan in Min G. Kang’s work; the “Presequence Chaff” term was coined bySkaion to describe his discovery.

4. Changing the Order that the packets are sent in from the simple increment-ing (first to last) order normally used. Mendax originally sent all segmentsin pseudo-random order, but the Skaion-modified version of Mendax canuse alternate orderings such as simple incrementing or decrementing order(last segment first, and so on). Sending the packets out of their natural ordercomplicates the reassembly work required, and increases the amount of statea NIDS must keep in order to correctly process the connection.

4.1 Segmentation

The fundamental evasion technique in this experiment was tosegment that request into small pieces. Figure 3 illustrates the beginning ofan attack that has segmented. Once the attack has been broken into segmentssmaller than the signature length, a NIDS must reassemble the stream in orderto detect the signature. Other evasion techniques can then be added to furtherobscure the signature.

Attacker Victim

PSH + ACK SEQ = 10,017HTTP/1.

Segment 3


Data

PSH + ACK SEQ = 10,001GET /bob

Segment 1

PSH + ACK SEQ = 10,009.printer

Segment 2

Normal Three-way Handshake

SYN SEQ = 10,000


ACK SEQ = 10,001

Fig. 3. Segmentation Evasion using eight-byte data segments

Similar results can be accomplished with IP fragmentation, but thepresence of fragmentation is simple for a NIDS to detect and is commonly

7

reported. Fragmentation can be determined by examining packet headers;detecting segmentation requires looking at the application-layer context of thetraffic.

4.2 Overlap

To complicate the reassembly process, the data segments can contain overlappingdata. Figure 4 shows a segmented attack with one byte of overlap; the last byteof each segment is also the first byte of the next segment. The sequence numbersare correctly labeled, so the target system will correctly reassemble the segmentsinto a functioning exploit.

Attacker Victim

PSH + ACK SEQ = 10,013nter HT

Segment 3


Data

PSH + ACK SEQ = 10,001GET /bo

Segment 1

PSH + ACK SEQ = 10,007ob.prin

Segment 2

Normal Three-way Handshake

SYN SEQ = 10,000


ACK SEQ = 10,001

Fig. 4. Overlap Evasion using seven-byte data segments with one byte of overlap

4.3 Presequence Chaff

The segment containing the first sequential bytes of data may include one ormore garbage bytes labeled as occurring before the agreed-upon start of theconnection. Figure 5 illustrates a sequentially ordered connection with four bytesof presequence chaff placed in the first packet. These presequence bytes willusually be silently discarded by the target system, but may confuse the NIDS.

8

Attacker VictimSYN SEQ = 10,000


DataPresequence Chaff


ACK SEQ = 10,001

PSH + ACK SEQ = 9997‡¥£¿ GET /bob.printer HTTP/1.1

GET /bob.printer HTTP/1.1‡¥£¿

Absolute Sequence Number

Relative Sequence Number

9997 10,000 10,026

-4 0 25

Fig. 5. Presequence Chaff Evasion using four bytes of chaff

4.4 Segment Order

We send all of our segments in “incrementing order”: packets in order from thefirst segment to the last segment. Using alternate orderings improves evasionagainst some NIDS; however, testing revealed that Snort [10], our experimentalchoice of NIDS, does not handle other packet ordering differently. Therefore, weonly use the most straightforward ordering to simplify the experiment.

5 Combining Evasion Techniques

Many evasion techniques can be combined; we have found that sometimes a singletechnique will consistently bypass a NIDS, but more commonly a combinationof factors is required to evade detection. In some cases, only a subset of possiblefactors evades detection; adding additional “stealth” measures to an evasiveattack may cause the NIDS to detect it.

Part of our modification of the original Mendax program freed it from beinghard-coded to a particular evasion pattern. We can arbitrarily vary any of theevasion factors and measure their effectiveness as we vary from a normal HTTPrequest.

The evasion techniques may lead to outright detection failure, or simplytrigger a less serious and more obscure alert. Because of the prevalence of falsepositives, the less serious alert may be missed or discounted by the system’soperators.

9

6 Experimental Choice of NIDS

To illustrate the applicability of evasion techniques, we selected the open sourceNIDS Snort[10]. We do not desire this experiment to reflect badly on Snort; inother testing, we have consistently found that some combination ofevasion factors will also bypass current commercial NIDS. We believe that Snort’spopularity and open source code makes it a useful demonstration tool. Theversion of Snort used in these tests is 2.0.0 beta (Build 51), downloaded fromthe CVS-CURRENT source tree on February 14, 2003.

Snort is a signature-based NIDS that also includes several heuristics todetect protocol anomalies. Most of these heuristics were added to detectspecific scanning or evasion techniques seen in the past - including Fragrouterand Fragroute. Snort has a documented flaw that only the first matching ruletriggers; if two rules apply, only the first rule triggers an alert. Unfortunately, itis not possible to define the order in which the rules are processed - and thereforeless serious alerts may obscure more serious alerts.

Snort uses preprocessors outside the normal rule system to perform anyrequired traffic normalization, or to handle various special detection cases suchas port-scanning. These preprocessors enable Snort to perform more flexibledetection than the signature rules alone, and the preprocessors are individuallyconfigurable. Preprocessor alerts are separate from the main signature rule-setalerts; multiple preprocessor alerts can be triggered without interfering with eachother or the signature rules.

In its default configuration, Snort includes a large number of rules, manyof which may trigger false positive alerts. In some cases, the rules are writtenimprecisely; in other cases, innocuous traffic may have legitimately taken onthese aspects of malicious traffic.

By default, the Snort preprocessors are tuned to a very low level of evasionsensitivity. In order to vary preprocessor sensitivity in later test cases, we neededto enable new detection features.

7 Experimental Exploit

For our experiment, we will use a attack that is ordinarily detectable by Snort.The exploit used in our experiment is the ISAPI .printer attack[11–13]. Theexploit code itself is a text file fed into Mendax; the Windows shell code for theexploit is taken from eEye proof of concept code[14]. The eEye exploit writes afile named www.eEye.com to the root directory of the target system; presence ofthe file confirms that the attack was correctly interpreted by the target system,an unpatched Windows 2000 Server running IIS 5.0.

Snort has a signature for this attack in its web-iis.rules file that triggers a“WEB-IIS ISAPI .printer access” alert. This signature will flag anyestablished stream destined for an HTTP port containing the case-insensitivestring “.printer” in the request.

When we ran our tests, we specified the source port for each attack. Thesource port uniquely specifies each condition, removing the possibility of

10

accidentally confusing the results of two conditions. Using a source port thatis unique within a test suite and consistent between test suites greatly simplifiesscripted verification and interpretation of attack results.

In addition, we programatically modified the input file containing theISAPI .printer buffer overflow in order to write the source port as part of theexploit-created filename. For a source port of 33100, the target file is namedwww.eEye.co33100. Because we did not duplicate source ports in a test suite,review of the files created on the target machine verified that all attackscompleted successfully.

8 Block Testing Space

Chaff (0 - 8)

Overlap (0

- 7)

Se

gment Length (1 - 8)

Segment Length = 3Overlap = 2

Presequence Chaff = 0





Fig. 6. Block Testing Space

Our test space (Figure 8) is three-dimensional; our primary dimension islength, which we will vary from one to eight bytes. The rear left ’spine’ of the

11

block testing pyramid represents our attacks that were only segmented, withzero bytes of overlap or presequence chaff. The rear and left edges of the pyramidrepresent tests using segmentation and only one additional evasion method. Theother blocks represent tests that simultaneously used all three evasion methods.

For each segment length, we test all legal overlap values. Overlap is limitedby the segment length; an equal value will never send any new data, and bydefinition we cannot have more overlapping bytes than the total segment length.Therefore, for each segment length we varied overlap, starting at zero bytes, andending at one byte less than that segment length.

The presequence chaff bytes are not limited by the segment length. Thesebytes are added to the initial packet in addition to its normal data segment.In theory, we can add as much presequence chaff as we want, only limited bythe largest unfragmented packet size we can send. For our experiment we variedpresequence chaff; starting from zero bytes, and ending at one byte greater thanthe associated segment length - except for tests with nine chaff bytes.

When our test was run with eight-byte segments and nine bytes ofpresequence chaff, our test exploit frequently failed, regardless of overlapvalues. In some cases, the connection completed correctly, the IIS log filesindicate that the HTTP “.printer” request was not garbled, but the exploitstill fails with result code 501. In other cases, the Mendax attack failed and thetarget system only acknowledges receipt of some of the attack packets. To avoidthese problems, we excluded those seven cases from our test space.

As mentioned earlier, we send all segments in incrementing order - segmentssent in order from first to last. If we wanted, we could repeat our block testingspace with alternate segment orderings (creating a four-dimensional test space),but Snort’s detection is not affected by alternate orderings.

9 Block Testing Case One: Default Configuration

Our test of Snort reveals that the detection results are not consistent. We havetherefore created two block pyramid result pyramids for each test case, as wellas illustrating the frequency of each alert in the table 1.

The first pyramid (Figure 7) illustrates all cases in which at least one alert wasseen. If no alerts were triggered in at least one case, the UNDETECTED “alert”is assigned to the case. The second pyramid (Figure 8) shows how frequently theattack was correctly detected, ignoring minimally accurate detections.

This case clearly indicates Snort’s rule overlap flaw; rules to detect Whisker’sevasion attempts prevent Snort from correctly detecting the ISAPI .printerattack. The following section (Rule Overlap Analysis) discusses why theseoverlapping rules are triggering on our attack.

More seriously, Snort failed to detect many of our attacks. Except for ruleoverlap cases, Snort always correctly detected attacks with only segmentation;no chaff and no overlap. When additional evasion factors were applied (again,and rule overlap did not apply) Snort failed to detect several of the attacks.

12

Chaff (0 - 8)

Overlap (0

- 7)

Se


WEB-IIS ISAPI .printer

UNDETECTED

WEB-MISC whisker tab splice

WEB-IIS ISAPI .printerUNDETECTED

DOS cisco attemptWEB-MISC whisker tab splice

WEB-MISC whisker space splice

Fig. 7. Alerts Detected: Default Configuration

Although Snort missed approximately one hundred attacks per suite, not allfailures were consistent. Sixty tests were never detected by the defaultconfiguration. Because of the inconsistent nature of the detection, at least someof these attacks may be detected by this Snort version at a different place ortime. However, we randomly chose some of these test cases and repeated thosetests one hundred times with the default configuration. Snort never detected oursample “undetected” tests.

9.1 Rule Overlap Analysis

Three different rules are overlapping with our ISAPI .printer rule: two Whiskerrules and one DOS Cisco rule. Snort rules each have a Snort identifier (SID) thatserves to uniquely identify each rule.

The two Whisker rules that are overlapping with our test are the WhiskerSpace Splice (SID 1104) and Whisker Tab Splice (SID 1087). These rules aredefined in the web-misc.rules file, and are intended to catch evasion techniquesused by the Whisker CGI probe tool. The DOS Cisco (SID 1545) rule is defined in

13

Chaff (0 - 8)

Overlap (0

- 7)

Se


4 x WEB-IIS ISAPI .printer





Fig. 8. Correct Detections: Default Configuration

Snort’s experimental.rules file, which is clearly labeled as a source for “bleedingedge” rules. The experimental.rules file is included by default.

The Whisker Space Splice rule triggers on any packet in an establishedconnection to the HTTP port (80) that has exactly one data byte long if thatbyte is a space character (hex x20). Our buffer overflow in the “Host:” fieldcontains 0x20 characters, so Snort reports multiple Whisker Space Spliceattacks if the data segment length is exactly one byte long.

The Whisker Tab Splice rule triggers on any packet in an establishedconnection to the HTTP port (80) that has fewer than five data bytes andthat data contains a tab character (hex x09). Our buffer overflow also contains ax09 character, so whenever the data segment length is less than five bytes long,Snort reports a Whisker Tab Splice alert.

The experimental DOS Cisco rule triggers on any packet in an establishedconnection to an HTTP port (80) that has exactly one data byte if that byte isthe hex value x13, which is not a printable ASCII character. Again, the exploitcharacters in the buffer overflow include a hex x13 character. Consequently, when

14

Table 1. Test Results Case One: Default Configuration

Alert Detection Proportion Cases (out of 268)

Experimental DOS Cisco attack Total 34/4 3

Whisker Space Splice attack Total 44/4 4

Whisker Tab Splice attack Total 504/4 50

ISAPI .printer attack Total 1581/4 282/4 203/4 294/4 81

Undetected Attacks Total 1371/4 292/4 203/4 284/4 60

our data segment length is exactly one byte long, Snort reports the experimental(and, in this case, unhelpful) DOS Cisco alert.

When the data segment length is one byte, Snort reports all three overlappingrules. The three characters that trigger these individual alerts do not occurin the same packet, and so we believe the rules do not obscure each other.However, whenever at least one of these three alerts is reported, Snort missesthe underlying ISAPI .printer attack. Strangely, it does this even though the“.printer” characters are always sent earlier than the buffer overflow and its tab,space, and hex x13 characters.

Because of the rule overlapping problem, adding new rules to Snort maydecrease its effectiveness. It is important for the distributed rules and user-addedrules to be as precise as possible to avoid both false positives and minimallyaccurate “detections”.

10 Block Testing Case Two: Disabled Whisker Rules,Enabled Evasion Alerts

For this test case, we disabled the Whisker Tab Splice and Whisker Space Splicerules in the web-misc.rules file. The “EXPERIMENTAL DOS Cisco” rule isdefined in the experimental.rules file, and was left enabled for continued ruleoverlap analysis. We removed the disable evasion alert option from the stream4preprocessor. In other words, we enabled “evasion alerts” in the preprocessorthat reassembles TCP streams for Snort.

Snort’s evasion alerts are documented (by the Snort developers) to increasethe false positive rate, so our increase in sensitivity comes at the cost of increased

15

Chaff (0 - 8)

Overlap (0

- 7)

Se


WEB-IIS ISAPI .printer

spp_stream4

spp_stream4UNDETECTED

WEB-IIS ISAPI .printerspp_stream4

DOS cisco attempt


UNDETECTED

DOS cisco attemptspp_stream4

WEB-IIS ISAPI .printerUNDETECTED

Fig. 9. Alerts Detected: Whisker Rules Disabled, Evasion Alerts Enabled

false positives. Attacks that are only minimally reported as possible evasion alertsmay be lost in those false positives.

We noticed a remarkable improvement in the number of cases correctlydetected, as shown in Figure 9. This improvement is mostly derived fromdisabling the Whisker rules and preventing rule overlap.

Some of the attacks that were detected as Whisker attacks are nowcompletely undetected or are minimally detected as spp stream4 alerts. Theoverall reliability of correct detection as an ISAPI .printer attack is very poor,as shown in Figure 10. The improvement from disabling the Whisker rulesillustrates that for a first-match system like Snort, having too many rules candegrade performance.

The spp stream4 preprocessor alerts greatly reduce the number of completelyundetected attacks; however, detecting an evasion method is not the same asdetecting the underlying attack. Given the cryptic nature of the spp stream4alerts, as broken out and displayed in Table 2, those alerts are only minimallyuseful to an operator in determining the nature of the attack.

16

Chaff (0 - 8)

Overlap (0

- 7)

Se







Fig. 10. Correct Detections: Whisker Rules Disabled, Evasion Alerts Enabled

As with the first testing case, detecting the evasion techniques independentlydoes not mean that they were still detected in combination. There are regions inthe block testing pyramids where the attack was not correctly detected because ofthe combination of three evasion factors. These attacks may have been detectedat the left and rear margins of the pyramid, where only two evasion techniqueswere combined.

Note also that in some cases, the evasion techniques are missed on the mar-gins but detected at some point inside the pyramid. Increasing overlap betweensegments appears to improve Snort’s detection capability - too much of an eva-sion technique can destroy its effectiveness.

In our research, these evasive regions vary based on the particular NIDS, andsometimes also on the configuration. Frequently, the regions of failed detectionare more consistent than in Snort’s case, making it easier for an attacker to picka reliable evasion combination.

17

Table 2. Test Results Case Two: Disabled Whisker Rules, Enabled Evasion Alerts


Experimental DOS Cisco Attack Total 34/4 3

Multiple Acked Packets (possible fragroute) Total 217(spp stream4 preprocessor) 4/4 217

possible EVASIVE RST detection Total 235(spp stream4 preprocessor) 1/4 42

2/4 433/4 644/4 86


Undetected Attacks Total 211/4 172/4 33/4 14/4 0

11 Block Testing Case Three: Detect State ProblemsEnabled

After the release of Fragroute[8], the detect state problems feature of the stream4preprocessor was added. Enabling this option activates several checks which areintended to detect fragroute-style evasion, at the documented cost of increasingthe false positive rate. While keeping the Whisker rules disabled and evasionalerts enabled, we have enabled the detect state problems option and repeatedour block testing suite.

Figure 11 shows that at this level of sensitivity, no attack is ever completelyundetected. Unfortunately, a large number of the alerts are only minimally ac-curate. All of the spp stream4 alerts, and in particular state problems, can begenerated by normal traffic. On a busy network, these alerts can be very fre-quent, and there is not much to distinguish false positives from the alerts thataccompany an actual attack.

Figure 11 shows that even at this very high level of sensitivity, Snort cannotalways detect the ISAPI .printer attack. Table 3 shows that roughly the samenumber of test cases were correctly detected as in the previous test.

Analysis of the Snort code indicates that the flaw seems to be in the spp stream4preprocessor. The preprocessor must call the FlushStream() method to triggerthe ISAPI .printer alert on the stream. In our analysis of detection failures,the “flush point” was not reached or the pointer to data was zero, and theFlushStream() method was not called.

18

Chaff (0 - 8)

Overlap (0

- 7)

Se



spp_stream4

DOS Cisco attempt

Fig. 11. Alerts Detected: Detect State Problems Enabled

12 Conclusions

When evasion techniques are combined at different levels, regions of detectionfailure appear. When individual techniques are combined, systems that detecteach separate component often fail at detecting some permutations.

It is important to realize that detecting an evasion technique is not the sameas countering the technique. In order to counter an attack, the IDS needs to beable to report the true attack concealed by the evasion. Detecting an evasiontechnique but missing the underlying attack is a poor trade-off.

Detecting evasion techniques by themselves can be a useful warning that anevent is in progress, but doesn’t help an operator to discover what attack waslaunched, whether it was successful, and what (if any) cleanup and recoverysteps need to be taken.

For a NIDS to be maximally effective, defenses against evasion must be en-abled by default and not overwhelm the operator with false alarms. Given thecontrol that the attacker has over client-side traffic, a NIDS that relies on client-side data for the signature must be prepared to handle multiple evasion tactics,singly or in combination.

19

Chaff (0 - 8)

Overlap (0

- 7)

Se







Fig. 12. Correct Detections: Detect State Problems Enabled

References

1. R. P. Lippmann, R. K. Cunningham, D. J. Fried, S. L. Garfinkel, A. S. Gorton,I. Graf, K. R. Kendall, D. J. McClung, D. J. Weber, S. E. Webster, D. Wyschogrod,M. A. Zissman: “The 1998 DARPA/AFRL Off-Line Intrusion Detection Evaluation”,First International Workshop on Recent Advances in Intrusion Detection, Louvain-la-Neuve, Belgium, 1998.

2. Becky Bace and Peter Mell: “NIST Special Publication on Intrusion Detection Sys-tems.” 2001. http://csrc.nist.gov/publications/nistpubs/800-31/sp800-31.pdf

3. Rain Forest Puppy: “A look at whisker’s anti-IDS tactics”. December 1999.http://www.wiretrip.net/rfp/pages/whitepapers/whiskerids.html

4. Fred Cohen: “50 Ways to Defeat Your Intrusion Detection System”. 1998.http://www.all.net/journal/netsec/1997-12.html

5. Mandy Chung, Nicholas Puketza, Ronald A. Olsson, Biswanath Mukherjee: “Sim-ulating Concurring Intrusions for Testing Intrusion Detection Systems: ParallelizingIntrusions”. Proceedings of the 1995 National Information Systems Security Confer-ence. Baltimore, Maryland, October 10-13, 1995, pp. 173-183.

6. Ptacek and Newsham: “Insertion, Evasion, and Denial of Service: Eluding Net-work Intrusion Detection”. Technical Report, Secure Networks, Inc., January 1998.http://citeseer.nj.nec.com/ptacek98insertion.html

20

Table 3. Test Results Case Three: Detect State Problems Enabled


Experimental DOS Cisco Attack Total 34/4 3

Possible RETRANSMISSION detection Total 260(spp stream4 preprocessor) 1/4 0

2/4 03/4 14/4 259

Multiple Acked Packets (possible fragroute) Total 217(spp stream4 preprocessor) 1/4 0

2/4 03/4 04/4 217

possible EVASIVE RST detection Total 246(spp stream4 preprocessor) 1/4 39

2/4 543/4 814/4 72


Undetected Attacks Total 04/4 0

7. Dug Song, Anzen Computing: Fragrouter NIDS evasion toolkit.http://www.securityfocus.com/tools/176

8. Dug Song: Fragroute toolkit version 1.2. April 16, 2004.http://monkey.org/d̃ugsong/fragroute/

9. Min G. Kang: Mendax IDS evasion program 0.7.1. June 28, 2001.http://adam.kaist.ac.kr/b̃ugsy/

10. Marty Roesch et al: “SNORT, A lightweight intrusion detection system project.”http://www.snort.org/

11. Common Vulnerability and Exposures list: CVE candidate CVE-2001-0241,“Buffer overflow in Internet Printing ISAPI extension in Windows 2000”, September18, 2001. http://www.cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2001-0241

12. eEye Digital Security: Advisory AD20010618 “All versions of Microsoft InternetInformation Services Remote buffer overflow (SYSTEM Level Access). June 18, 2001.http://www.eeye.com/html/Research/Advisories/AD20010618.html

13. Microsoft Security Bulletin MS01-023: “Unchecked Buffer in ISAPI Ex-tension Could Enable Compromise of IIS 5.0 Server”. May 1, 2001.http://www.microsoft.com/technet/security/bulletin/MS01-033.asp

14. eEye Digital Security: eEye proof of concept ISAPI .printer exploit. June 18, 2001.http://www.eeye.com/html/research/Advisories/iishack2000.c

Documents

Combining Evasion Techniques to Avoid Network Intrusion