December 18th, 2002, 05:35 PM
switching attacks and mitigation
First of all just to make my self clear:
I do not intend to give tips to lamers, sorry for that!
I am just following the first site line: Hackers know about the weaknesses in your system. Should'nt you?
The point of that thread is to enlite the lack of security implementation and consideration for ethernet swithing based network!
Many guys think that using private VLAN will secure there system, and I believe it is unpartially false. But it is time to wake up to real !!!
A layer2 attack is hard to achieve from the outside world but a man inside can do disastrous malicious attacks, so the main message is watch your logs and tune your IDS to detect such attacks!
After a good threat leaded few days ago by brandon64_99 Hacking VLANs/Packet Stealth if felt I could write something about VLAN hacking!
I hope that can help!
I hope to get feedback on that one!
Please tell me about attacks and relative mitigation techniques I forgot (and I'm sure did), and I could update that paper. Thanks;
LAYER 2 SWITCHING ATTACKS AND MITIGATION
from Networker, December 2002
This memorandum aims to describe the list of security threats and counter measure that might be identified on an 802.1q ethernet switch based network.
Switch based network are layer 2 networks, this lead to an inside network attack risk.
For the guys who are still using LANE over ATM networks these attacks are achievable as well!!!
2. BASICS LAYER 2 KNOWN ATTACKS
Attacks described below are applicable to any ethernet switch based network and are based on common and basic switching functions.
2.1 CAM OVERFLOW / MAC FLOODING
2.1.1 ETHERNET SWITCHING BASICS
The main difference between HUB and switch is the forwarding of unicast packet. The switch learn about the frames transmitted through its ports and cache information about hosts connected to it.
Information such as MAC addresses available on physical ports with their associated VLAN parameters are stored into the CAM table (Content Addressable Memory).
Let take an example in a private VLAN; 3 hosts A, B & C are connected to 3 differents switched ports. When host A send data to host B through port 1, the switch learn that host A is located on port 1 and cache it into the CAM. If host B never sent a packet, the switch is not able to locate host B and will flood the packet originated by A to all VLAN ports.
When B is replying to A on port 2, the switch learn that host B is located on port 2 and cache it into the CAM. The packet is forwarded to host A on port 1 and host C will not receive that packet.
Next time A sent a packet to host B, it will be exclusively forwarded to port 2 and host C will know nothing about it.
2.1.2 CAM OVERFLOW ATTACK
Because memory is not unlimited, the CAM table has a fixed size. This fact allows the switch to be exploited for sniffing purposes. On some switches, it is possible to bombard the switch with bogus MAC address data. The switch, not knowing how to handle the excess data, will 'fail open'. That is, it will revert to a hub and will broadcast all network frames to all ports.
In 1999, the MACOF tool (MAC OverFlow) had been created for that purpose. It is capable to generate about 155000 ethernet packets per minute with randomized MAC source. As an example CISCO catalyst CAM table size is 131 052 entries.
At this point, one of the more generic network sniffers will work to spy the VLAN segment, the attacker is also able to drive a DoS attack by sending data floods broadcasted over the VLAN slowing down drastically the switch and hosts performances.
It is interesting to note that the CAM is common to all VLAN therefore there are all compromised, if an attacker as access to only one VLAN he will be able to sniff only that one but may DoS the whole network.
Therefore this attack compromise confidentiality and user services on a ethernet switch.
2.1.3 ATTACK MITIGATION
1. Some switches allow to limit the number of MAC addresses learn through a port. If host are directly connected to the switch this function will surely protect the system by limiting the number to a single. In that case the attacker will DoS himself by driving such an attack. If a hub is connected to the switch all users using that very hub may be DoSed.
2. Most switches implement port security functions based on static MAC adresses. But this procedure is very heavy as a management point of view. Even more is users are mobile in the network.
2.2 ARP SPOOFING
One of the basic operations of the Ethernet protocol revolves around ARP (Address Resolution Protocol) requests and replies. In general, when Node A wants to communicate with Node C on the network, it sends an ARP request. Node C will send an ARP reply which will include the MAC address. Even in a switched environment, this initial ARP request is sent in a broadcast manner.
It is possible for Node B to craft and send an unsolicited, fake ARP reply to Node A. This fake ARP reply will specify that Node B has the MAC address of Node C. Node A will unwittingly send the traffic to Node B since it professes to have the intended MAC address.
Some available tools are specialized for sending fake ARP replies to classes of machines (i.e., NFS servers, HTTP servers, etc). One such tool is dsniff and it works well to sniff for specific types of traffic. Other tools listen for the general ARP request and send the fake ARP reply at that time.
The parasite program falls into this category and it serves well to sniff the entire network. For this type of attack to work, we need the ability to forward on the frames we receive to their intended host. This is most commonly achieved through some type of IP forwarding, either at the kernel or application level.
2.2.2 ARP SPOOFING FOR SNIFFING PURPOSES
An attacker may compromise the confidentiality of IP connections transmitted on the VLAN he is connected to by sniffing data transfer avoiding been detected. As an example the ethernet target spoofed may be the gateway (e.g. routeur).
The attacker spoof the routeur MAC address by either sending a gratuitous ARP saying that packet to the outside world should be forwarded to the attacker MAC address. Note that IP duplication may alert the administrator but ARP request transmitted by a router are very few because the ARP caching time for such device may be huge (e.g. 8 hours for default CISCO router configuration)
Then all packets originated by a local victim is forwarded to the attacker machine. In order to be undetectable the attacker shall re forward those packet to the real routeur otherwise the outside world connectivity is denied.
The attacker machine behaves like a proxy and provides a half-duplex sniffer for the whole VLAN segment.
In the case of the attacker is willing to sniff a specific host in a full-duplex manner he can use exactly the same technique for spoofing the victim, therefore data exchange from outside world to the victim may be sniffed in both directions.
2.2.3 ARP SPOOFING FOR ANONYMITY AND DOS PURPOSES
ARP spoofing may be use in a different way in order to receive data to a victim usurping its addresses.
If the victim is a host then the attacker will be able to appear like the victim and receive data such as e-mail or database resulting in Denial of Service for the victim, a lack of confidentiality and anonymity for the attacker (because he is usurping the victim network characteristics).
In order to avoid IP address duplication between the attacker machine and the victim, the victim host may be DoSed.
If the victim is the routeur; outside connectivity will be denied for the whole VLAN segment.
2.2.4 ATTACK MITIGATION
There is no real solution to mitigate that attack but it can be detected thanks to Intrusion Detection System (IDS).
2.3 MAC DUPLICATING
It's not difficult to imagine that, since all frames on the network are routed based on their MAC address, that the ability to impersonate another host would work to our advantage. That's just what MAC duplicating does. You reconfigure Node B to have the same MAC address as the machine whose traffic you're trying to sniff. This is easy to do.
This differs from ARP Spoofing because, in ARP Spoofing, we are 'confusing' the host by poisoning it's ARP cache. In a MAC Duplicating attack, we actually confuse the switch itself into thinking two ports have the same MAC address.
2.4 VLAN HOPPING ATTACK
This attack highly depends on platform implementation. The idea is to send data from a user port with 802.1q encapsulation, please note that the port is not a trunk and should transmit only 802.3 or EthernetII frames.
Doing that on a single switch whatever the VLAN ID used the frame will never be forwarded to destination. But in a multiple switch configuration a trunk implementation may be exploit. Trunk ports may be set implicitly to a VLAN_ID (CISCO default native VLAN for trunk is VLAN 1). Therefore when a user port send a packet to a destination located into a distant switch and that very packet is encapsulated into 802.1q format with the native VLAN ID, it will be forwarded to the distant switch.
In order to achieve this attack:
- the attacker shall know what the victim MAC address and VLAN.
- the attacker must belongs to the trunk native VLAN
- The packet need a double encapsulation to reach the victim, the first one is based on the native VLAN the second on the victim VLAN.
Thanks to that attack a unidirectional malicious stream may be generated to the victim from the attacker. It is a blind attack similar to IP spoofing attack.
2.4.2 ATTACK MITIGATION
The trunk native VLAN must be identified and other port than trunk port shall be removed from that one.
3. ADVANCED LAYER 2 KNOWN ATTACKS
3.1 SPANNING TREE ATTACK
The goal of this attack is to sniff traffic on the backbone but interesting hosts located on distant switches and have static ARP entries to prevent against ARP spoofing attack.
The STP (Spanning Tree Protocol) attack idea is to fool a network composed by several ethernet switches by force all switches to forward packets to the attacker machine.
In order to do that the Attacker sends a BPDU packet advertising a priority zero bridge (root bridge) to the switch he is connected to. Therefore traffic that should normally go through a distant link are transmitted across the attacker local switch. Then thanks to the CAM overflow attack he may sniff distant data (cf. figure).
3.1.2 ATTACK MITIGATION
Spanning tree functions must be disabled on all user interfaces but maintained for Network to Network Interfaces to avoid loop.
3.2 VIRTUAL TRUNK PROTOCOL ATTACK
VTP is a protocol used to distribute VLAN configuration among switches aver trunk port, if an attacker becomes a trunk port he could use that protocol to configure at will the whole network. For instance he might send VTP messages faking to be a VTP server with no with no VLAN configured, as a result all VLAN configured with VTP will be deleted across the entire VTP domain. That's a huge DoS attack.
3.2.2 ATTACK MITIGATION
Don't use VTP!
3.3 VMPS ATTACK
The aim of VLAN Management Policy Server is to assign dynamically VLAN basing on MAC address, IP address or HTTP authentication (URT). VMPS is centralizing host information in a database which is downloaded to servers via TFTP. VMPS uses VLAN Query Protocol (VQP) for client/server exchanges which is unauthenticated and runs over UDP.
All VMPS traffic is in clear text, unauthenticated and over UDP, therefore that protocol may be easily misused for hijacking purposes.
3.3.2 ATTACK MITIGATION
VMPS traffic shall be transmitted on a Out Of Band basis (user traffic separate network) or not used.
3.4 DHCP STARVATION ATTACK
Using the MAC overflow attack an attacker is able to DoS the network by requesting all of the available DHCP adresses.
3.4.2 ATTACK MITIGATION
Same counter measure than for MAC overflow attack.
3.5 DHCP ROGUE ATTACK
The attacker could turn its machine to a rogue DHCP server and provide address to the VLAN clients. DHCP server assigns IP address as well as default gateway address and DNS address. Therefore, the attacker may force all traffic to go through its own machine (by assigning the default gateway as its own address) for sniffing purpose.
3.5.2 ATTACK MITIGATION
There is no real mitigation known. RFC 3118 "Authentication for DHCP messages " should help but is not widely implemented by DHCP servers.
[shadow] SHARING KNOWLEDGE[/shadow]