Intrusion detection system evasion techniques: Difference between revisions

Revision as of 03:40, 14 April 2016

Revision as of 05:16, 14 April 2016

Line 7:

Most IDSs have been modified to detect or even reverse basic evasion techniques, but IDS evasion (and countering IDS evasion) are still active fields.

<span data-ve-clipboard-key="0.5194384298974967-4"> </span>

==Payload obfuscation==

Line 19 ⟶ 17:

=== Polymorphism ===

Signature-based IDS often look for common attack patterns to match malicious traffic to signatures. To detect [[buffer overflow]] attacks, an IDS might look for the evidence of [[NOP slide|NOP slides]]s which are used to weaken the protection of [[address space layout randomization]].<ref name=":32">{{Cite journal|last=Chaboya|first=D. J.|last2=Raines|first2=R. A.|last3=Baldwin|first3=R. O.|last4=Mullins|first4=B. E.|date=2006-11-01|title=Network Intrusion Detection: Automated and Manual Methods Prone to Attack and Evasion|url=http://ieeexplore.ieee.org/lpdocs/epic03/wrapper.htm?arnumber=4042655|journal=IEEE Security Privacy|volume=4|issue=6|pages=36–43|doi=10.1109/MSP.2006.159|issn=1540-7993}}</ref>

To obfuscate their attacks, attackers can use [[Polymorphic code|polymorphic shellcode]] to create unique attack patterns. This technique typically involves encoding the payload in some fashion (e.g., XOR-ing each byte with 0x95), then placing a decoder in front of the payload before sending it. When the target executes the code, it runs the decoder which rewrites the payload into its original form which the target then executes.<ref name=":12" /><ref name=":32" />

Line 55 ⟶ 53:

In order to match certain signatures, an IDS is required to keep [[State (computer science)|state]] related to the connections it is monitoring. For example, an IDS must maintain "TCP control blocks" (TCBs), chunks of memory which track information such as sequence numbers, window sizes, and connection states (ESTABLISHED, RELATED, CLOSED, etc.), for each TCP connection monitored by the IDS.<ref name=":04" /> Once all of the IDS's [[random-access memory]] (RAM) is consumed, it is forced to utilized [[virtual memory]] on the [[Hard disk drive|hard disk]] which is much slower than RAM, leading to performance problems and dropped packets similar to the effects of CPU exhaustion.<ref name=":04" />

If the IDS doesn't [[Garbage collection (computer science)|garbage collect]] TCBs correctly and efficiently, an attacker can exhaust the IDS's memory by starting a large number of TCP connections very quickly.<ref name=":04" /> Similar attacks can be made by fragmenting a large number of packets into a larger number of smaller packets, or send a large number of out-of-order TCP segments.<ref name=":04" /><h3>

===Operator Fatigue</h3>===
Alerts generated by an IDS have to be acted upon in order for them to have any value. An attacker can reduce the "availability" of an IDS by overwhelming the human operator with an inordinate number of alerts by sending large amounts of "malicious" traffic intended to generate alerts on the IDS. The attacker can then perform the actual attack using the alert noise as cover. The tools 'stick' and 'snot' were designed for this purpose. They generate a large number of IDS alerts by sending attack signatures across the network, but will not trigger alerts in IDS that maintain application protocol context.

== References ==