In the article entitled Network Access Control – What’s important to remember with NAC?, Dominik Altermatt described the basics of Network Access Control (NAC) and briefly discussed how to bypass this control mechanism. In this edition of Labs, we will introduce a practical solution for bypassing port-based IEEE 802.1X network access control.

Standing on the shoulders of giants

In 2011, Alva Lease “Skip” Duckwall IV gave a presentation at Defcon 19 entitled A Bridge Too Far in which he showed how 802.1X can be bypassed using a Linux transparent bridge. Based on these principles, Matt E wrote the bash script NACkered v2.92.2. We then used this script to write our own NAC bypass script collection, which we have released on our GitHub page.

At first, the plan was to use NACkered and make selective changes as needed. But we gradually found ourselves changing so many things that we ultimately developed a standalone solution. We included one extension to support Laurent Gaffié’s Responder tool, because the combination of NAC bypass and Responder is very useful for internal network-based penetration tests or as part of red team assessments to gain access to login credentials.

Requirements and setup

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.

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:

• bridge-utils
• macchanger
• arptables, iptables and ebtables
• mii-tool
• tcpdump
• br_netfilter (kernel module)

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:

nac_bypass_setup.sh v0.6.1 usage:
    -1 <eth>    network interface plugged into switch
    -2 <eth>    network interface plugged into victim machine
    -a          autonomous mode
    -c          start connection setup only
    -h          display this help
    -i          start initial setup only
    -r          reset all settings
    -R          enable port redirection for Responder
    -S          enable port redirection for OpenSSH and start the service

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. Their respective functions will be discussed in more detail later.

Use

The nac_bypass_setup.sh script is used together with a legitimate device as shown in the diagram below:

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 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.

Bypassing NAC in an infinite loop

The scenario described above is only possible if the attacker is in possession of a legitimate device. But if the attacker only has physical access to a building and its rooms and does not have their own device, additional steps are necessary. If a room has a network installation – e.g. a meeting room or shared workspace – the bypass device can still be installed. However, it must be noted that the NAC bypass setup is agile and can respond to changes such as switching devices. With a shared workspace, for example, User1 connects their device to the docking station in the morning. The hidden bypass device installs its configuration on User1’s device. As soon as they leave the shared workspace, the bypass device resets to the initial state and waits for new devices. If User2 connects their device to the docking station, the bypass device is no longer allowed to run with User1’s configuration. Instead, it must use User2’s credentials to connect to the network.

The bypass device therefore checks network connectivity at certain intervals and then responds to status changes and then invokes the appropriate NAC bypass procedure. We created a simple implementation of this check with the awareness.sh script, which checks an adapter’s network status every five seconds and responds accordingly when the status changes.

while true
do
    NETWORK_STATE_INTERFACE=`cat "/sys/class/net/$INTERFACE/carrier"`

    if [ "$NETWORK_STATE_INTERFACE" -ne "$STATE_INTERFACE" ]; then

        STATE_COUNTER=0

        if [ "$NETWORK_STATE_INTERFACE" -eq 1 ]; then
            echo "[!] $INTERFACE is now up!"
        else
            echo "[!] $INTERFACE is now down!"
        fi
    else

        if [ "$STATE_COUNTER" -eq "$THRESHOLD_UP" ] && [ "$NETWORK_STATE_INTERFACE" -eq 1 ]; then
            echo "[!!] Set new config"
            bash nac_bypass_setup.sh -a -c

        elif [ "$STATE_COUNTER" -eq "$THRESHOLD_DOWN" ] && [ "$NETWORK_STATE_INTERFACE" -eq 0 ]; then
            echo "[!!] Reset config"
            bash nac_bypass_setup.sh -a -r
            bash nac_bypass_setup.sh -a -i
        fi

        echo "[*] Waiting"
        ((STATE_COUNTER++))
    fi

    STATE_INTERFACE=$NETWORK_STATE_INTERFACE
    sleep $TIMER
done

First, the basic setup for the NAC bypass is configured. Next, a loop is started to monitor the state of the network interface. The second part of the NAC bypass setup is then executed as soon as the interface is activated. If the network connection is lost, the configuration is reset and initialized. Configurable cycles are also set between the status changes to avoid premature configuration changes when network connectivity is lost temporarily, for example. This script allows a bypass device to respond to device switching; this can be done without any manual intervention over an extended period of time by placing the device in an appropriate room.

Next steps

The awareness.sh script responds to status changes and modifies the NAC bypass configuration accordingly. All other actions must be carried out manually at present using the likes of SSH on the device. This SSH service is only available on the victim’s network, however. One of the next steps is the planned integration of an additional management interface using a WLAN or cellular network adapter. This adapter could then be used to establish an autonomous connection, allowing the attacker to access the device without having to be physically on the premises or network. The awareness script could also be enhanced to include modules that ensure more autonomy. For example, communication via a command and control server (C2) can be configured to receive commands or extract data. The NAC bypass project is available on GitHub. We appreciate any feedback you may have and welcome pull requests.

About the Author

Michael Schneider has been in IT since 2000. Since 2010 he is focused on information security. He is an expert at penetration testing, hardening and the detection of vulnerabilities in operating systems. He is well-known for a variety of tools written in PowerShell to find, exploit, and mitigate weaknesses. (ORCID 0000-0003-0772-9761)

Links

• https://1.ieee802.org/security/802-1x/
• https://g-laurent.blogspot.com/
• https://github.com/lgandx/Responder
• https://github.com/p292
• https://github.com/p292/NACKered
• https://github.com/scipag
• https://github.com/scipag/nac_bypass
• https://github.com/scipag/nac_bypass/blob/master/awareness.sh
• https://raspberrypi.org/
• https://twitter.com/0×6d69636b/status/1067802857141911552
• https://wiki.nftables.org/wiki-nftables/index.php/Legacy_xtables_tools
• https://www.defcon.org/images/defcon-19/dc-19-presentations/Duckwall/DEFCON-19-Duckwall-Bridge-Too-Far.pdf