Top 20 CIS Critical Security Controls (CSC) Through the Eyes of a Hacker – CSC 11

In this blog series members of Optiv's attack and penetration team are covering the top 20 Center for Internet Security (CIS) Critical Security Controls (CSC), showing an attack example and explaining how the control could have prevented the attack from being successful. Please read previous posts covering:

• CSC 1: Inventory of Authorized and Unauthorized Devices
• CSC 2: Inventory of Authorized and Unauthorized Software
• CSC 3: Secure Configurations for Hardware and Software on Mobile Devices, Laptops, Workstations, and Servers
• CSC 4: Continuous Vulnerability Assessment and Remediation
• CSC 5: Controlled Use of Administrative Privileges
• CSC 6: Maintenance, Monitoring, and Analysis of Audit Logs
• CSC 7: Email and Web Browser Protections
• CSC 8: Malware Defenses
• CSC 9: Limitation and Control of Network Ports, Protocols and Services
• CSC 10: Data Recovery Capability

CSC 11: Secure Configurations for Network Devices such as Firewalls, Routers, and Switches

The Control

Establish, implement, and actively manage (track, report on, correct) the security configuration of network infrastructure devices using a rigorous configuration management and change control process in order to prevent attackers from exploiting vulnerable services and settings.

The Attack

In many cases the default configurations present on devices are there to facilitate setup and interoperability - to get systems communicating with the minimum amount of configuration. In a lab environment, it's a boon to be able to connect devices to a switch and just have them communicate. In a production environment however, many of the default settings can have serious negative impacts on the security posture of the environment as a whole. In our example, we’ll illustrate how an unhardened switch configuration can provide an attacker with an opportunity to perform a VLAN hopping attack, by exploiting the Dynamic Trunking Protocols (“DTP”).

Our attack begins with a go-to process that I always make use of when I gain access to a new network, passive traffic capture and analysis. Initially, we'll capture packets and attempt to identify interesting network traffic, while it's certainly not limited to layer 2 frames and broadcast/multicast traffic, this type of traffic very frequently bears fruit. In the Wireshark screenshots below we note two items, 1) we’re connected to port Fa0/1 on our switch and 2) we can see DTP frames being issued by the switch we're connected to. 

Figure 1: CDP frames contain a lot of interesting information, for our purposes, we’ll take note of the fact we’re connected to port Fa0/1

Figure 2: This DTP frame indicates that the switchport is currently acting as a regular access port, and the DTP is set to ‘auto negotiate’

DTP allows for the dynamic negotiation of trunk ports between Cisco switches. In a lab environment, DTP can be used in conjunction with the VLAN Trunking Protocol ("VTP") to connect a pair of switches and propagate VLAN information between the devices. In the above screenshot we see that our switchport is currently operating as an access port, and that DTP is configured for auto negotiation.

It’s important to note that for illustrative purposes our sample switch configuration has been simplified; additionally, while an attacker wouldn’t have insight into the configuration, we’ll include relevant output to better illustrate what’s happening on the device. An excerpt from a show vlan command provides the following output:

Figure 3: Output from the show run command; only port Fa0/48 has been assigned to VLAN 3

The takeaway from the above screenshot is that in our example only port Fa0/48 has been assigned to VLAN 3, and none of the other ports on the switch can communicate with the device connected. It’s also worth mentioning here that there isn’t any interVLAN routing configured.

We use the Yersinia tool to spoof DTP frames, and if we're fortunate enough to be connected to a switch that is configured in Dynamic Auto or Dynamic Desirable we form a trunk. 

Figure 4: We use the Yersinia tool to perform our VLAN hopping attack; the output is consistent with what we say in Wireshark

Figure 5: Yersinia output after we’ve issued the DTP frame required to negotiate a trunk

For the curious, post-attack output from a show vlan command does not include our port Fa0/1, as it’s no longer an access port:

Figure 6: Where did interface Fa0/1 go?

Once again, we capture traffic and now that we have a trunk port, take note of frames that have been tagged with VLAN IDs. We load the 8021q Linux kernel module and create subinterfaces for any of the VLANs we want to send traffic on. Using this process we can communicate with any VLANs that our switch has visibility to. In the screenshot below, we create a subinterface for VLAN 3 and can now communicate with the isolated system that was attached to port Fa0/48 in the previous screenshot.

Figure 7: Creating a subinterface in Linux that tags all outgoing frames with VLAN ID 3

In the right (or wrong depending on your perspective) circumstances, the presence of DTP can provide an attacker with the means to execute VLAN hopping attacks. On several occasions, this has provided me with a convenient Network Access Control (NAC) bypass and the ability to gain access to restricted network segments such as management VLANs from a network port that would under normal circumstances only provide me with a captive portal or quarantine network.

The Solution

From a tactical perspective the configuration issue can be remediated by explicitly disabling DTP and setting all interfaces to either access or trunk mode.

A strategic approach to proactively treating these and similarly related configuration issues is the application and adherence to the tenets outlined by CSC 11:

1. Carefully review and evaluate the hardening guidelines that are available for the devices in use in the environment. 
2. Stage out hardened configurations of these devices, and then perform testing against the implementations to ensure they're operation is aligned with expectations. 
3. Create a standard hardened baseline or gold configuration for the relevant devices
4. Manage, and thoroughly vet proposed changes to devices through a formal change control process
5. Once a policy and process is in place to deploy hardened configurations, leverage technical controls to monitor configuration changes and actively reconcile changes against change management records. 

The next post will cover CSC 12: Boundary Defense.