Re: Bypassing "smart" IDSes with misdirected frames? (long and boring)
From: Srini (srao_at_intotoinc.com)
To: "Michal Zalewski" <firstname.lastname@example.org>, <email@example.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
> 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
> - 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).