hack proofing your network second edition phần 10 pot

IDS Evasion • Chapter 16 705 Using Application Protocol Level Evasion IDS sensors have the ability to inspect the protocol internals of a communica- tions stream to aid in the detection process.There are two basic strategies vendors employ: application protocol decoding, where the IDS will attempt to parse the network input to determine the legitimacy of the service request, and simple signature matching. Both of these approaches have their own unique challenges and benefits; we will see that most IDSs probably implement a hybrid of these solutions. Opportunities to evade detection are available at every layer of the protocol stack. Security as an Afterthought Application developers are typically motivated by features and dollars.We all know that the end user is the ultimate decision maker on the success or failure of software. In an effort to please end users, provide maximum compatibility, and eliminate erroneous conditions, developers omit strict compliance of protocol specifications in favor of error correction. It is uncommon for an application to immediately terminate requests upon the first deviation from specified proto- cols—quite to the contrary, every effort is made to recover from any error in an attempt to service each possible request (thereby maximizing compatibility and www.syngress.com in any fashion. Most systems are quite simply bait, meaning they are designed to be the most attractive target on a network segment. It is the hope of the defender that all attackers would see this easy point of pres- ence and target their attacks in that direction. Although it has been seen that there is cause to have bait systems configured identically to other production systems on the target network (hopefully hardened), so that if an attacker’s presence is detected on the honeynet (nobody can transmit any data to this system without detection), the defender can be sure vulnerabilities exist in their production configuration. And with the added benefit of detailed logging, some low-level forensics will typically reveal the vulnerability information along with any backdoors the intruder used to maintain their foothold. Keep in mind, no system is foolproof. Attackers should be able to discern that they are behind a bridge by the lack of Layer 2 traffic and the discrepancy in Media Access Control (MAC) addresses in the bait system’s ARP cache. See http://project.honeynet.org for more details. 194_HPYN2e_16.qxd 2/15/02 12:07 PM Page 705 706 Chapter 16 • IDS Evasion possibly increasing interoperability).As security researcher Rain Forest Puppy (known as RFP) stated at the CanSecWest Security Conference 2001,“You would be surprised with what passes for legitimate HTTP traffic…”These prac- tices are the downfall of application security since they only serve to aid an attacker in allowing additional latitude in which to operate. Evading a Match Upgrades, patches, and variation of implementation may change the appearance (on the wire) of an application. Signatures—too specific, too general and just plain too stale—are a basic issue that continues to thwart IDS attack identifica- tion efforts. If we look back towards our snort signatures, we can see quite clearly that one of them specifies the complete path name for the chgrp command.This sig- nature is supposed to alert to the execution of some command through a Web server.Any attacker who is aware of the semantics for these rules could easily modify their attack to play any number of tricks in hopes of evading this match. This rule itself is quite specific about the path and name for the chgrp com- mand.We can plainly see that if the command resided in a different directory than /usr/bin, this signature would fail.Also, if the attacker were to simply ensure that their path environment variable were correctly set, they may just issue chgrp, without the complete path to evade a signature match. Should the IDS be configured to alert when any of these variations are present? How many sig- natures would our IDS have if we were to account for these many variations? Alternate Data Encodings Largely implemented to support multiple languages, the standard text sent between a Web client and server may be encoded so that it’s interpreted as Unicode, which can represent any known symbol (the Unicode value for Yung is U+6C38). It also presents all new challenges to IDS vendors, as these values must be inspected and converted into ASCII for standard processing.This challenge is not that difficult to overcome; most systems implement a practice known as pro- tocol normalization. Protocol normalization will take an input string and digest all known encodings, white space, and any protocol-specific delimiters in an attempt to produce the most basic form of the input. Unfortunately, all the normalizations imaginable cannot overcome the chal- lenge of monitoring closed source software packages.Without detailed informa- tion of the inner workings of a system, there can be no accounting for www.syngress.com 194_HPYN2e_16.qxd 2/15/02 12:07 PM Page 706 IDS Evasion • Chapter 16 707 undocumented nonstandard features. Microsoft’s Internet Information Server (IIS) had one such special feature: %u#### encoding was allowed as an alternate to the normal Unicode encodings (%####).The famed Code Red worm had used this previously unknown technique to bypass many IDS signatures tuned to match for the specific .ida buffer overflow vulnerability. Lack of information is the worst enemy of a network defender. Consider the following imaginary attack: Attack String: GET /vulnerable.cgi?ATTACK=exploit-code Signature: alert tcp $EXTERNAL_NET any -> $HTTP_SERVERS 80 (msg:"WEB-ATTACKS vulnerable.cgi attempt"; flags:A+; content:"get /vulnerable.cgi? ATTACK=exploit-code";nocase; sid:1337; rev:1; classtype: web-application-attack;) Modified Attack String: GET /vulnerable.cgi?ATTACK=<SPACE>exploit-code The attack here seems to exploit some Common Gateway Interface (CGI) application, and a simple signature is developed to alert to the known vulnera- bility.This signature would provide a very high-level assurance that there would be relatively few false positives, as the exploit-code is embedded right into the signature. However, we can see that if the attacker were able to send a modified attack string, through the use of some additional white space, they should be able to bypass a signature match.This exercise again illustrates the difficulty of signa- ture development. If the signature left out a portion of the exploit code, there may be a great number of false positives, whereas if they embed some of the exploit code, the chance for evasion is greatly increased. This is an incredibly simplistic example and is not that difficult to overcome. Adequate normalizations should be able to eliminate whitespace and allow for a signature match. Web Attack Techniques Several Web attack issues have been analyzed by Rain Forest Puppuy; see, for instance,“A look at whisker’s Anti-IDS Tactics,” from December, 1999 (www.wiretrip.net/rfp/pages/whitepapers/whiskerids.html). He has implemented a number of them into his whisker vulnerability scanner.We’ll take a look at some of them in the following sections. www.syngress.com 194_HPYN2e_16.qxd 2/15/02 12:07 PM Page 707 708 Chapter 16 • IDS Evasion Method Matching The method of a HTTP request informs the server what type of connection to anticipate (GET, HEAD, POST, and so on). RFP found that many IDS signatures had completely failed to recognize any other methods.This is a somewhat depressing fact as many IDS vendors claim not to be totally dependent on signa- ture matching to generate an alert. Directory and File Referencing A slash, the character that specifies a separation between directory and file names (/), can be represented in a couple of different ways.The simplest form is double or multiple slashes (/some//file.html = /some////file.html).These tricks will fool the simplest signature matches, providing there are no normalizations to counteract. Another form of the same trick (this works only on IIS Web servers), is to use the DOS slash character (\). If an IDS were not aware of this convention, it would not be able to generate a match. These tricks work because they can reference a file by a different pathname. Amazingly enough, resolving a pathname is substantially harder then you would think (this is what has lead to a number of remote compromises in IIS, remember Unicode). Dot, the path to the current directory, and double dot, the path to the previous directory, can be used to obfuscate a file reference.An attacker may only need to use his or her imagination in constructing unique paths; all of these are equivalent requests: GET /some/file.cgi HTTP/1.0 GET / /./some////file.cgi HTTP/1.0 GET /./some// \ ///some/./file.cgi HTTP/1.0 A form of the aforementioned evasions is what RFP calls parameter hiding. This evasion is based on the assumption that some IDSs may only evaluate a request until it encounters a question mark (?), a hex-encoded value of %3f.This character is typically what will denote that any further parameters are arguments to a Web application. If the IDS simply wanted to alert to the request of a file, it may not fully evaluate the expression.The following two requests are equivalent: GET /real.file HTTP/1.0 GET /%3f/file/does/not/exist/ / / / / /real.file HTTP/1.0 www.syngress.com 194_HPYN2e_16.qxd 2/15/02 12:07 PM Page 708 IDS Evasion • Chapter 16 709 Countermeasures As discussed previously, a signature-based IDS may be able to normalize the com- munications stream.That is, as it inputs data destined for a HTTP server, it should apply some logic to reduce the input into its lowest common denominator (a single /, or resolving directory references). Partial signature matches may also help. If a sensor does not enforce a strong 100 percent match, they should be able to account for some variation of many exploit types. Using Code Morphing Evasion Polymorphism is the ability to exist in multiple forms, and morphing is the process used to achieve polymorphism.The objective of polymorphic code is to retain the same functional properties while existing in a structurally unique form.A NIDS has only the opportunity to inspect information as it exists on the wire; this would then only allow the structure of the exploit to be inspected.This fea- ture had allowed viruses to remain undetected for quite some time.The only dif- ference is that a virus scanner has the opportunity to inspect disk files instead of network data.The way that most virus scanning engines have tackled this problem is through the use of heuristic scanning techniques; this is similar to what a host-based IDS would do (identifying suspicious events, inappropriate file access, and so on). Polymorphism is achieved through taking the original attack payload and encoding it with some form of a reversible algorithm.All of the NOP-sled instructions are substituted with suitable replacements.This encoded payload is then sent over the network with a small decoding function prefixed (this decoder is also dynamically generated to avoid a signature match).When the exploit runs on the target, the decoder will unwrap the original payload and execute it.This way, the original functionality is maintained. Polymorphic shellcode is discussed thoroughly in this author’s paper that was released in early 2001 (www.ktwo.ca/c/ADMmutate-README).An engine is included for use in any current or future vulnerabilities.The basis for polymor- phic code generation is that there is always more then one way to calculate a value. If, to exploit a vulnerability, we had to calculate the value of 4, we could do any of 2+2, 3+1, 6-2, and so on.There are literally endless methods to calcu- late a given value—this is the job of an exploit, the possessing of some machine instructions.To a NIDS examining network traffic, there is no way to identify 2+2 as being equivalent to 3+1.The NIDS is only given the low-level machine www.syngress.com 194_HPYN2e_16.qxd 2/15/02 12:07 PM Page 709 710 Chapter 16 • IDS Evasion instructions to evaluate against a known pattern; it does not interpret the instruc- tions as the target host will. This technique has the ability to mask any exploit from detection, from any specific rule to the general.The only opportunity for a signature-based NIDS to formulate a match is if a signature for the small decoder is able to be determined. To date, I have not seen any signatures or techniques developed for this class of polymorphic shellcode.Table 16.1 shows a side-by-side view of two executions of a polymorphic shellcode engine. Table 16.1 Shellcode Variations Possible Possible Normal Polymorphic Polymorphic Addresses Shellcode Shellcode #1 Shellcode #2 0x8049b00 nop push %ebx das 0x8049b01 nop cmc pushf 0x8049b02 nop pop %edx inc %ecx 0x8049b03 nop xchg %eax,%edx xchg %eax,%ebp 0x8049b04 nop lahf pop %edi 0x8049b05 nop aas push %edi 0x8049b06 nop push %esi dec %ebp 0x8049b07 nop push %esp dec %ebx 0x8049b08 nop clc lahf 0x8049b09 nop push %edx xchg %eax,%edx 0x8049b0a nop push %esi push %ebx 0x8049b0b nop xchg %eax,%ebx pushf 0x8049b0c nop dec %ebp inc %esp 0x8049b0d nop pop %ecx fwait 0x8049b0e nop inc %edi lahf 0x8049b0f nop dec %edi pop %edi 0x8049b10 nop inc %ecx dec %ecx 0x8049b11 nop sahf dec %eax 0x8049b12 nop pop %edi cwtl 0x8049b13 nop sti dec %esp 0x8049b14 jmp 0x8049b38 push %esp xchg %eax,%ebx 0x8049b16 pop %esi repz dec %eax sarb $0x45,(%ecx) www.syngress.com Continued 194_HPYN2e_16.qxd 2/15/02 12:07 PM Page 710 IDS Evasion • Chapter 16 711 0x8049b17 mov %esi,%ebx push %ebp mov 0xffffff90(%ebx),%ebp 0x8049b19 mov %esi,%edi dec %esp dec %edi 0x8049b1b add $0x7,%edi pop %eax mov $0xd20c56e5,%edi 0x8049b1e xor %eax,%eax loope 0x804da1b imul $0x36,0xee498845 (%esi),%ebx 0x8049b20 stos js 0x804d994 dec %ecx %al,%es:(%edi) 0x8049b21 mov %edi,%ecx daa and %ah,%cl 0x8049b23 mov %esi,%eax sbb $0x15,%al jl 0x804da3d 0x8049b25 stos pop %eax out %al,$0x64 %eax,%es:(%edi) 0x8049b26 mov %edi,%edx out %eax,(%dx) add %edi,%eax 0x8049b28 xor %eax,%eax push %ebp sarl %cl,0x4caaa2a0 (%ebp,%eax,2) 0x8049b2a stos dec %edi nop %eax,%es:(%edi) 0x8049b2b mov $0x8,%al jp 0x804d966 cmp 0x5cd8733(%eax),%ebx 0x8049b2d add $0x3,%al movl movsl %es:(%ecx),%ss %ds:(%esi),%es:(%edi) 0x8049b2f int $0x80 mov push %ss $0x15d5b76c,%ebp 0x8049b31 xor %ebx,%ebx adc %edi,(%edi) int $0x14 0x8049b33 mov %ebx,%eax loopne 0x804d9a0 push $0xbffff586 0x8049b35 inc %eax push %ebp xchg %dh,%ch 0x8049b36 int $0x80 xchg %eax,%ecx As you can plainly see, there is very little correlation between the three exe- cutions.There are a huge number of permutations that can be used. It is apparent that most IDSs are not always quite ready to run out of the box.They require frequent updating and maintenance to yield long-term success. The IDSs that do have hope of detecting unknown forms of attack are anomaly www.syngress.com Table 16.1 Continued Possible Possible Normal Polymorphic Polymorphic Addresses Shellcode Shellcode #1 Shellcode #2 194_HPYN2e_16.qxd 2/15/02 12:07 PM Page 711 712 Chapter 16 • IDS Evasion detection-based.These systems do not use signatures at all.They instead monitor all network communications as they occur and attempt to build a high-level image of typical traffic. A statistical anomaly would then trigger an alert.As the system matures and gains more entropy into its database, it would then theoreti- cally become more accurate.There is some question whether or not a purely anomaly-based detection engine would be very effective, as exploit attempts seem to be quite normal in day-to-day network operation and may fall into the base- line of these systems.As in all things, a little of each is not a bad idea.A strong signature-based system supplemented by an anomaly-based detection engine should yield a high level of assurance that most intrusion events are monitored. In the endless security game of cat and mouse, one can forecast the genera- tion of polymorphic statistically normalized attack engines that should provide one more hurdle for NIDS developers to overcome. www.syngress.com 194_HPYN2e_16.qxd 2/15/02 12:07 PM Page 712 IDS Evasion • Chapter 16 713 Summary Signature-based IDS sensors have many variables to account for when attempting to analyze and interpret network data. Many challenges continue to elude these systems.The lack of information that is available for inspection is difficult to overcome. However, the rate at which many IDS sensors have been maturing is quite promising; Gigabit speeds and flexible architectures supported by an ever- growing security community push forward to configure systems that are capable of detecting all but the most obtuse and infrequent attack scenarios. At every layer of the network stack there are difficulties with maintaining a consistent view of network traffic, as well as the effect of every packet being trans- mitted. It is quite clear that an attacker has certain advantages, being able to hide in a sea of information while being the only one aware of their true intension. Packet layer evasions have been well documented throughout the past several years. IDS vendors are quite aware of the many issues surrounding packet acquisi- tion and analysis. Most networks are beginning to filter “suspicious” packets in any case—that is, any types with options and excessive fragmentations. Perhaps in the coming years, network layer normalizations will become commonplace and many of these evasion possibilities will evaporate. The difficulty with analyzing the application layer protocols continues to cause ongoing headaches. Some proxy solutions have begun to take hold, but the bottleneck that these systems cause is often too great.They also suffer from sim- ilar issues as IDSs, unable to identify classes of attacks that they were not origi- nally intended for. It is quite acceptable to quash malformed TCP/IP packets in the case of an error; a legitimate end system would eventually retransmit.The same is not true for higher layers; a NIDS may have an extremely limited understanding of appli- cation protocols and the information they transmit. Polymorphic attacks present a significant challenge that cannot be easily solved with a purely signature-based system.These attacks may exist in virtually limitless combinations. IDS evasion will continue to be a way of life on the Internet.There is an ever-renewing tide of tools and techniques that are developed and refined (even- tually raising the everyday script kiddie into a more advanced skill set) to make the job of detection more difficult. One should continually monitor and investi- gate network activity to gain an understanding of what to expect during day-to- day operations. www.syngress.com 194_HPYN2e_16.qxd 2/15/02 12:07 PM Page 713 714 Chapter 16 • IDS Evasion Solutions Fast Track Understanding How Signature-Based IDSs Work ; The capabilities of a network intrusion detection system (NIDS) are defined by a signature database.This enforces the requirement for repeated updates to combat the frequency of new vulnerabilities. ; Most NIDSs do not alert even to slight variations of the defined signatures.This affords an attacker the ability to vary their attack to evade a signature match. ; Attackers will continue to vary their evasion techniques such that the processing required to monitor and detect is greatly increased.This would contribute to denial of service (DoS) attacks and evasion possibilities. Using Packet Level Evasion ; Many vendors implement Transmission Control Protocol/Internet Protocol (TCP/IP) with slight variations.A NIDS has a difficult time in constructing a view of network communications as they appear to other systems.This inconsistent view is what allows an attacker to evade detection. ; Hosts may not adhere to Request for Comments (RFC) specifications and allow some packets where the NIDS may not. ; NIDSs do not have enough information from the wire to reconstruct TCP/IP communications.With the options and states available in a TCP/IP stack, some ambiguities form as to how a host would interpret information; there is an insufficiency of information transmitted between systems when communicating. ; Fragrouter and congestant are effective evasion tools.They implement a number of documented NIDS evasion techniques. www.syngress.com 194_HPYN2e_16.qxd 2/15/02 12:07 PM Page 714 [...]... measure your understanding of the concepts presented in this chapter and to assist you with real-life implementation of these concepts To have your questions about this chapter answered by the author, browse to www.syngress.com/solutions and click on the “Ask the Author” form Q: How many IDSs do I need to make them more effective? A: All networks are different and require varying levels of monitoring .Your. .. exposures Correlate your logs and IDS events to give you a better picture of what may be going on Do not rely on authorities and the network administrators of the attacking networks; they are usually far too overworked or uninterested to give a respectable amount of support Q: How do I know that my IDSs are working? A: Ongoing auditing and testing should be done to ensure that networking systems are... scanner.The second category is tools that will attempt to exploit security holes, and in some cases, use the newly compromised victim to further penetrate into a network. This category is newer, and in fact, tools have only been announced and are not yet available to the public.The first category is primarily intended for security administrators to evaluate their network for vulnerabilities The second category... to assist you in making a decision If the salesperson cannot answer your questions sufficiently, ask to speak to one of the product engineers My experience with vendors has usually been good as they are happy to help and answer any of your questions, but be wary of the marketingspeak Make your own decision as to what product will fit your needs False positive rates are probably the most annoying issue... thorough results, and no matter what commercial tool you choose, your second scanner should be Nessus.You can find Nessus at www.nessus.org Figure 17.3 Nessus Performing a Scan Security Administrators Integrated Network Tool (SAINT) SAINT is an updated version of one of the first vulnerability scanners, Security Administrator Tool for Analyzing Networks (SATAN) SATAN was released back in 1995 and checked... offering distributed scanning solutions that use multiple scan engines on multiple machines to scan the network then report back to a central reporting console In theory, this sounds like an acceptable solution, but it opens the floor to other issues, such as network bandwidth, and, of course, the potential security issues if the traffic isn’t handled securely Reporting is a feature that is slowly becoming... because no one product is a complete fit for every network. When deciding on a vulnerability scanner, you need to take the time to thoroughly evaluate each product for your specific needs and environment Almost all product vendors will offer you a free demonstration copy of their software—take them up on this offer.The worst-case scenario is that you will find yourself being phoned by their sales people to... www.westcoast.com/asiapacific/articles/2000_07/ testc/testc.html s Network Associates (NAI) CyberCop Scanner 5.5 www.secadministrator.com/Articles/Index.cfm?ArticleID=9203 s Axent (now Symantec) NetRecon 3.0 www.secadministrator.com/Articles/Index.cfm?ArticleID=9204 s ISS Internet Scanner 6.1 www.secadministrator.com/ Articles/Index.cfm?ArticleID=9205 s BindView HackerShield (now BV-Control for Internet Security)... known to exist.This alone is probably the best reason to use more than one scanner, and of course, constant monitoring of your systems www.syngress.com 194_HPYN2e_17.qxd 2/15/02 9:31 AM Page 727 Automated Security Review and Attack Tools • Chapter 17 If you are responsible for a large network, scanner performance is probably important to you A lot of factors affect the performance of the product.Two of... 194_HPYN2e_17.qxd 2/15/02 9:31 AM Page 725 Automated Security Review and Attack Tools • Chapter 17 scanned and the network it is attached to.The information obtained could be used in conjunction with other vulnerabilities or even with simple commands to further penetrate the system and the network it is attached to Many consulting organizations that perform penetration testing already have tools that . them more effective? A: All networks are different and require varying levels of monitoring .Your par- ticular risk tolerance should help you find this out, though.A network that desires a high. exposures. Correlate your logs and IDS events to give you a better picture of what may be going on. Do not rely on authori- ties and the network administrators of the attacking networks; they are. and analysis. Most networks are beginning to filter “suspicious” packets in any case—that is, any types with options and excessive fragmentations. Perhaps in the coming years, network layer normalizations