Vulnerability Development mailing list archives
Re: Bypassing "smart" IDSes with misdirected frames? (long and boring)
From: "Srini" <srao () intotoinc com>
Date: Fri, 28 May 2004 13:10:50 -0700
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 next packet from the attacker is then sent to a correct IP and hardware address, both belonging to X. The packet contains the actual attack code, the "DEBUG" command, but when noticed by the IDS/IPS, would be: - Deemed to be coming from the past, because the sequence number is lower than now expected. This packet would likely be ignored as a result of network hiccup corrected by retransmission. - Even if not ignored, the command would not be interpreted as an attack, because the connection is now in DATA mode, supposedly. 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. The most obvious solution appears to be the inclusion of hardware addresses as a stream identifier - so that a packet sent to a different hardware address would not be considered as belonging to the same connection. There is a catch, however: this enables the attacker to use an opposite attack, and send a malicious command in a packet addressed to a broadcast address, or a secondary NIC of a machine, and hope it will be accepted by the recipient, but ignored by the IDS as a stray ACK. It appears to me that only those systems that specifically look for "MAC addresss jumping" effect within a connection may be capable of providing a good mean of detecting those problems.
Stream/Session identification is normally done by 5 tuples (source ip, dest ip, protocol, sport, dport). If IDS/IPS is run in brige mode, one more validation is done ie whether the source MAC/destination MAC match the MAC addresses that are populated in the session (when the session is established, both end points MAC addresses are noted down). If they don't match, IDS/IPS systems can be configured to either drop the packet or notify the administartor (via logs). Srini
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)