nac_bypass: bypass Network Access Control (NAC, 802.1x)
nac_bypass
Requirements
The basic requirement for an NAC bypass is access to a device that has already been authenticated. This device is used to log into the network and then smuggle in network packages from a different device. This involves placing the attacker’s system between the network switch and the authenticated device. One way to do this is with a Raspberry Pi and two network adapters.
Installation
The NACkered script and our nac_bypass_setup.sh solution were written and tested on Debian-based Linux distributions, but both should be executable on other Linux distributions as well. The following software packages are required:
- Install tools, on Debian-like distros: bridge-utils, macchanger, arptables, ebtables, ipptables, mii-tools and tcpdump
- Load kernel module: modprobe br_netfilter
- Persist kernel module: br_netfilter into /etc/modules
For arptables, iptables and ebtables, make sure not to use Netfilter xtable tools (nft), or the script will not work as desired.
The nac_bypass_setup.sh script has the following parameters:
The parameters -1 and -2 define which network adapters will be used. You can also edit them directly in the script: -a suppresses the output of the script’s log and debugging information and no manual interaction is required when running it. The parameters -R and -S activate port forwarding for the use of SSH and Responder. The parameters -c, -i and -r only initiate certain sequences within the script.
Use
The legitimate device, client, is not initially connected to the network switch. Now the script is started on the attacker device, bypass. Bypass and attacker are one physical device. The attacker figure symbolizes actions carried out by the attacker on the NAC bypass device. The first step is the initial configuration: To start with, unwanted services, such as NetworkManager, are stopped, IPv6 is disabled and any DNS configurations are initialized. Next, the bridge is configured and started. To ensure bridging works as desired, the kernel has to be configured to forward EAPOL frames. Without this adjustment, 802.1X authentication will not be carried out.
Once the configuration is complete, the network cables can be connected and the bridge’s switch side is now enabled as a passive forwarder. The bypass device forwards all network traffic back and forth between the switch and the client but cannot send any packets itself. The client should now be authenticated with the network switch and can log into the network successfully.
All network traffic passes through the bridge and can be analyzed accordingly. This is done to capture Kerberos and SMB packets with tcpdump – as these are normally found in several places on a Windows network, making it possible to see the network configuration, such as the client’s IP and MAC address. This information is used to automatically configure the client side of the bridge. However, the bypass’s connection to the network remains blocked to ensure that network packets from the attacker device find their way onto the network and are detected. If packets from the attacker are sent onto the network later, an ebtables rule will overwrite the MAC address, meaning that the packets will appear as if they originated from the client. The same procedure is implemented using iptables rules at the IP level, so that outgoing TCP, UDP and ICMP packets also have the same IP address as the client. Finally, the attacker is able to connect to the network and can carry out actions from their own device.
If port forwarding has been enabled for SSH and Responder, the bridge forwards all requests for the respective ports to the attacker’s services. From there, a Responder instance can be run to carry out multicast poisoning and to perform authentication for protocols such as SMB, FTP, or HTTP. This instance can be reached from the network using the client’s IP address.
Copyright (c) 2019 scip AG
Source: https://github.com/scipag/