An all-encompassing NAC solution is designed to do just what the name implies: check specific criteria to allow or block a device’s access to the network.

Essentially, NAC is intended to address two issues:

• Authentication: Only authorized devices should be granted access to the network, such as an employee’s personal laptop. In contrast, a hacker’s harmful devices should be blocked from the network.
• Compliance: Authenticated devices are granted authorization when they meet additional criteria. These include passing tests for current antivirus patterns and OS patch level requirements.

NAC solutions are now automated in such a way that devices rejected by NAC are not simply denied access. Instead, alternative options can be defined. An unknown device can, for example, be routed via VLAN to a guest zone. In this scenario, captive portals (such as in hotels) use a web login for guest authentication before the guests are able to access the Internet. In addition, authorized devices with obsolete antivirus patterns can be routed to a quarantine environment, which only allows access to the update server of the antivirus solution. This provides an opportunity to update the antivirus patterns so that the legitimate device then complies with NAC before it is allowed access to the network.

In addition, NAC provides for a separation between various organizational units, so that a device assigned to HR, for instance, can only access HR’s specific network resources. So an NAC solution not only makes things harder for hackers, it also prevents harmful actions from potentially being carried out by one’s own employees. The range of NAC applications is therefore very extensive and complex.

NAC implementation

NAC can be implemented in a variety of ways. The big manufacturers offer packages that include hardware with the necessary features and software (agent and administration server). In some cases, cross-vendor implementations are available, although these typically have a more limited range of features and may also require more effort to configure.

The following two methods are usually used for the authentication of devices:

• MAC-based: The device is identified at the switch by verifying the MAC address and then granting authorization with access control lists (ACL) for the network.
• Certificate-based: The device sends its locally installed 802.1x machine certificate to the switch, which then uses ACLs to verify the validity in order to allow access.

Then there are two common methods used for compliance checks:

• Agent: A software agent is installed on the device. This must be configured with the defined policies. If the device meets the required criteria, it is allowed to access the network.
• Scanner: A vulnerability scanner that scans the device in a special zone is one alternative. The results are sent to the NAC server and checked against the relevant policies.

NAC bypass

First of all, the simplest NAC bypass would involve finding a switch that does not use NAC. These are usually core switches. Normally the only way to protect against this type of bypass is to secure the rooms in which the core switches are located. There should also be a concept for controlling and monitoring physical access to these rooms.

Another possibility is to disrupt the NAC infrastructure, i.e. to make it inaccessible so that it is not possible to verify MAC addresses or certificates via the NAC server. Many NAC solutions are set up with a fallback scenario, so that there are only two possibilities: either allow all or block all devices. If all devices are allowed, an attacker can do their dirty work during the time window between when the NAC solution goes down and when its service is restored.

MAC spoofing

Unfortunately, many companies still use MAC-based NAC. It’s easy for a hacker to spoof a MAC address and access the network, even when MAC-based NAC has been implemented.

If the ACLs are configured with very strict and exact rules, a hacker would need to get the MAC address of a specific client. In other words, if the hacker wants to attack the accounting department, they would need the MAC address from an employee in the accounting department. This would merely require that the hacker briefly get their hands on a device from the accounting department to obtain the MAC address. Essentially, to get their hands on a valid MAC address, the hacker could spy on broadcast traffic or employ brute force methods.

The MAC-based NAC scenario should be avoided whenever possible.

802.1x bypass

The certificate-based type of NAC is, of course, quite a bit trickier to fool.

Most certificate-based NAC implementations nevertheless have a vulnerability that is easy to exploit. A clean certificate-based NAC solution requires that any device accessing the network must support 802.1x. However, many companies have exceptions, such as for IP telephones, printers, postage machines, TV panels, etc. Taking a hard-line approach would require replacing or upgrading all devices that do not support 802.1x. This is not always possible or practical, however, which is why exceptions arise that have to be managed alternatively via MAC-based NAC concepts. The resulting gaps can then be exploited with MAC spoofing. Because these device exceptions usually have very specific roles, hacking opportunities can be minimized through very strict and modified MAC ACLs.

Another vulnerability is found in the staging area of the client. If a new device is installed for a company employee, the device will initially have no certificate that can be used for authentication. The installation therefore requires accessing the network without NAC. To deal with this problem, the relevant network zones should be limited to the minimum required network infrastructure resources.

The following certificate-based NAC bypass would require that the hacker install a malicious device between a legitimate device and the switch. It is possible to circumvent the NAC solution by using a man-in-the-middle attack with the right tools (known examples currently include Marvin or FENRIR). The hacker can sneak past NAC controls and onto the network by piggybacking onto a legitimate client.

The malicious devices currently used for such purposes can be very small and hidden in cable conduits in tables, floors and ceiling panels, for example. Equipped with a battery pack and GSM modules, these devices are almost completely self-sufficient and can be controlled remotely.

It is very difficult to guard against these types of attacks. To create more barriers for hackers, measures should be taken to ensure that no devices (e.g. info panels or batch readers at entrances) with access to the internal client network are used in publicly accessible areas. In addition to this, there should always be adequate access control systems in place (batch systems and turnstiles). Additional protections include identifying attacks with systems that monitor network traffic (IDS and access analyses, reports and alerts).

Conclusion

From the hacker’s perspective, a clean NAC solution can greatly increase the difficulty of a successful attack. Companies without NAC run the risk of a hacker hiding a malicious device in a meeting room to quite easily capture NTML hashes and use these for dubious purposes. Many companies have responded to this and similar scenarios. However, a lot of NAC solutions are still MAC-based, and compliance checks are rarely implemented. As a rule, MAC-based NACs should not be used. In the case of certificate-based NAC solutions, those responsible should be fully aware that all network devices need to support 802.1x to ensure a clean implementation. If exceptions are unavoidable, these should be managed properly. It is important to know the exact location of these exceptions, and for the access possibilities of these devices via ACLs to be reduced to the bare minimum. The scenario involving the non-availability of the NAC infrastructure also needs to be analyzed and the issue addressed as to whether the whole staff is blocked from access or whether the risk remains at an acceptable level while the NAC is down.

The often underestimated management of the certificates should not be neglected either: devices with expired certificates are no longer allowed access to the network. When choosing the cryptographic properties of the certificates, it is also important to use the latest methods considered to be secure.

Like any security concept, NAC is no panacea and should always be implemented and managed together with a sound security foundation and complementary security concepts.

About the Author

Links

• http://resources.infosecinstitute.com/nac-hacking-bypassing-network-access-control/#gref
• http://www.hackingarticles.in/4-ways-capture-ntlm-hashes-network/
• https://github.com/Orange-Cyberdefense/fenrir-ocd
• https://standards.ieee.org/findstds/standard/802.1×-2010.html
• https://www.gartner.com/reviews/market/network-access-control
• https://www.gremwell.com/marvin-mitm-tapping-dot1x-links
• https://www.lifewire.com/layer-3-switch-817583