Re: Bypassing "smart" IDSes with misdirected frames? (long and boring)

[nick black <dank () suburbanjihad net>]

On 2004-05-27, Michal Zalewski <lcamtuf () ghettot org> wrote:
> 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 is a variation on the generalized insertion attack as discussed in
Ptachek & Newsham's seminal "Insertion, Deletion and Denial of
Service," although not a particularly strong one (the ambiguity of
reassembly defines the difficulty of coping with insertion attacks;
there is precious little ambiguity as to whether this payload would
successfully traverse up to the application layer).

> 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

Why in the world would a system trying to recreate an accurate model of
network traffic patterns throw away some of the most basic and essential
inputs to its model?  Why not just throw away IPv4 addresses as well?
After all, link addresses are subsumed into the IPv6 address during
stateless address auto-configuration.

Furthermore, tossing this info eliminates a potentially useful hashing
key, negates any trust factor applied to hardware address controls
implemented by switches, makes detection and robust behavior in the face
of MAC flooding / ARP poisoning difficult, and leaves your IDS missing
appreciated functionality of humble little arpwatch...

The case you discuss is addressed in some detail by your friend and
mine, RFC 1122.  As a corollary of these careful guidelines being freely
available, history suggets a wide swath of implementations screwed things
up right and proper.

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

For that matter, any analysis performed on an SMTP stream will likely
detect a gross anomaly should the state machine be mangled in the manner
of an inserted DATA :).

> 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

Network topology drives IDS placement, and an interface is the least
granular entity one can meaningfully discuss in terms of its scope (IMHO).
Should, for some janky reason (unorthodox HA or load-balancing?), a
single IP address be "inverse-multihomed" to multiple interfaces with
the intention of a lossy mapping onto one IP stack's five-tuples,
deploying the IPS so that only one interface is monitored violates sane
rules of physical scoping (and the arp flux will entertain for hours).

The IDS shouldn't ignore the packet in this case given a strict
interpretation of RFC 1122; only link-layer broadcasts sans IP broadcast
destination addresses should be discarded.  If both are broadcasts, the
"specific destination address" is set to an IP associated with that
interface, and used as the target network address.  Stacks broken with
regard to these practices must be handled with the same hand-wavi^H^H^H
caution as other noncompliant garbage, which is why they pay us the big
bucks.  We work in the dark, we do what we can, etc and all that.

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

Yep!  This bromidic platitude could be generalized as "IDS's which
emulate defended state machines less crappily are less craptastic."

Much more irksome problems include properly robustifying TCP
reassembly in the face of gormless abortions of RFC 1323 implementations
or modeling a busy server whose busted hardware merrily blits gibberish
into its frames well before you've guessed the peer platform or path
differences.  They're all the same problem:  IDS's have yet to run on
anything more complex than Turing's randy old tape machine, and thus
can't perfectly simulate the functions defined by their defended brood.
(By the time my code whoops the Entscheidungsproblem and disproves Rice's
theorem, I hope to be well out of industry :) ).  As I said above,
however, the ambiguities raised by MAC-cycling are far less flummoxing
than others IDS's must deal with regularly.

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

I would simply be skeptical of an IDS which discounts any meaningful data
about the traffic it analyzes.  I'm not at all suggesting MAC addresses are
trustworthy or unspoofable in the general case, but they're as much a
part of the analysis process as any other addressing.  The fact that
IP's transport five-tuples leave them out (primarily to facilitate
multicasting, I'd assume) of the equivalency function doesn't change
that, and security capabilities of modern managed switches balance this
discrediting in certain environments.

I hope this wasn't abrasive or condescending; any attitude is due to
a protean heisenbug I've been chasing all evening :/.

These are my opinions and do not reflect policy of Reflex Security.

-- 
nick black <dank () reflexsecurity com>
"np:  nondeterministic polynomial-time
the class of dashed hopes and idle dreams." - the complexity zoo


---------------------------------------------------------------------------

---------------------------------------------------------------------------