Vulnerability Development mailing list archives
Re: Bypassing "smart" IDSes with misdirected frames? (long and boring)
From: Mike Frantzen <frantzen () nfr com>
Date: Fri, 28 May 2004 14:51:58 -0400
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.
This has been a known attack at least since Ptacek and Newsham's seminal paper on IDS evasions.
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.
The problem is far worse than that. Including the hardware addresses in the stream identifier tuple is not a valid general solution; it turns out a decent percentage of IDS installations will be on the edge of a network with multiple links to the internet. So the IDS ends up seeing packets in the same connection with different MAC addresses (depending on which link the packet is going out). We (at NFR) saw that with some customers a few years back when we indirectly included MAC addrs in the connection identifier. We also run into the problem that some network cards have poor multicast filters. Those network cards' drivers have to put the card into promiscious mode to support IPv6 and it's multicast link-local addressing (even if one does't actually run an IPv6 LAN). So the host might end up accepting a packet to any MAC address as long as the IP is right. There is also the problem of some really crappy embedded devices not bothering with ARP and sending all packets to the broadcast MAC. I'm not sure about IEEE 802.3ad link aggregation (aka ethernet trunking, aka ethernet bonding) if packets are sent out with a consistent virtual MAC address or the MAC address of the NIC that actually transmitted the packet. Ambiguities abound. Fun fun :-) .mike frantzen@(nfr.com | cvs.openbsd.org | w4g.org) PGP: CC A4 E2 E8 0C F8 42 F0 BC 26 85 5B 6F 9E ED 28
Current thread:
- Bypassing "smart" IDSes with misdirected frames? (long and boring) Michal Zalewski (May 28)
- Re: Bypassing "smart" IDSes with misdirected frames? (long and boring) Jim Bauer (May 28)
- Re: [Full-Disclosure] Re: Bypassing "smart" IDSes with misdirected frames? (long and boring) Michal Zalewski (May 28)
- Re: Bypassing "smart" IDSes with misdirected frames? (long and boring) Oliver Friedrichs (May 28)
- Re: Bypassing "smart" IDSes with misdirected frames? (long and boring) Jim Bauer (May 28)
- Re: [Full-Disclosure] Bypassing "smart" IDSes with misdirected frames? (long and boring) Aaron Turner (May 28)
- Re: Bypassing "smart" IDSes with misdirected frames? (long and boring) Mike Frantzen (May 28)
- Re: [Full-Disclosure] Re: Bypassing "smart" IDSes with misdirected frames? (long and boring) Michal Zalewski (May 29)
- Re: Bypassing "smart" IDSes with misdirected frames? (long and boring) Srini (May 29)
- Re: Bypassing "smart" IDSes with misdirected frames? (long and boring) Jim Bauer (May 28)