Conducting internal network penetration tests is always fun. There are vulnerabilities that easily help me to get to “keys of the kingdom” i.e. domain admin. However, I had hit a wall when a client refused to whitelist my device on their NAC. It was this time where I had to think out-of-the-box first to get into the network and then eventually compromise their domain admin account.
In this article, I will be covering the following:
- How NAC solutions work in brief.
- The scenario of the attack and how I bypassed NAC.
- Another technique to bypass NAC.
- Possible mitigations to reduce the effectiveness of a NAC bypass.
What is NAC and how they work (NAC 101)
Network Access Control or NAC is a solution to prevent unauthorized access to internal networks. It restricts access to the network based on identity or security posture of the device that is trying to connect.
How NAC works:
When a device connects to the network, the NAC relies on one or more detection techniques to detect the devices’ presence. They are listed below:
DHCP Proxy – a NAC solution intercepts DHCP requests for network configuration information coming from elements operating on the network disclosing their presence.
Broadcast Listener – a NAC solution listens to broadcast network traffic, such as ARP requests, DHCP requests, etc., generated by elements operating on the network disclosing their presence.
Listening to (sniffing) IP traffic – IP packets passing through a certain monitoring location disclosing a certain element is connected to the network.
Client-Based Software – some NAC solutions make use of client-based software as part of the solution architecture, which is used to perform endpoint security assessment to prevent an element from obtaining network configuration information until it is evaluated and to notify a centralized management console the element is on the network.
SNMP Traps – some switches can be configured to send an SNMP trap when a new MAC address is registered with a certain switch port. The SNMP trap information details the MAC address and the network interface on which it was registered.
Most of the NAC solutions available today use only one of the detection techniques. Detecting various devices on the network is one of the key elements of the NAC and if the NAC is incorrectly configured and if it fails at detecting a device connecting to the network, the NAC solution can be bypassed.
When a NAC solution identifies the presence of a new device, it then checks if the device complies with the organizational policies such as latest version of AV installed, etc. Once NAC confirms the checks, it then authorizes the device to connect to the network.
Now that we know briefly how NACs work let’s have a look at the scenario of the NAC bypass.
The scenario of the attack and how I bypassed NAC
I conducted a black box assessment as an outsider having physical access to the target organization and had no prior knowledge of the network/infrastructure or subnet ranges nor had my device whitelisted on the network.
As every penetration test starts, my first step begins with information gathering. I had nothing but a VoIP phone next to me of an employee who was on leave. I started to look at the settings, and I got the following details:
- Call Manager TFTP server IP address,
- DHCP server IP,
- Default gateway,
- MAC Address of VoIP phone, etc.
I plugged in my device on the network, but the NAC gave me access to only reach the guest network. I tried to ping the IP addresses gathered but was expectedly unsuccessful.
I thought to myself, based on what do VoIP phones or network printers get connected on the network. Since VoIP phones and network printers are non dot1x authentication capable devices, they, therefore, cannot have an updated AV signature list and so on. They will definitely need to be whitelisted based on MAC as there is no mechanism for the NAC to assess these kinds of devices. If I spoofed the MAC address, then I should be seen as that VoIP phone by the NAC.
Converting my thoughts to actions, I spoofed the MAC address of the VoIP phone on my Windows system to see if my theory worked and found that I was correct. I could access the Voice VLAN IPs and also was able to reach the Server VLAN subnet ranges. This was one of the best NAC solutions around, and I was surprised it could not detect my device as a Windows system.
**the evidence of the MAC address of the originally spoofed VoIP phone could not be initially gathered.
It can be seen that my device is in the domain beginning with gbm and after spoofing the mac address it is a part of domain beginning with qi. I was then able to ping the active directory successfully.
Voila!! I was in the network, able to scan ports and do other nasty things that eventually led me to domain admin.
Ethical Hacking Training – Resources (InfoSec)
Other techniques to bypass NAC
While writing this article, I came across another blog post that mentioned how a penetration tester bypassed a NAC solution using IPv6. It is pretty cool, so I thought of sharing it here too.
Mitigations to reduce the effectiveness of a NAC bypass.
My first step towards gaining access to the network was to gather information from the VoIP phone lying around. Users normally do not need access to such information. Hence access to the network configuration on VoIP phones should be locked down. Also, by default, there is a web service running that gives unauthenticated access to the Cisco VoIP phones’ network configuration. This too should not be available. Below is the screenshot.
What if an attacker still manages to get access to the network by spoofing the MAC address of a printer? The best practice is to segregate Voice VLAN and Server VLAN. In my case, the organization failed to restrict traffic internally between the two VLANS hence I was able to reach the Server VLAN. The network was completely flat. It stresses the importance of having a firewall in the core layer of the network so as to segregate and restrict traffic going from one VLAN to another.
Vendors could possibly ping the newly connected device on the network. The TTL response could be a good indicator of the host and operating system.
In short, the following mitigations are recommended:
- Lock down access to view network configuration on VoIP phones.
- In case an attacker manages to bypass the NAC; a core firewall in the network will help that restricts traffic from Voice VLAN to Data VLAN. Not all traffic should be trusted from Voice VLAN.
- Disable the web service on VoIP phones to further restrict users to view network configuration.
- There should be a mechanism by the NAC vendors that pings the devices to determine the kind of host that is connected (this technique may be around but may not be known to the NAC administrators).
Cisco also has enhanced their profiling capability citing MAC spoof issue. The details can be found on the below link: