In recent years, Network Access Control (NAC) solutions based on the 802.1x protocol have gained significant traction. Like all security solutions, it is crucial to carefully evaluate their functionality to integrate them into a proper Cybersecurity strategy.

I understand that this evaluation requires highly specific technical knowledge, and often those assessing rely on what is described in datasheets. This post serves three purposes:

1. to raise awareness that incorrectly assessing a security solution exposes organizations to threats;
2. to describe the steps by which a threat actor can exploit weaknesses in NAC solutions,
3. to be informative and therefore understandable even to non-technical individuals.

Introduction: NAC solutions

First and foremost, an overview of NAC or Network Access Control solutions is necessary. These solutions are based on the 802.1x protocol to authenticate and authorize connected devices. Some solutions, through additional components, also assess device behavior to identify any anomalies.

The problem these solutions aim to solve is related to unauthorized access to Ethernet ports by unauthorized devices. Specifically, these solutions protect ports naturally accessible to individuals, particularly in offices and public areas.

Over time, these solutions have evolved to not only authenticate but also authorize and profile connected devices. In other words, it is possible to dynamically configure Ethernet ports based on connected devices. This functionality greatly aids in improving and automating the management of large and dynamic campus areas.

Device authentication is based on the 802.1x protocol: the switch requests authentication from the device, and authentications are validated through external servers. Authentication can occur via username and password or through certificates. Once the device is authenticated, the channel is active until the session expires, which must then be renewed.

Over time, solutions have evolved to support multiple connected devices, such as:

• Phone with cascaded computers;
• Computers with virtual machines;
• …

However, in the real world, there are numerous devices that do not implement the 802.1x protocol. NAC solutions have further “evolved” (perhaps it would be more correct to say “devolved”), authenticating devices based on their MAC address: this functionality is called MAB or MAC Address Bypass. It is evident that the term “bypass” cannot be associated with a security feature, and indeed, we recall that NAC solutions are also used for automation.

The most important consideration, however, concerns how an authenticated session is established. 802.1x allows authentication of the channel, not individual packets. Specifically, the switch associates the authenticated session with the MAC address of the device. An attacker can thus insert a malicious device between the authenticated device and the switch, exploiting the authenticated channel.

The final consideration concerns what I call “silent” devices. For NAC solutions to work, connected devices must support 802.1x or transmit at least one packet to make their MAC address known to the switch. Some devices are designed to receive data but not transmit it, making it impossible to use any NAC solution.

Switch configuration

Switch configuration should be carefully evaluated to minimize risks, which, as we will see later, are still present.

Each Ethernet port can be configured in various modes depending on the vendor. Examining Cisco switches, the modes are:

• Multi-Host: once the port is authenticated by the connected device, any other device can use the channel (for example, in the case of virtual machines).
• Multi-Domain: each connected device, belonging to a specific VLAN, must be authenticated (for example, in the case of cascaded phones and computers).
• Multi-Auth: each MAC address that appears on the Ethernet port must be authenticated.
• MAB: no real authentication is performed, but only a check that the MAC address is enabled.

Where possible, the preference should be, in order, Multi-Auth, Multi-Domain, Multi-Host, MAB (note: definitions depend on the vendor, the important thing is to understand the concept).

MITM on 802.1x

From the attacker’s perspective, in the worst-case scenario, inserting oneself between an authenticated device and a switch means being transparent. Specifically, it means, in order:

1. forwarding any data to and from the switch without applying any filters to local frames;
2. waiting for the channel to be authenticated;
3. emitting data using only the MAC address and IP address of the authenticated device.

There are two possible ways to implement the above:

1. building a software switch running in user-space, probably resulting in less optimal performance;
2. leveraging components offered by Linux, thus working in kernel-space with better performance, albeit with some limitations.

With reference to the second approach, the three steps translate operationally into:

1. compiling a custom kernel so that all frames are forwarded by Linux Bridge;
2. reading the MAC address of the connected device;
3. analyzing passing data until obtaining the IP address of the connected device and the MAC address of the gateway;
4. configuring a Linux Bridge, iptables, and ebtables so that it is possible to communicate with the outside using the MAC address and IP address of the connected device;
5. activating a covert channel that allows the malicious device to be exploited remotely.

The result will be a device practically invisible and remotely manageable.

Defense strategies

Programming a device to transparently exploit an authenticated 802.1x session is not simple but not overly complex either. Therefore, it is necessary to consider the risk that ports with promiscuous access may be compromised as described above.

For several years, my approach has been to consider networks with promiscuous access akin to DMZ networks: high-risk areas that require high visibility and very restrictive policies. No assumptions can be made about the security of connected devices.

A first approach is therefore to increase visibility by adding behavioral analysis of devices: if a printer starts communicating with an unknown remote site, uploading more or less significant data, a red flag should go up somewhere.

A second approach involves using a zero-trust approach, creating policies that allow only what is strictly necessary, thus limiting the scope of action of any malicious devices. In this regard, the use of Private VLANs can further reduce the attack surface. However, it is always necessary to keep in mind how a device is authenticated: for example, if a specific computer is authenticated based on the user using it, and if following user authentication, firewalls use the user’s IP address as the basis for evaluating policies, then this mechanism cannot be considered secure. Indeed, the hypothetical malicious device mentioned above will use the same IP address assigned to the user.

A third approach, less common but extremely effective, involves using an additional layer consisting of IPSec or similar protocols. This approach, which I like a lot, considers promiscuous networks as if they were public networks: users who authenticate on these networks must use VPN systems to access internal company networks.

There is a further approach, not yet applicable, which concerns the possibility of encrypting the device-switch channel and rendering it unusable from MITM attacks. MACSec (802.1ae) is the standard that implements this type of functionality but is not currently implemented on access switches and endpoint devices.

References

• An oddly specific post about group_fwd_mask
• Configuring 802.1X Port-Based Authentication
• https://deployingradius.com/documents/protocols/compatibility.html
• Configuring PAP
• Defeating Wired 802.1X with a Transparent Bridge Using Linux
• Bypassing Port Security In 2018