Message-ID: <20040527211810.Q50588@dekadens.coredump.cx>
From: lcamtuf at ghettot.org (Michal Zalewski)
Subject: Bypassing "smart" IDSes with misdirected frames? (long and boring)

Morning,

I have a question regarding smart IDS or IPS systems (either working in
parallel mode, or, in some cases, as an in-line bridge - but not as a
gateway). The question is a result of a thought experiment, and perhaps is
worth some further research, for which I regrettably do not have time at
the moment.

I think a clever attacker may be, in some circumstances, fool IDS/IPS
systems that perform protocol reassembly / tracking to detect anomalies or
reduce false positive rate - I think both Okena and Intruvert fall in this
category, among others.

A potential attack scenario involves attacker A, who happens to be on a
logical network (VLAN) local to the IDS system (just a LAN workstation
within an enterprise), and targets machine X. There is a IDS/IPS node D
listening on a span port of a switch somewhere down the road, or just
bridging two devices together.

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.

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.

Naturally, even if my assumptions are right, this is not a shocking
discovery. IDS avoidance is as ancient as IDSes themselves; modern
solutions can do quite well to stop those attacks, however, whereas this
approach may be a bit more difficult for them to handle.

The exposure is quite simple: an rogue entity on your network (be it a
malicious user, or an infected computer) may be able to avoid triggering
alarms or having his attacks stopped, despite of efforts to reassemble and
track protocols to avoid more traditional avoidance techniques.

So, would anyone be willing to comment or this or test it any further? I
am not as much looking for a hyphotetical discussion, but rather for
feedback on specific products and their vulnerability. It is obvious you
may configure some networks to mitigate such attacks, deploy third-party
solutions to detect them, or accept some false positives in certain
environments.

Thanks,
-- 
------------------------- bash$ :(){ :|:&};: --
 Michal Zalewski * [http://lcamtuf.coredump.cx]
    Did you know that clones never use mirrors?
--------------------------- 2004-05-27 21:18 --

   http://lcamtuf.coredump.cx/photo/current/

Powered by blists - more mailing lists