Today's article is about the topic of ARP (Address Resolution Protocol) and the possible attack vectors in this context.
With ARP spoofing, an attacker sends ARP response packets to selected network participants and thus changes their ARP table in order to be able to read and possibly manipulate all network traffic.
The Address Resolution Protocol is used in broadcast domains to assign the appropriate IPv4 address to MAC addresses. The assignment is stored locally in an ARP table for the respective network participant.
The problem with the Address Resolution Protocol lies in the ARP request and the ARP response. With ARP spoofing, an attacker floods the ARP tables of all network participants using fake ARP replies. If a network participant now wants to establish a connection to the server, for example, he first looks in his ARP table to see whether a MAC address is stored for the IP address of the server. Since every IP address in the client's ARP table points to the attacker's MAC address, the connection is not established to the server but to the attacker.
For a classic man-in-the-middle attack, the attacker simply forwards the incoming requests and can read and possibly manipulate the network traffic. He acts as a kind of transparent proxy.
The tools Ettercap and Bettercap, among others, can be used for the man-in-the-middle attack. This example uses Bettercap in the console and Ettercap as an alternative with a graphical user interface.
In the example shown, client A (192.168.1.3) communicates with client B (192.168.1.2) and the attacker (192.168.1.5) executes a man-in-the-middle attack using ARP spoofing. It is shown how the attacker can record network traffic. The login of the client on the website hosted by the server is also recorded, the authentication is HTTP basic authentication.
Man in the Middle Attack with GUI:
The following steps are carried out:
1. Start the Ettercap program.
2. Select “Accept” in the bar at the top right.
3. Hosts can be found in the network via ARP using the magnifying glass at the top left and are then displayed in the host list (to the right of the magnifying glass).
4. With the “MITM Menu” button you can select “ARP spoofing” from the drop-down menu.
5. If unencrypted data is now sent from a spoofed client, the login data entered, for example, is displayed in the lower part of the window.
To run Bettercap in the console, we used the following command:
timeout 60 bettercap -iface eth0 -eval "set http.proxy.sslstrip true; set net.sniff.verbose true; set net.sniff.output /root/mitm.pcap; set arp.spoof.fullduplex true; arp.spoof.internal true; net.recon on; net.probe on; arp.spoof on; http.proxy on; net.sniff on"
timeout
With the addition timeout the duration of the man-in-the-middle attack can be specified.
This is particularly advantageous in extensive networks if the system used for the attack hangs and the attack can no longer be stopped manually.
iface
Here you can select the interface to be used for the attack.
eval
With this flag, a string of settings can be passed to Bettercap directly at startup, so that they don't have to be set manually, one after the other.
net.sniff on
This module is a network packet sniffer and fuzzer that supports both BPF syntax and regular expression filtering. It is also capable of dissecting several important logs to gather credentials.
http.proxy on
A full-fledged transparent HTTP proxy that can be programmed with Javascript modules. When used in conjunction with a spoofer, all HTTP traffic will be redirected to it and port redirects will be performed automatically as needed.
arp.spoof on
This module spoofs selected hosts on the network with spoofed ARP packets to perform a MITM attack.
net.probe on
When enabled, this module sends different types of probe packets to each IP address in the current subnet for the net.recon module to detect.
net.recon on
This module is responsible for periodically reading the system's ARP table to detect new hosts on the network.
arp.spoof.fullduplex on
If set to true, both the targets and the gateway will be attacked, otherwise only the target (however, if the router has ARP spoofing protection, the attack will fail).
net.sniff.output
If this option is set, the sniffer writes the captured packets to this pcap file.
net.sniff.verbose
If set to true, every captured and analyzed packet will be sent to the events.stream for viewing, otherwise only the packets analyzed on the application layer (sni, http, etc.).
http.proxy.sslstrip
Enable or disable SSL stripping.
In order to "strip" the SSL, an attacker intercepts the redirection of the HTTP to the secure HTTPS protocol and intercepts a user's request to the server. ... With an SSL strip, the attacker forwards the victim's request to the server of the online shop, for example, and receives the secure HTTPS payment page.
arp.spoof.internal
If set to “true”, local connections between computers on the same subnet will also be forged, otherwise only connections that are routed out of the subnet via the entered gateway (in the case of a full duplex attack, the packets from the gateway to the clients will also be forged directed the attacker).
Attached is a screen of the PCAP file generated by Bettercap, in which you can find the Basic-Auth.
In order to be able to detect and prevent the attack, a service that is available in most networks is used: the DHCP server.
The DHCP server has an overview of all dynamically assigned IP addresses (and their MAC addresses) in the network. In connection with the defense and detection of ARP spoofing attacks, it becomes clear why static IP addresses should also be maintained using the DHCP server.
In order not to have to access the data of the DHCP server directly, some switches offer a functionality that we use to defend against ARP spoofing.
DHCP snooping is a functionality designed to prevent DHCP attacks.
With DHCP snooping, “trusted ports” are configured on switches from which DHCP offers are accepted. The DHCP server is connected to one of these “trusted ports”, as this is the only one that should dynamically assign IP addresses. Trunk ports must also have the “trusted” status in the context of DHCP snooping, as valid DHCP offers are transmitted here. If the switch detects that a DHCP offer is taking place via another port, it drops the packet.
A side effect of DHCP snooping is the DHCP snooping database in which all IP and MAC addresses that were assigned by the DHCP server on the “Trusted Port” are noted.
Attached is the link to Cisco's explanation/configuration: DHCP snooping
configure terminal
ip dhcp snooping vlan
interface
ip dhcp snooping trust
exit
The dynamic ARP inspection is now used to discard traffic from IP/MAC address combinations that are not in the DHCP snooping database.
If an attacker were to carry out an ARP spoof attack, the switch would determine that ARP packets were being sent to the subnet at the port that did not match the information from the DHCP snooping table and would then discard these packets. If a rate limit for ARP packets is also configured on the respective interface, the interface would be deactivated if the limit was exceeded.
configure terminal
ip arp inspection vlan
interface
ip arp inspection trust
exit
In the above example of DHCP Snooping in conjunction with Dynamic ARP Inspection, only dynamically assigned DHCP leases are initially taken into account. Of course, it often happens that systems are configured with static IP addresses. On the one hand, it is possible to distribute “fixed” IPs via IP reservations through the DHCP server. This has the advantage that these “statically” assigned IP addresses via DHCP also appear in the DHCP snooping table and the DAI therefore also works here. Dynamic ARP inspection does not work for manually assigned static IP addresses. However, there is almost always the possibility of configuring ARP ACLs (Access Control Lists) on the switch, which are also used for static IPs. These ARP ACLs have priority over the DAI check.
In the example shown, the DHCP snooping database is stored and used on the switch. In large infrastructures, switches quickly reach their resource limits. For this purpose, the DHCP snooping database can be stored centrally on a FTP/TFTP server at Cisco, for example, and made available to every switch. It is important to ensure that the management ports of the switches and the FTP/TFTP server are placed in their own separate network area so that not every client has access to them.
Since the attack is only based on broadcast traffic, an elegant solution is client isolation. Clients can be separated from each other via private VLANs and the broadcast traffic cannot simply be read and manipulated by an attacker in the network.
With host-based detection, the overview of all IP addresses on the DHCP server is used. The overview of the IP addresses can be made available to the clients on a share, for example.
In order to detect an ARP spoofing attack, the clients must automatically check their ARP table at regular intervals using the DHCP overview to identify any irregularities. If irregularities are found, they can be output to a file and checked, for example with the help of OSSEC.
The Network IDS solution is also based on a list from the DHCP server that contains all known IP and MAC addresses. Using tools like Snort - an IPS/IDS - IDS rules can be written that compare known MAC addresses to the MAC addresses of the incoming connections and report if mismatches are detected. Depending on the configuration, IPS rules can now block IP addresses or carry out further steps.
An ARP spoof attack can also be detected by defending it with DHCP snooping and dynamic ARP inspection. For this purpose, the switches can be connected to a monitoring system via SNMP, for example, and you can see a thwarted attack.
Switches should switch off the responsible port when ARP spoofing is detected via Dynamic ARP Inspection. Any error messages from the switches can be monitored via SNMP (Simple Network Management Protocol).
The offending device should be isolated and examined for compromise.
When dealing with the following ISMS framework controls, the vulnerability and how to fix it plays a role:
ISO 27001:
A. 9.1.2 Access to Networks and Network Services
A.13.1.2 Security of Network Services
BSI Baseline Protection:
NET.1.1.A7
@ font-face
{font-family: "Cambria Math";
panose-1: 2 4 5 3 5 4 6 3 2 4;
mso-font-charset: 0;
mso-generic-font-family: novel;
mso-font-pitch: variable;
mso-font-signature:3 0 0 0 1 0;}@font-face
{font-family: Calibri;
panose-1: 2 15 5 2 2 2 4 3 2 4;
mso-font-charset: 0;
mso-generic-font-family: swiss;
mso-font-pitch: variable;
mso-font-signature:-469750017 -1073732485 9 0 511 0;}@font-face
{font-family:”Helvetica Neue”;
panose-1: 2 0 5 3 0 0 0 2 0 4;
mso-font-charset: 0;
mso-generic-font-family:auto;
mso-font-pitch: variable;
mso-font-signature:-452984065 1342208475 16 0 1 0;}p.MsoNormal, left.MsoNormal, div.MsoNormal
{mso-style-unhide: no;
mso-style-qformat: yes;
mso-style-parent: "";
margin: 0cm;
mso-pagination: widow-orphan;
font-size: 12.0pt;
font-family: “Times New Roman”, serif;
mso-fareast-font-family:”Times New Roman”;}p.li1, li.li1, div.li1
{mso-style-name:li1;
mso-style-unhide:no;
margin: 0cm;
mso-pagination: widow-orphan;
font-size: 10.0pt;
font-family:”Helvetica Neue”;
mso-fareast-font-family: Calibri;
mso-fareast-theme-font: minor-latin;
mso-bidi-font-family:Calibri;}.MsoChpDefault
{mso-style-type: export-only;
mso-default-props: yes;
font-family: "Calibri", sans-serif;
mso-ascii-font-family: Calibri;
mso-ascii-theme-font: minor-latin;
mso-fareast-font-family: Calibri;
mso-fareast-theme-font: minor-latin;
mso-hansi-font-family: Calibri;
mso-hansi-theme-font: minor-latin;
mso-bidi-font-family:”Times New Roman”;
mso-bidi-theme-font: minor-bidi;
mso-fareast-language:EN-US;}div.WordSection1
{page: WordSection1; {
There is an entry in the MITER ATT&CK framework for the vulnerability:
Attack.mitre.org
The vulnerability is described under the following CVE:
CVE-1999-0667
PSN ID: PS-TN-2020-0001
