full-disclosure - Bypassing "smart" IDSes with misdirected frames?

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [thread-next>] [day] [month] [year] [list]

Message-ID: <20040527192451.GA23434@gmx.net>
From: cuttergo at gmx.net (Alexander E. Cuttergo)
Subject: Bypassing "smart" IDSes with misdirected frames?

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


-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
Url : http://lists.grok.org.uk/pipermail/full-disclosure/attachments/20040527/4f9eb2bd/attachment.bin