full-disclosure - Re: Bypassing "smart" IDSes with misdirected frames? (long and boring)

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-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <200405280928.38402.jfbauer@nfr.net>
From: jfbauer at nfr.com (Jim Bauer)
Subject: Re: Bypassing "smart" IDSes with misdirected frames? (long and boring)

On Thursday 27 May 2004 16:19, Michal Zalewski wrote:
> For the purpose of this discussion, let us assume the IDS has a
> detector designed to detect malicious SMTP commands sent to a remote
> server. The detector looks for "DEBUG" command in these commands, but
> not when the session is in BODY mode (because we do not want to
> trigger alerts whenever developers exchange mails with references to
> debugging). This is a naive example, but should be good enough. Our
> attacker, A, establishes a connection by performing a normal
> handshake with X, and sends a couple of typical commands first.
>
> 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 (belonging to host Y, some broadcast/multicast group, or just
> nobody in particular). This command is, of course, never received by
> the recipient (or, if sent to a broadcast address, will likely be
> ignored). The attack then continues as planned.

I don't see how a broacast MAC address would help the attacker.  The 
target would still recieve it.

> Now, an IDS that sees all network traffic but performs TCP stream
> analysis building on top of a traditional proto / saddr / daddr /
> sport / dport stream identification method (discarding hardware
> address data) - as I would expect it is almost always the case -
> would run into serious problems. Seeing a valid, correctly addressed
> "DATA" or RST packet with correct sequence numbers, the system has no
> reason not to interpret it, and to disable detection of abnormal SMTP
> commands temporarily or permanently.

The IDS will see not see a valid response to the "DATA" command (that is 
never received) so it will know it is still in SMTP command mode.  Even 
if your not-so-smart IDS let this slip by, there is still the issue of 
"DEBUG" not being in a valid format for a header.


> 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.