Steve Riley on 802.1X Flaw

This is not a Microsoft issue, but I learned of it through a Microsoft Security Newsletter feature called 802.1X on Wired Networks Considered Harmful by Steve Riley. He claims to have written about this subject in his book Protect Your Windows Network: From Perimeter to Data, but he believes the issue merits greater attention. Cutting past the introduction to 802.1X, Steve writes:

"[T]here’s a fundamental flaw in wired, 802.1X that seriously reduces its effectiveness at keeping out rogue machines...

[I]t authenticates only at the establishment of a connection. Once a supplicant authenticates and the switch port opens, further communications between the supplicant and the switch aren’t authenticated. This creates a situation in which it’s possible for an attacker to join the network. (Thanks to Svyatoslav Pidgorny, Microsoft MVP for security, for showing me this vulnerability.)

Setting up the attack does require physical access to the network. An attacker needs to disconnect a computer (let’s call this the “victim”) from its 802.1X-protected network switch port, connect a hub to the port, connect the victim to the hub, and connect an attack computer (which we’ll call the “shadow”) to the hub. This is trivially easy if the attacker is physically inside your facility and if your Ethernet jacks are accessible. Or the attacker could connect an unmanaged access point to the hub and then conduct the attack from your parking lot. (Of course, the attacker could try to hide by disabling this AP’s SSI broadcast.)

The brief disconnection of the victim from the network won’t interfere with the attack’s success. When the victim computer is reconnected, it authenticates to the switch again. It doesn’t matter that a hub is in the way now, because a hub is little more than a wire with ports in it. Electrically, the victim is still connected to the switch.

Next the attacker configures the shadow computer’s MAC and IP addresses to be the same as those on the victim computer. A little network sniffing will quickly reveal this. The attacker also configures a host firewall to drop all inbound traffic that isn’t a reply to communications that it initiated.

Now, here’s why 802.1X on a wired network really is insufficient. After the victim computer has authenticated and the switch port is open, the attacker can connect to resources on the protected network. This is because there is no per-packet authentication of the traffic once the port is open. Since the shadow computer has the same MAC and IP addresses as the victim computer, from the point of view of the switch it appears only as if there’s a single computer connected to the port.

802.1X’s lack of follow-on per-packet authentication creates the situation for this man-in-the-middle attack I’ve just described. 802.1X only authenticates the connection; it assumes all traffic that’s flowing over the connection is legitimate. This assumption is 802.1X’s fundamental flaw."

Steve then addresses what happens when two computers try to use the same IP and MAC address while connected to the switch. If the "shadow" PC sends a SYN to a remote system, both victim and shadow PCs will see a SYN-ACK reply. The victim PC should reply with a RST (not RST ACK) because it won't be expecting an unsolicited SYN-ACK. Steve makes an interesting point, though:

"If the victim computer is running a firewall that drops unsolicited inbound SYN-ACKs, which most do, the victim won’t process the received SYN-ACK in step 2 and therefore won’t send the RST to the server. The rest of the above sequence won’t happen and the shadow computer can have complete access to the protected network.

This is the only instance I know of where a personal firewall on a computer can reduce the security of the rest of the network! Of course this is no reason not to deploy personal firewalls; their benefits strongly outweigh the likelihood of this attack actually happening."

I noticed Steve says the remote server, upon receiving a RST from the victim PC, will reply with "a RST-ACK (acknowledging the received RST and sending its own), which both the shadow and the victim receive."

This should not be the case. RFC 793 says a RST should not be sent in response to a RST. I don't know if Steve tested this in his own lab, since his description seems to mimic the page by Svyatoslav Pidgorny he mentions.

The bottom line appears to be that using 802.1X is a bad idea if an intruder has physical access to a port where a legitimate system is connected. 802.1X on wireless networks in not susceptible to this problem.