ARP stands for Address Resolution Protocol which is used in network communications. ARPs translate Internet Protocol (IP) addresses into MAC addresses and vice versa. When ARPs find matches between IP and MAC addresses, the result is a successful connection to the internet. To make things run smoother and quicker, some applications are configured with the ability to cache ARPs along with their matching IP and MAC addresses. If there is no known match, the application can send out an ARP request packet in an attempt to find the corresponding addresses.
What is ARP Poisoning?
ARPs were designed for connection purposes and therefore lack security. There is no verification process of ARPs and therefore no way to tell if they are coming from a legitimate or corrupted source. Applications will accept ARP responses the majority of the time, even if they have never sent out a prior request. This lack of security leaves room for ARP poisoning, where attackers can intercept and tamper with communications. ARP poisoning, or ARP spoofing, is a type of man-in-the-middle (MITM) attack where a bad actor situates themselves in the middle of all communications between the application and network. Once access is granted, all devices within the application's network will accept this new ARP/IP pairing, updating the cache table to accept all communications with the corrupted ARP.
Consequences of ARP Poisoning
Once attackers have access to the system via ARP poisoning, they can roam around freely, intercepting all communications between the network and the application. Once access is gained, attackers can launch other serious application attacks that include:
Distributed Denial-of-Service (DDoS) Attacks
A distributed denial-of-service (DDoS) attack is used to overwhelm a system. Because ARPs provide connections between networks using IP and MAC addresses, attackers can manipulate them into communicating with the system they wish to attack. Sending numerous IP addresses to one application at one time essentially crashes the system, bombarding it with traffic that it cannot keep up with.
Session Hijacking Attacks
Because attackers have the ability to intercept and observe all network communications, they can capture the session ID. Session IDs are used in network communications, holding onto verifications and user credentials from application to application. If attackers intercept the session ID after gaining access into the network via ARP poisoning, they can easily gain access to other accounts in which the user is still authenticated—executing a successful session hijacking attack.
SQL Injection Attacks
ARP poisoning gives cyber criminals an access point into the application. Once access is granted, they can manipulate requests and alter communications, launching an SQL injection attack. In this type of application attack, bad actors can insert malicious code into the database of the application, which allows for corrupted requests. This gives bad actors the power to alter HTTP requests or even completely alter the entire HTML page.
How To Detect an ARP Cache Poisoning
Detection of an ARP poisoning attack is challenging. Because there is no verification process as APRs are passed from the application to the network and automatically cached and updated on ARP tables, constant monitoring is key. One telling sign that ARP spoofing is taking place is when two IP addresses match with the same MAC address. This means that one is corrupted and the other is legitimate; however, it is not so easy to detect. Known methods of detection include:
Constant Monitoring of the ARP Cache Table
The ARP cache table is constantly updated as users connect with different applications and corresponding information is saved for future logins. Keeping this table under surveillance checks for any suspicious activity when items in the table are altered or changed. When monitoring ARP cache tables, static entries require the most attention, as these are manually entered and remain until they are manually removed.
Legacy Scanning Approaches in Development
To get a better idea of the health of an application before deployment, many application security teams run a vulnerability scan using legacy static application security testing (SAST), searching for vulnerabilities that could lead to an application attack. However, one of the challenges of legacy SAST tools is the high volume of false positives they generate, which consumes valuable time on the part of the application security team to triage and diagnose.
Another way in which application security teams find ARP poisoning vulnerabilities is through dynamic application security testing (DAST), which often helps identify weaknesses in an application's runtime. DAST stages an ARP spoofing attack, which observes how an application behaves in order to tweak security methods before deployment. DAST tools help developers understand the application’s line of protection better, but they are prone to errors and often miss vulnerabilities (false negatives) while also generating false positives.
Application Security Instrumentation
The challenge with legacy application security scanning approaches is that they approach security from the outside-in. Instead, a different approach that embeds security within applications using instrumentation is needed. When applications and application programming interfaces (APIs) are exercised in runtime, developers receive alerts within their IDE and continuous integration/continuous deployment (CI/CD) pipelines. Specialized application security experts are no longer needed to run tedious vulnerability scans and to interpret their results, flagging vulnerabilities and passing them back to development teams. Additionally, security instrumentation is continuous and in real time, which virtually eliminates false positives. This reduces the risk ARP poisoning poses.
Stopping and Preventing ARP Poisoning Attacks
Early detection of application vulnerabilities is the most aggressive approach to the prevention of ARP poisoning attacks. ARP vulnerabilities are directly caused by the lack of security with ARPs, unable to verify responses and allowing the acceptance of ARP responses without any prior request. Prevention of an ARP spoofing attack starts with a look at the application’s line of defense, observing if it can stand up to more serious attacks that result from ARP vulnerabilities.
Preventing ARP Poisoning by Packet Filtering with Web Application Firewalls
Packet filtering works to monitor traffic between networks and applications. Using packet filtering to check IP addresses, applications can either block or allow access depending on configured restrictions. When an ARP filtering packet identifies an IP address that conflicts with source information, it blocks access to the device. The construction and design of a web application firewall (WAF) that filters packets take time and lots of testing. Developers must first identify vulnerabilities and then determine their seriousness before configuring a WAF. Once created, more testing is needed to monitor performance and check for other vulnerabilities that may have been missed from initial testing. Packet filtering with WAFs may reduce the number of application attacks. However, WAFs are unable to identify unknown vulnerabilities zero-day exploits because they rely on a signature-based threat engine.
Preventing ARP Poisoning by Using Runtime Application Self-Protection
ARP poisoning can happen anytime, no matter how aggressive an application’s security. That is why equipping applications with a means to monitor, detect, and protect in runtime is crucial. Security instrumentation embeds runtime application self-protection (RASP) directly into code released into production. This extends real-time and continuous security into applications running in production. Instead of monitoring for changes after successful ARP poisoning, RASP enables security operations (SecOps) teams to detect ARP vulnerabilities before they are exploited.
