Reassemble or GTFO! – IDS Evasion Strategies
Arron Finnon
Goals of this talk :
- Basic understanding of IDS and how it works
- Challenges faced by IDS
- How bad guys can avoid IDS systems
What is CIDF?
CIDF is Common Intrusion Detection Framework
(e) Events box
(a) Analysis box
(s) Storage box
(c) Countermeasures
Typical Network IDS being deployed to detect intrusions. This enables us to detect what’s happening inside, but really bad for telling us whats happening to our network outside the perimeter.
Host vs. Network
Host IDS has a huge range of information to hand. This means it can gather a better overview of attacks than Network based systems. NIDS is unaware of host related issues.
Issues Faced by IDSes
- Ambiguous RFCs
- Inconsistencies in implementations
- Lack of system resources
- Lack of data to analyse
- Protocols
- UDP is easy
- TCP is more complex
IDS vendors speak more about throughput than they do about detection.
The need for IDSes to handle inconsistencies between how applications like Apache and IIS handle requests is a growing issue. IDSes need to cover all the bases to make sure attacks are detected correctly.
So what’s the point
Vendors tend to oversell IDSes –> Stops ALL known attacks!
They DON’T talk about detection rates
They DO talk about throughput –> How does this help the device owner? Blinky lights means it on right!
Out of the box detection rates are as low as 3%
IDS vendor tests rely too heavily on the vendor configuring and tuning the systems. Unrealistic test compared with standard installs.
Simple simple Evasions
Snort detects on AAAAAAAAAAAAAAAAA and on CCCCCCCCCCCCCC but not BBBBBBBB ?
Sure, because hackers only use A’s for buffer overflows!
HTTP Compression… GZIP’d and CHUNKED transfer encoding –> IDS has no way of knowing what and when the payload will stop!
The horrible truth
Lots of IDSes only detect things in the first xx bytes (usually around 300 bytes)
Inherently IDSes fail-open to avoid DoS conditions.
There are reasons for this. as they’re not part of the active network conversation, they shouldn’t take down the network if they fail.
Attacking NIDSes
IDSes don’t fair well in re-assembly at all. Snort is a great example of this.
Insertion Attacks
Force an NIDS to read a packet in a way that the end-point (target) won’t
Examples
- GET /cgi-bin/phf? HTTP/1.1 –> Easy to filter
- GET /cgi-bin/pleasedontdetectthisforme? HTTP/1.1 –> Harder (red = injected traffic)
So how can this be done!
- Invalid checksums in packet headers –> often ignored by the NIDS due to throughput
- TTL one short of target
- MTU mismatch –> If your NIDS MTU is lower than your target… DF Flag
- TCB –> TCP Sequencing
- ….
The TCB Issue
How does and IDS reorder unordered Streams?
The same way as any other system, sequence numbers
But at what point do you start?
Where to start
3 – Way Handshake
- Susceptible to evasion attacks
- Miss 3WHS and your IDS isn’t in sync
- Not good!
Take sequence from traffic
- Susceptible to insertion attacks
- Insert traffic to confuse the NIDS
Re-assembly attacks
- Reality 2x different looking streams inside 1
- Insertion vs. Evasion
- Network protocol inconsistencies
Overlapping fragments
Windows
- Fragments –> always favours the old data over the new
Unix
- Fragments –> always favours the new data over the old
There are more than 2 IP implementations, and more than 2 ways to deal with this… Lets not start on flags and how they’re handled in overlapping fragments.
An NIDS needs to know how to deal with things based on the target it is protecting.
Summary
- IDS/IPS cannot stop all known attacks
- Nevermind the unknown ones!
- IDS/IPS doesn’t need to be like a web server!
- It needs to be like ALL the web servers, ever!
- You can only do analysis on what you understand
- Deep Packet Inspection
Links :
Cатсн²² (in)sесuяitу / ChrisJohnRiley 
Pingback: First Press Coverage of DeepSec 2011 –
Pingback: Question for Hacker or InfoSec Pro….Evading the IDS « NetSecurityIT