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

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

From: frantzen at nfr.com (Mike Frantzen)
Subject: Re: Bypassing "smart" IDSes with misdirected frames? (long and boring)

> 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