Defeating Sniffers and Intrusion Detection Systems

(Taken from phrack.com, the best Hacker zine ever)

-------------------------[ Defeating Sniffers and Intrusion Detection Systems

----[ Overview

The purpose of this article is to demonstrate some techniques that can be used

to defeat sniffers and intrusion detection systems. This article focuses

mainly on confusing your average "hacker" sniffer, with some rough coverage of

Intrusion Detection Systems (IDS). However, the methods and code present in

this article should be a good starting point for getting your packets past ID

systems. For an intense examination of attack techniques against IDS, check

out: http://www.nai.com/products/security/advisory/papers/ids-html/doc000.asp.

There are a large number of effective techniques other than those that are

implemented in this article. I have chosen a few generic techniques that

hopefully can be easily expanded into more targeted and complex attacks. After

implementing these attacks, I have gone through and attempted to correlate

them to the attacks described in the NAI paper, where appropriate.

The root cause of the flaws discussed in this article is that most sniffers

and intrusion detection systems do not have as robust of a TCP/IP

implementation as the machines that are actually communicating on the network.

Many sniffers and IDS use a form of datalink level access, such as BPF, DLPI,

or SOCK_PACKET. The sniffer receives the entire datalink level frame, and

gets no contextual clues from the kernel as to how that frame will be

interpreted. Thus, the sniffer has the job of interpreting the entire packet

and guessing how the kernel of the receiving machine is going to process it.

Luckily, 95% of the time, the packet is going to be sane, and the kernel

TCP/IP stack is going to behave rather predictably. It is the other 5% of the

time that we will be focusing on.

This article is divided into three sections: an overview of the techniques

employed, a description of the implementation and usage, and the code. Where

possible, the code has been implemented in a somewhat portable format: a

shared library that wraps around connect(), which you can use LD_PRELOAD to

"install" into your normal client programs. This shared library uses raw

sockets to create TCP packets, which should work on most unixes. However, some

of the attacks described are too complex to implement with raw sockets, so

simple OpenBSD kernel patches are supplied. I am working on complementary

kernel patches for Linux, which will be placed on the rhino9 web site when

they are complete. The rhino9 web site is at: http://www.rhino9.ml.org/

----[ Section 1. The Tricks

The first set of tricks are solely designed to fool most sniffers, and will

most likely have no effect on a decent ID system. The second set of tricks

should be advanced enough to start to have an impact on the effectiveness of

an intrusion detection system.

Sniffer Specific Attacks

------------------------

1. Sniffer Design - One Host Design

The first technique is extremely simple, and takes advantage of the design of

many sniffers. Several hacker sniffers are designed to follow one connection,

and ignore everything else until that connection is closed or reaches some

internal time out. Sniffers designed in this fashion have a very low profile,

as far as memory usage and CPU time. However, they obviously miss a great deal

of the data that can be obtained. This gives us an easy way of preventing our

packets from being captured: before our connection, we send a spoofed SYN

packet from a non-existent host to the same port that we are attempting to

connect to. Thus, the sniffer sees the SYN packet, and if it is listening, it

will set up its internal state to monitor all packets related to that

connection. Then, when we make our connection, the sniffer ignores our SYN

because it is watching the fake host. When the host later times out, our

connection will not be logged because our initial SYN packet has long been

sent.

2. Sniffer Design - IP options

The next technique depends on uninformed coding practices within sniffers.

If you look at the code for some of the hacker sniffers, namely ones based-off

of the original linsniffer, you will see that they have a structure that looks

like this:

struct etherpacket

{

etherheader eh;

ipheader ip;

tcpheader tcp;

...