IDS mailing list archives
Re: Bypassing "smart" IDSes with misdirected frames? (long and boring)
From: nick black <dank () suburbanjihad net>
Date: Fri, 4 Jun 2004 11:30:05 +0000 (UTC)
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 --------------------------------------------------------------------------- ---------------------------------------------------------------------------
Current thread:
- RE: Bypassing "smart" IDSes with misdirected frames? (long and boring) Phil Hollows (Jun 01)
- <Possible follow-ups>
- Re: Bypassing "smart" IDSes with misdirected frames? (long and boring) nick black (Jun 04)