Message-ID: <40B6A06D.7050008@brvenik.com>
From: security at brvenik.com (Jason)
Subject: Bypassing "smart" IDSes with misdirected frames?

Alexander E. Cuttergo wrote:

> On Thu, May 27, 2004 at 01:49:54PM, Michal Zalewski wrote:
> 
>>A potential attack scenario involves attacker A, who happens to be on a
>>logical network (VLAN) local to the IDS system (just a LAN workstation
>>within an enterprise),
> 
> If the attacker is on the same LAN as your IDS, you have many problems
> more severe than the attack you have described. 
> 
> More generally, if you can send a packet which is accepted by the IDS and
> not by the target host, you can bypass IDS. Another example is sending
> packets with low ttl; this even does not require access to the same LAN.
> 

Unfortunately examples of this already exist and work. You do not have 
to be on the local segment either. A major IDS Vendor has been confirmed 
to work in a broken way like this. The case causing this behavior seems 
like an optimization for performance to me but it allows the injection 
of bogus data into the data stream with only one system talking.

http://securitygeeks.shmoo.com/

"One of the top selling IDS vendors on the planet has a new method for 
defining "established" TCP sessions.

172.16.2.130.33012 > 10.2.2.250.143: SYN
172.16.2.130.143 > 10.2.2.250.33012: S/ACK
172.16.2.130.33012 > 10.2.2.250.143: ACK
    CONNECTION IS NOW ESTABLISHED
172.16.2.130.143 > 10.2.2.250.33012: ACK/PSH
172.16.2.130.33012 > 10.2.2.250.143: ACK
172.16.2.130.143 > 10.2.2.250.33012: ACK/PSH

(for those of you that didn't notice... all of the traffic is sent from 
ONE IP. In a TCP handshake, usually there are TWO parties involved... 
not one)

Someone should send Mr. Richards a copy of Mr. Stevens excelent book, 
TCP/IP Illustrated, Volume 1.

For those that want to test if your IDS handles TCP states in an ... 
interesting manor, feel free to use this pcap file [1].
"


> 
>>Then, an extra attack step involves host A sending an IP packet addressed
>>to host X and containing a valid message (be it a DATA command, or RST
>>frame, or whatnot), but to a bogus hardware-level address
> 
> [cut]
> 
>>Seeing a valid, correctly addressed "DATA" or RST packet with
>>correct sequence numbers, the system has no reason not to interpret it,
> 
> A packet which is not accepted by the recipient will not elicit an ACK frame.
> An IDS which accepts TCP data without checking for ACK frames can be
> bypassed in many ways - it is sometimes really hard to determine whether a
> given TCP packet is legal or not (from the point of view of the recipient).
> Of course, just checking for ACK is not enough (i.e. attacker sends quickly
> two packets with the same tcp seq), but this is a well discussed area not
> fitting within this mail.

Unless the attacker can generate a packet that is accepted without 
another participant. I also believe that PAWS and SACK can complicate 
things quite a bit relative to insertion. It is a fun game we can play...


> 
> 
>>Naturally, I have taken several shortcuts - a paranoid protocol analyzer
>>may also be checking for SMTP responses before accepting data mode, and so
>>forth; an ultra-paranoid IDS may also trigger alerts upon receiving data
>>past RST or strange retransmissions, at a cost of generating plenty of
>>false positives. But although there may be protocol-specific remedies in
>>this particular case, the attack itself appears to be exploitable using a
>>number of vectors.
> 
> In case of a reasonably well-written IDS, no. But I don't know how real life
> commercial IDS would handle it.

Try the ones you have

[1] - http://www.shmoo.com/~bmc/iss.pcap


> 
> peace,
> algo
> 
> 

Powered by blists - more mailing lists