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
