When people talk about Virtual LANs (VLANs), they tend not to focus on the security features of this versatile network topology. However, there are several tangible security vulnerabilities that can increase business risk if they are not properly understood and mitigated. In this article, Redscan’s Simon Heron highlights the ten top threats.
Attacks on VLANs are easier to perpetrate than you might think. And typically, there are several known applications (including yersinia, dsniff and macof) that provide potential attackers with the tools to penetrate VLANs and cause chaos. Easy to find and download from the Internet, these toolsshow people how to exploit badly configured networks and physical weaknesses in the LAN, making it depressingly easy for them to launch a devastating VLAN attack. VLANs are implemented at layer 2 of the OSI network model. The majority of layer 2 (data link layer) attacks exploit the inability of a switch to track an attacker, because the switch has no inherent mechanism to detect that an attack is occurring. This weakness means that this same attacker can perform malicious acts against the network path, altering the path and exploiting the change without detection. While the number of possible attack vectors is large, here is a list of what I believe to be the top ten threats for organisations using VLANs in no particular order.
Discover our award-winning MDR service, ThreatDetect™
1. CAM Table Overflow/Media Access Control (MAC) Attack
This attack focuses on the Content Addressable Memory (CAM) table, which stores information such as MAC addresses on a physical port along with the associated VLAN parameters. CAM tables have a fixed size and that is what makes them a target for attack. Like a buffer overflow attack, the aim is to fill this table up and see what happens. The attacker sits on a physical port and generates a vast number of MAC entries. When the CAM table fills up and has no room left, traffic without a CAM entry is sent out on all ports of the VLAN in question. Traffic with a CAM entry is not affected, but adjacent switches can be. Depending on the switch in question, this type of attack can be mitigated by:
- Specifying the MAC addresses that are allowed to communicate through the physical port
- Limiting the number of MAC addresses for a port.
If an invalid MAC address is found, the MAC address can either be blocked or the port closed down. This prevents the CAM table from being filled up and blocks the attack. Whilst more draconian, it can be argued that closing the port may be the better response as, obviously, something suspicious is happening on that port.
2. Address Resolution Protocol (ARP) attack
ARP was developed at a time when security was not such an issue. Consequently, this protocol has a simple belief that everyone is friendly and responses can be taken at face value. If a host broadcasts an ARP request to the network, it expects only the relevant host to respond. Similarly, if a host announces its presence by sending out a gratuitous ARP, other hosts expect that it is telling the truth and believe what it broadcasts. This, of course, works well until a malicious host appears. In Figure 2, a host starts broadcasting a gratuitous ARP, announcing itself to hold the IP address of the default gateway, 10.3.2.1. PCs, routers and other hosts may cache information gained from gratuitous ARPs for future communications. As a result, anything from a legitimate host will be routed through the malicious host as the default gateway. The attacker then pushes the data to the real default gateway. This will allow the attack to view traffic on the way out of the network but incoming traffic will by-pass the attacker. The attacker now needs to broadcast the address of the host they are trying to target on the LAN to get the default gateway to send the incoming packets to itself before transmitting them to the victim. Now it can see all the traffic incoming and outgoing. One consideration is that without a VLAN, this attacker could affect the entire LAN, so VLANs do mitigate this sort of attack. Another way of mitigating these ‘Man in the Middle’ attacks is to use Private VLANs to force hosts to only talk to the default gateway but this is not always practical.
3. Switch Spoofing/Basic VLAN Hopping Attack
In my previous article on VLANs, ‘The anatomy of a VLAN’ published in Redscan’s July 2013 newsletter, I explained how trunks on switches carry traffic for all VLANs. In Figure 3 below, there are three VLANs, 5, 10 and 15. A VLAN trunk has been configured to allow the two sites to communicate. A malicious host now presents itself to router 1 as another router and attempts to connect by using the appropriate tagging and trunking protocols (e.g. Multiple VLAN Registration Protocol, IEEE 802.1Q, VLAN Trunking Protocol). If successful, then the attacker can see the traffic on all the VLANs and can contact hosts on any of the VLANs. To mitigate this attack vector, organisations should ensure that ports are not set to negotiate trunks automatically and that ports, which are not meant to be trunks, are configured as access ports.
4. Double Tagging/Double Encapsulation VLAN Hopping Attack
This is a development of Switch Spoofing, as many systems are now configured correctly to prevent Switch Spoofing. The exploit this time is to build a packet with two 802.1Q VLAN headers as shown on the left of Figure 4. The first router strips off the first header and sends it on to router 2. Router 2 strips the second header and send the packet to the destination. This attack sends a packet in only one direction, but still gives the attacker access to hosts that should not be accessible. It only works if the trunk has the same native VLAN as the attacker. To mitigate this attack, auto-trunking should be disabled and a dedicated VLAN ID should be used for all trunk ports. Finally, avoid using VLAN 1.
5. VLAN Management Policy Server (VMPS)/ VLAN Query Protocol (VQP) attack
This is a slightly unlikely attack as it requires the network to use VMPS. It is unusual as it imposes a significant load on the administrative resources of a company and Cisco, whose protocol this is, is moving towards 802.1X for the same functionality. However, if implemented, VMPS allows VLANs to be assigned based on the MAC address of the host and these relationships are stored in a database. This database is usually downloaded to the VMPS and then queried using VQP, an unauthenticated protocol that uses UDP (User Datagram Protocol), making it very easy to manipulate by an attacker. As a result, by using VQP, it is very easy to impersonate hosts as there is no authentication, which allows the attacker to join a VLAN that he or she is not authorised to access. The mitigation is to either monitor the network for misbehaviour, send VQP queries out of band or to disable it the protocol.
6. Cisco Discovery Protocol (CDP) Attack
CDP is a feature that allows Cisco devices to exchange information and configure the network to work smoothly together. The information being sent is sensitive, such as IP addresses, router models, software versions and so on. It is all sent in clear text so any attacker sniffing the network is able to see this information and, as it is unauthenticated, it is possible to impersonate another device. The best option is to disable CDP where possible. However, CDP can be useful and, if it can be isolated by not allowing it on user ports, then it can help make the network run more smoothly.
7. Multicast Brute-Force Attack
A multicast brute-force attack searches for failings in the switch software. The attacker tries to exploit any potential vulnerability in a switch, by storming it with multicast frames. As with CAM overflow, the aim is to see if a switch receiving a large amount of layer 2 multicast traffic will “misbehave”. The switch should limit the traffic to its original VLAN, but if the switch does not handle this correctly, frames might leak into other VLANs, if routing connects them. This type of attack is pretty speculative as it looks for the switch to mishandle multicast frames. The switch should contain all the frames within their appropriate broadcast domain and an attack of this nature should not be possible. However, switches have failed to handle this form of attack in the past and hence it is another attack vector.
8. Random Frame-Stress Attack
This type of attack could almost be considered “Fuzzying”(https://www.owasp.org/index.php/Fuzzing), but at layer 2. A large number of packets is generated, randomly varying several fields within each packet and leaving only the source and destination addresses untouched. The aim is to see how the switch software copes with meaningless or unexpected values in packet fields. This type of attack should fail, but obviously bugs do occur which may allow for unexpected access to other VLANs or give rise to denial of service (DoS) attacks.
9. Private VLAN (PVLAN) Attack
PVLANs are used to further divide up groups of hosts at layer 2. For instance a demilitarised zone (DMZ) might have web servers that are accessed by the outside world and a sFTP(Secure File Transfer Protocol) server providing download facilities for staff in the field. There is no reason for these servers to talk to each other and PVLANs will prevent this from happening. Indeed, PVLANs make it very difficult for an infected web server to taint a sFTP server, however, they will only do this at layer 2. PVLANs are not intended or designed to protect against a layer 3 attack. An example is given in Figure 5. An attacker would create a frame with the destination MAC address set to that of the router; the source address can be that of the host he or she is on. At layer 3, the frame has the IP address of the intended victim. The switch will pass this frame to the router as the destination MAC address is that of the router. The router will then forward the frame to the victim as the IP address is valid. With this attack, packets can only be sent. The return frames will have the correct addressing and will be blocked. An attack can be mitigated by the using the right ACLs (Access Control List) on the router, preventing the IP addresses on the primary LAN from talking to each other. This means that only those servers in PVLAN1 can talk to each other through the switch, thanks to the PVLAN, but the attacker cannot access servers on PVLAN 1 from PVLAN 2.
10. Spanning Tree Protocol (STP) Attacks
STP is used to maintain loop free network topologies. This is achieved using Bridge Protocol Data Units (BPDU) which are very simple packets with no payload. By using BPDUs, a switch is chosen as the Root Bridge which then defines how traffic is routed round the network. In such an exchange, it can take around 30seconds to establish which switch is to be the Root Bridge. An attacker has two options. One is to repeatedly send Topology Change Notification (TCN) messages to disrupt the system’s current understanding of the network and force renegotiation of the Root Bridge, resulting in a DoS attack. An alternative is to send a specially crafted BPDU to try and become the Root Bridge. Once this is done, then it is possible for the attacker to see packets that are not intended forhim/her. This is not trivial and requires for the attacker to stay connected to two switches, running bridging software, so that he/she can advertise as a priority zero bridge. Prevention of STP attacks can be achieved by using features like BPDU guard on Cisco products, which enforce the selection of the Root Bridge.
Note: new conclusion Despite the scale and variety of VLAN threats – and their potentially devastating impact on networks – they can all be effectively mitigated through the combination of good network management practices, effective network design and the application of advanced security products. VLANs can be secure, and organisations should not be perturbed from deploying them because of the threats; rather they should deploy them wisely to mitigate the threats.
This article is the second in a series of articles on the topic of VLANs. The third article provides a highly valuable insight into industry best practices for enhancing VLANsecurity. If you would like further information now about how to improve the security of your VLAN installation, contact Redscan on: info@redscan.com.
Discover our award-winning MDR service, ThreatDetect™
