Message-ID: <07fc01c444ef$e101f190$4505010a@SriniSony>
From: srao at intotoinc.com (Srini)
Subject: Re: Bypassing "smart" IDSes with misdirected frames? (long and boring)

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

Powered by blists - more mailing lists