Vulnerability Development mailing list archives
Re: Bypassing "smart" IDSes with misdirected frames? (long and boring)
From: Jim Bauer <jfbauer () nfr com>
Date: Fri, 28 May 2004 09:28:38 -0400
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.
Current thread:
- Bypassing "smart" IDSes with misdirected frames? (long and boring) Michal Zalewski (May 28)
- Re: Bypassing "smart" IDSes with misdirected frames? (long and boring) Jim Bauer (May 28)
- Re: [Full-Disclosure] Re: Bypassing "smart" IDSes with misdirected frames? (long and boring) Michal Zalewski (May 28)
- Re: Bypassing "smart" IDSes with misdirected frames? (long and boring) Oliver Friedrichs (May 28)
- Re: Bypassing "smart" IDSes with misdirected frames? (long and boring) Jim Bauer (May 28)
- Re: [Full-Disclosure] Bypassing "smart" IDSes with misdirected frames? (long and boring) Aaron Turner (May 28)
- Re: Bypassing "smart" IDSes with misdirected frames? (long and boring) Mike Frantzen (May 28)
- Re: [Full-Disclosure] Re: Bypassing "smart" IDSes with misdirected frames? (long and boring) Michal Zalewski (May 29)
- Re: Bypassing "smart" IDSes with misdirected frames? (long and boring) Srini (May 29)
- Re: Bypassing "smart" IDSes with misdirected frames? (long and boring) Jim Bauer (May 28)