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.
"[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.
Comments
802.1x wired auth with hard coded MACs on the switch ports is a good way to minimize rogue computers from obtaining an IP address from a DHCP server, say a Windows 2003 active directory domain.
By itself, it is not a solution for network protection. Utilizing IPSec (AH+ESP) on the LAN is a better solution for the protection of data.
Using 802.1x auth beyond the inital recognition is not what 802.1x was meant for. MitM is a fundamental flaw in 802.1x wired or wireless.
However, utilization of PKI/Smart cards (two factor auth) mitigates this risk somewhat.
If 802.1x is a bad idea, what's a good idea? I don't know of any other technology that allows for seperation between guest and data networks. Is there anyway to mitigate this?
It seems that this man-in-the-middle type attack doesn't just defeat 802.1x but Port Security as well. As multiple machines can hide behind the same MAC and IP on the same port.
rarmknecht: IPSEC is a better solution. It authenticates every packet that the computer receives. Check out IPSEC documentation from microsoft for more info.
A better way to circumvent 802.1x would be to use an inline device that does the masquerading and acts as a transparent bridge. This way is can generate it's own traffic without the intervention of the legitimate station and still allow genuine traffic to pass unheeded.
Very difficult to see a way to prevent this attack without a per flow authentication.
/Giza