MAC-spoofing through an 802.1X PNAC solution using a switch or HUB

[RobKoerts]

I have a question regarding MAC-spoofing in an 802.1X solution. Let's say I have the following deployment:

Authentication server: Cisco ISE
Authenticator: Cisco Catalyst 2960X
EAP-method: EAP-TLS
Supplicant: Single PC on a wall-outlet
Periodic re-authentication: Set to 1 hour

---

Now a hacker manages to get into the office and wants access to the network. The hacker removes the legitimate supplicant from the wall-outlet (switch-interface), identifies its MAC-address, adds a simple switch or HUB to the wall-outlet and reconnects the legitimate supplicant to the simple switch/HUB.

Due tot the disconnect, the 802.1X authentication and authorization process starts and the valid supplicant is authenticated once more. The hacker then spoofs the MAC-address on a malicious device, adds this device to the simple switch/HUB and removes the legitimate supplicant.

This way, the switch-interface behind the wall-outlet will not detect an interface change (down/up) and will not register a new MAC-address. I can imagine that the Authenticator will not attempt to re-authenticate in scenario.

---

The actual question: Does this mean that the malicious device now has access to the network? At least until the periodic re-authenticaton kicks in?

If not, awesome!
If so, what is the recommended way to protect the network from this scenario?

Things that come to mind are faster periodic re-authentication and proper monitoring, but I'm very curious if there are other ways to deal with it. (If it's an actual issue

[ahollifield]

Depends on how the switch is configured (multi-host, multi-domain, single host, multi-hosts).  Also the malicious device would not be able to perform the EAP-TLS authentication.  

[RobKoerts]

Thanks for your reply.

The idea behind this scenario is that the Authenticator switch can't tell that the legitimate supplicant has been replaced by the malicious device because it uses the (spoofed) MAC address of the legitimate device that already did a successful reauthentication after being reconnected to the network through the non-intelligent switch or HUB.

The authenticator switch won't detect a port down/up in this scenario (and thus won't force an 802.1x reauthentication) due to the extra non-intelligent switch or HUB that is placed between the Authenticator switch and the (malicious and legitimate) devices. The Authenticator switch also wouldn't see a second host on its interface since the MAC address of the malicious device is the same as that of the legimitate device.

So how would the Authenticator switch recognize the difference between traffic of the legitimate device and the malicious device in this scenario? The traffic originates from the same MAC address and there's no legitimate supplicant check (or a permanent session between supplicant and Authenticator) after a succesful 802.1X authentication. I believe that's why periodic reauthentication was invented.

My apologies if my scenario is a little vague. I'll make sure to add a drawing next Monday to clear things up.

[ahollifield]

This won’t ever work though because if you leave both devices connected with the same MAC address (one real one spoofed), both devices will have severe communication problems. Even dumb switches are still MAC aware so it would have no idea which port to send the frames.

[RobKoerts]

I explained in my original post that the legitimate device is removed after it succesfully performs its 802.1X authentication through the added switch/HUB, before adding the malicious device.

The port of the Authenticator switch stays up (since it is connected to the added switch), which means no 802.1X reauthentication takes place. This means that the Authenticator switchport still allows traffic for the legitimate device, since it doesn't know the legitimate device has been removed.

Switches use MAC addresses to identify unique hosts and to forward traffic. Now we connect the malicious device to the added switch/HUB with the same MAC as the legitimate device. 

How would the authenticator switch be able to tell the difference between the two? And what mechanic would prevent the malicious host from communicating in this scenario?

[ahollifield]

Right got it, I understand what you are asking now. See this link: https://www.cisco.com/c/en/us/td/docs/solutions/Enterprise/Security/TrustSec_1-99/Dot1X_Deployment/Dot1x_Dep_Guide.html#wp386865

I could think of a couple ways to mitigate this: aggressive session re-auth timers, inactivity timer (as referenced in link above), and MACSEC.

Also for this scenario you may also consider this to be more of a physical security problem too.

[RobKoerts]

So if I understand you correctly, the above scenario would allow the malicious device to communicate and thus this situation needs to be mitigated by taking extra measures. Preferably both physical and configurable. 

Thanks for your help, it's appreciated! I'll make sure to check out the document you linked.