Analyzing ARP to Discover & Exploit Stale Network Address Configurations
Introduction
In penetration testing, ARP is most commonly discussed in terms of poisoning attacks where an attacker achieves a man-in-the-middle (MITM) position between victim nodes by contaminating the ARP cache tables of neighboring hosts. While initially inspired by this technique and the desire to derive a means of passively obtaining a list of candidate targets, this post aims to look at ARP from a data analytics perspective by capturing and quantifying broadcast requests to identify intercommunicating network hosts.
The byproduct of this effort is a simple Python tool for Debian Linux called eavesarp that was heavily influenced by Jaime Penalba’s netdiscover, which passively monitors for ARP requests and presents a table summarizing the sender, targets, and sum of ARP requests for each sender-target combination. Such information is key when plotting targeted ARP poisoning attacks and identifying stale network address configurations (SNACs), the latter being a misconfiguration that occurs when a client for a network service has been configured with a hardcoded IP address or FQDN that is no longer associated with a live host. eavesarp builds on the capabilities of netdiscover by providing active discovery of SNACs, while also providing DNS name resolution capabilities.
If the reader is comfortable with the brief introduction above, feel free to jump to the section titled Exploiting SNACs for the practical bits. Otherwise, the following subsections of this introduction will provide a bare-minimum summary of how ARP operates along with contextual information explaining why this came about.
A Brief Word Regarding the Address Resolution Protocol (ARP)
ARP is a protocol used to resolve the MAC address for the NIC that has been configured with a given IP address. Requests are sent across the network in clear text such that any member of broadcast domain can observe and record them. There are countless articles on how to exploit weaknesses in ARP so this post will not discuss them at length, but glancing at the abstract in RFC 826 does provide basic terminology and insight used throughout the remainder of this post:
- sending host (sender) – The host that wants to interact with another host (target). This is the host that is requesting the MAC address associated with a known IP address.
- target host (target) – The destination host that the sender wishes to interact with. This is the owner of the MAC address associated with the IP address known by the sender.
Also keep in mind that only ARP requests are broadcasted, not replies, so it isn’t possible to determine if a reply from the target is received without making an ARP request for the target or observing the response via MITM attack.
Contextual Babble
During a recent engagement with BHIS, a client deployed a Kali-based host on an internal network segment to support testing. Minimal NetBIOS/LLMNR traffic was observed in the environment and attempts to exploit the broadcast nature of this traffic using Responder failed to capture weak password hashes. Additionally, relay attacks were ineffective due to proper enforcement of SMB signing on high-value hosts. Using MailSniper to verify usernames obtained via OSINT techniques and BruteLoops, a horizontal brute force attack using common passwords was performed but failed to yield valid credentials. Given that no glaring vulnerabilities on distinct applications and services were identified, the author elected to perform targeted ARP poisoning attacks to harvest hashes and other information. The issue quickly became identifying which hosts to target for poisoning while minimizing impact to network conditions.
As any rational assessor will attest, ARP poisoning attacks are as perilous as powerful: even a minor error while configuring the attack can result in denial of service (DoS) conditions. Consideration that this phase of the engagement was executed remotely, the author cannot stress the word ‘targeted’ enough.
What does targeted mean in the context of ARP poisoning? From the author’s perspective, the ideal MITM positioning is to become an intermediary node between the switch and client hosts known to interact with server hosts offering high-value services — but not all of them simultaneously since the level of network traffic sent to the attacking node increases with each victim, thereby resulting in elevated odds of introducing DoS conditions. This “MITM-the-client approach” painstaking, but prudent when victim hosts are user workstations since an accidental DoS to a select number of workstations is preferable to a server hosting services that may be mission critical to the client environment.
But how can one go about identifying which hosts are interacting with one another on a network from an unauthenticated context?
Though unable to know with absolute certainty that a given client is a consumer to the desired application-layer service offered by the server, monitoring broadcasted ARP requests reveals which hosts attempt to resolve the MAC address for servers at the link layer. Collecting and analyzing these requests over time unveils interesting relationships between hosts relative to network connections.
To be concise, I desired a tool that performed the following functions:
- Monitors a network interface for broadcasted ARP requests
- Tracks the sender and target for each request
- Maintains a count of how often a given sender requests a target
Although the author was unaware at the time of the engagement, netdiscover performs each of these functions and presents the analyzed data in a nice interactive interface. However, take note of the top record where the IP (.3) has requested the MAC address of .7 one hundred and sixty-one times (161). This is a key indicator of a SNAC. eavesarp builds on this concept by providing active verification of SNACs and providing DNS capabilities.
From this point onward, this post will focus on describing, detecting, and exploiting SNACs. Given the appropriate conditions, this misconfiguration can be leveraged to achieve a MITM position between clients and services with minimal likelihood of degrading operational capabilities of the client environment.
Stale Network Address Configurations (SNACs)
A SNAC (pronounced “snack”) occurs when the client for a network service has been configured with a static address value but no response is received when an ARP request is broadcasted to resolve the target MAC address, indicating that no host is currently configured with that IP address. This event can occur for various reasons, such as when DHCP issues a different address to the original host or if the original host has gone offline since the client was configured. Repetitive ARP broadcasts from a sender for a single target within a small window of time is a strong indicator of a SNAC since ARP responses are cached after receiving a valid reply from a given target.
While events leading to an address configuration going stale are quite common, such a configuration can be exploited to achieve interesting ends. If the transport protocol for the service happens to be cleartext UDP then it’s possible to capture traffic in transit by merely assuming the IP address of the stale configuration and sniffing traffic from the appropriate interface. Setting a second IP for a NIC is a trivial task given proper network conditions allowing one to alias a given NIC with multiple IPs (See the section titled IP Aliasing).
Exploiting SNACs when confronted with connection-oriented protocols presents an interesting situation since a connection must be established before the attacking host will receive any data beyond connection information. However, it’s possible to work around this issue by capturing network traffic from an intercepting interface, determine common ports the vulnerable client/host is attempting to access and then bring a TCP listener online to accept the connection and initial data. This allows one to determine the higher-layer protocol by using the initial payload as a fingerprint. The final section of Exploiting SNACs (Services Using TCP as a Transport) demonstrates a potential MITM scenario that handles TCP oriented protocols by enabling IP masquerading on the attacking host.
Before jumping into exploitation of SNACs, two additional sections are provided to illustrate use of eavesarp and how to alias network interfaces on Linux and Windows hosts.
SNAC Detection Using Eavesarp
Basic usage of eavesarp is discussed here. All results were gathered from a reasonably small network where development took place. A single host has been intentionally configured to act as a SNAC (.2) targeting .101 as the stale address, which is why there is at least one target that will always have a glaringly larger count of ARP requests.
Starting eavesarp in passive mode (default) while specifying the proper NIC results in a basic table being returned unveiling that sender .2 is requesting the MAC of target .101 much more frequently than any other target in the broadcast domain. This is the indicator described in Stale Network Address Configurations (SNACs).
Note in the image above that output is sorted by the sender generating the greatest number of ARP requests in a descending fashion, as are the corresponding targets associated with that sender. This is intended to facilitate quick identification of senders affected by SNACs. Also observe that the records are blocked by color while printing the sender address only a single time per block, making the output easier to digest by eliminating the duplicate sender values. If MAC addresses are desired, use the -oc (–output-columns) option to specify which values to display.
Basic execution of eavesarp is passive because only broadcasted ARP requests are captured and analyzed. The MAC for .3 is set to ‘[UNRESOLVED]’ above because no ARP requests from that IP has been received as a sender — only a target.
Active checks can be configured as well, which will confirm if a given configuration is stale by making an ARP request for the target observed in a broadcasted request. DNS resolution can be enabled to perform reverse name resolution for both the sender and target address, providing PTR record values. This is useful in situations where hostnames are descriptive and may help make ARP poisoning attacks more targeted. The following image shows a continuation of the previous capture with these capabilities enabled. Emojis present in the stale column indicates a SNAC.
The final column intends to communicate if the target IP is different than the forward IP associated with the target PTR, which may indicate that the stale configuration is intended for the host that now owns the forward IP. In this scenario, it may be possible to enable IP forwarding on the attacking host, assume the IP of the stale configuration, and then become a man-in-the-middle for the intended host that owns the forward IP by rewriting packets at the IP/TCP layer. Given use of cleartext protocols between the sender and legitimate host, this can result in capture/modification/relay of sensitive information in transit. This is the premise of the section titled Services Using TCP as a Transport in the Exploiting SNACs section.
While this capability is only aesthetic, the user can always specify a color profile to suit the current mood. The author has been using the foxhound profile because he’s a geek for Metal Gear Solid and it’s a nice throwback to the interface used in Sons of the Patriots. Starting eavesarp while selecting a valid value to pass to the –color-profile option (-cp) results in a change of appearance.
The remainder of this post will now focus on the exploitation of SNACs, starting with a brief overview of how to alias network interfaces with multiple IP addresses.
IP Aliasing
Assigning additional IP addresses to a single NIC is known as IP aliasing. When an ARP request for a target IP assigned to that interface, static or alias, the host will respond with the same MAC address. It is this capability that allows us to abuse SNACs without having to poison the ARP cache of neighboring hosts.
When on a Debian Linux host, the following commands can be executed to add or delete an IP alias to a target interface.
ip a add <ip_address>/<netmask> dev <interface> ip a del <ip_address>/<netmask> dev <interface>
Though slightly more convoluted (as always) this can be applied in Windows as well by first assigning a static IP to the target interface, clicking the ‘Advanced’ Button, and proceeding to add a new configuration via the ‘Add’ button in the ‘Advanced TCP/IP Settings’ window.
Exploiting SNACs
This section details two potential scenarios where exploitation of SNACs is possible. First, a syslog configuration is targeted and represents the simplest of scenarios because the UDP transport requires no connection setup — it effectively “shovels” free data to the aliased interface. The second targets SMB and is somewhat contrived but provides a foundation for targeting TCP protocols.
Services Using UDP as a Transport Protocol
The syslog scenario described above manifested in the environment discussed in the Contextual Babble section. A misconfigured client was configured with a value that resolves to an IP address that cannot be resolved to a MAC using ARP. This client was logging records in clear text that contained artifacts originating from the query string of HTTP requests processed by a web server. These records just so happened to contain cleartext credentials and other sensitive information.
To prevent disclosure of environmental details, the author created a Python script (swisslogger) to replicate this scenario and is available at the first URL below should the reader wish to replicate the attack for experience-building purposes. swisslogger effectively simulates an easily exploitable SNAC vulnerability when configured to point to an unassigned IP address by continuously attempting to send syslog records, in turn producing constant ARP requests.
Below are links to eavesarp and swisslogger:
The following image shows the execution of the swisslogger while setting the IP to a stale value. It simply just begins churning logs out to the address specified in the host parameter.
The following table summarizes the hosts involved at this stage of the demonstration.
| IP Address | Role | Hostname | Notes |
| 192.168.86.2 | sender | iron | This host is vulnerable due to a stale network address configuration via swisslogger. Upon execution, it will begin making consistent ARP requests targeting .101, indicating a SNAC. |
| 192.168.86.5 | attacker | deskjet | This host will run eavesarp to detect the stale configuration applied to .2 and will be used to receive traffic from .2 after assuming the .101 address. This host will respond to any ARP request for .101 after aliasing. |
| 192.168.86.101 | target | syslog | This address is not in use by any host until .5 will be aliased |
Starting eavesarp while specifying the proper NIC reveals that sender .2 is requesting the MAC of target .101 much more frequently than any other target in the broadcast domain. This is the indicator described in Stale Network Address Configurations (SNACs).
Sender .2 appears to be afflicted with a SNAC and target .101 is now suspect of being an unused IP address. It’s possible to verify this observation by whitelisting only .101 using the –target-whitelist flag and enabling ARP resolution (-ar), as shown in the following image (Note that column ordering is optional).
Now is the time to alias the interface. It can be seen in the following images that ARP requests from sender .2 for target .101 halt after aliasing and syslog traffic generated by the swisslogger script is being received. The date command was executed just before implementing the alias in the first image and the timestamp shown in tcpdump capture aligns perfectly.
The syslog example is simple enough that it almost feels fabricated, however dealing with higher layer protocols using TCP as a transport will inherently become more complex because the attacking machine will need to handle connection establishment before receiving meaningful data from the SNAC.
Services Using TCP as a Transport Protocol
As mentioned in the SNAC detection section, eavesarp also supports active ARP and DNS resolution. It begins by enumerating any PTR records for senders and targets, followed by performing forward resolution of recovered PTR values. The following image shows execution of eavesarp while enabling ARP and DNS resolution and applying a whitelist only for the known stale target address (.101).
Observing that PTR records are defined for each host, we can now use the analyze subcommand and take a closer look at the stale target address. The analyze command differs from the capture command by analyzing raw pcap files or SQLIte database files generated by eavesarp, though it should be noted that the same analysis options are available when executed in capture mode.
eavesarp has compared the forward address to the value observed in the initial ARP request and identified dissonance, as communicated in the final column. This may indicate that the true target host has changed IP addresses to the forward value, representing a potential MITM opportunity.
Note: This post is about to take a sharp turn into Fiction City, established in the great state of Creative Liberty. It’s contrived, but it should provide a foundation for future work.
At this point, let’s assume that the neighboring host (.102) is indeed the intended target host needed by the sender (.2) but is currently unable to access it due to the SNAC. Let’s also assume that a network administrator, Karen, has noticed strange ARP behavior originating from the sender and decided to verify the configuration parameters of the syslog client. However, after physically walking to .2 and authenticating (FICTION), she’ll try to access the stale target address over SMB to get additional configuration information before applying any changes.
For clarity, the following table has been updated to reflect the additional upstream host in addition to new configurations:
| IP Address | Role | Hostname | Notes |
| 192.168.86.2 | sender(SNAC) | iron | This host is vulnerable due to a stale network address configuration via swisslogger. Karen will log on here and try to access an upstream SMB share for magic datas on .101 as she is unaware that the address has changed. |
| 192.168.86.101 | target | syslog | This address has been aliased to the interface of .5, the attacking host. |
| 192.168.86.5 | attacker | deskjet | This host has been aliased with .101 and will be configured with firewall rules to support IP masquerading (nat). |
| 192.168.86.102 | intended target | w10 | This is the host that originally had the .101 IP address but has since been changed to .102, resulting in a SNAC. All traffic will now be forwarded to this address via firewall rules. |
As described above, we know that Karen is about to access .101 over SMB to get configuration information because she is unaware that the IP of the intended target has changed to .102. We can handle this situation by borrowing from Laurent Gaffie’s work and enable IPv4 forwarding on the attacking. followed by implementing firewall rules to rewrite packets to be addressed to .102.
sysctl net.ipv4.conf.eth1.forwarding=1 iptables -t nat -A POSTROUTING -o eth1 -j MASQUERADE iptables -t nat -A PREROUTING --dst 192.168.86.101 -j DNAT --to-destination 192.168.86.102
Another tcpdump session is initialized prior to authenticating to .101 from .2 so that traffic can be captured and analyzed, then smbclient can be used to simulate the SMB session initiated by Karen. As elucidated below, Karen has access to the SMB share hosted on the intended target host while mistakenly referencing the stale address identified earlier (.101).
Review of captured traffic using Wireshark shows that hashed credentials were captured as expected and PCredz (more Laurent Gaffie wizardry) can be used to dump them from the capture file for offline dictionary-based brute force attacks.
http://g-laurent.blogspot.com/2016/10/introducing-responder-multirelay-10.html
Conclusion
Detection and exploitation of SNACs is a trivial process when operating in an environment where IP aliasing is feasible. Though the proof of concept tool developed to facilitate detection is currently available only for Linux, developing a tool for other operating systems should not represent a great challenge. Impact stemming from exploitation of a SNAC is relative to the type of network traffic originating from the sender, the simplest of which results in capture of arbitrary network traffic that may contain sensitive information.
Blue Recommendations
- Configure network infrastructure to enforce Dynamic ARP Inspection (DAI), a control preventing the use of aliased IP addresses and ARP poisoning attacks by assuring ARP responses are honored only when the MAC to IP binding is present in an authoritative database (simplification)
- Monitor for excessive ARP requests for a specific IP address within an unreasonable timeframe
- Debian hosts cache a given ARP response for 60 seconds by default. This configuration can be inspected/configured by interacting with the following file:
- /proc/sys/net/ipv4/neigh/default/gc_stale_time
- Newer versions of Windows generate a value upon successful resolution but are marked “stale” if not used again between 15 and 45 seconds
- Debian hosts cache a given ARP response for 60 seconds by default. This configuration can be inspected/configured by interacting with the following file:
- Monitor for invalid DNS records that point to abandoned IPs since clients may be configured with the friendly value, resulting in SNAC
- Though not tested, LaBrea (as recommended by @strandjs) should prevent detection and exploitation of SNACs by tarpitting hosts that exhibit SNAC behavior
Ready to learn more?
Level up your skills with affordable classes from Antisyphon!
Available live/virtual and on-demand
