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.
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.
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.
peace,
algo
pgpAjn7y0tEr3.pgp
Description: PGP signature
