Arp Spoofing in APIs

ARP (Address Resolution Protocol) spoofing is a network-level attack where an attacker sends falsified ARP messages onto a local network. The attacker associates their MAC address with the IP address of a legitimate host (like a gateway or API server), causing traffic meant for that host to be sent to the attacker instead.

ARP is a stateless protocol that doesn't verify whether a response comes from the actual owner of an IP address. When a device sends an ARP request asking "Who has IP 192.168.1.1?", an attacker can reply with their own MAC address, effectively positioning themselves between the victim and the legitimate host. This creates a man-in-the-middle (MITM) position where the attacker can intercept, modify, or drop network traffic.

In API contexts, ARP spoofing allows attackers to intercept API requests and responses, potentially capturing authentication tokens, API keys, sensitive data payloads, or modifying requests before they reach the intended API server. The attack works because ARP doesn't authenticate responses—any device can claim to be any IP address on the local network.

API traffic intercepted through ARP spoofing can lead to severe security breaches. An attacker positioned between a client and API server can capture API keys, JWT tokens, or session cookies from request headers. They can also read sensitive data in request bodies (like PII, financial information, or proprietary business data) and response bodies (such as database records, user information, or internal system details).

The attack enables several specific API threats:

• Credential theft: Capturing API keys, tokens, or passwords from Authorization headers
• Data exfiltration: Reading sensitive information in request/response payloads
• Request manipulation: Modifying API calls before forwarding to the server (e.g., changing account numbers, payment amounts, or permissions)
• Response tampering: Altering API responses before they reach the client
• Denial of service: Dropping or delaying legitimate API traffic
• Session hijacking: Using captured authentication tokens to impersonate users

Consider a mobile app communicating with a backend API. If an attacker ARP spoofs the network, they can intercept all API calls, capture the user's authentication token from the Authorization header, and then use that token to make their own API calls impersonating the victim. This is particularly dangerous for APIs that don't implement additional transport-layer protections like mutual TLS or certificate pinning.

Detecting ARP spoofing requires monitoring network traffic for anomalies. Common detection methods include:

• Static ARP table monitoring: Checking for multiple IP addresses associated with the same MAC address, which indicates ARP poisoning
• Dynamic ARP inspection: Network switches can validate ARP packets against a trusted database of MAC-IP bindings
• Network traffic analysis: Unusual traffic patterns, such as unexpected connections to internal systems or data flows between systems that don't typically communicate
• ARP request flooding: Detecting a high volume of ARP requests from a single host, which attackers use to overwhelm legitimate responses

middleBrick detects ARP spoofing-related vulnerabilities through its network security scanning capabilities. The scanner identifies APIs that transmit sensitive data without proper transport encryption, making them vulnerable to ARP spoofing interception. It also checks for APIs that don't implement certificate pinning or mutual TLS, which would allow an attacker who successfully ARP spoofs to establish trusted connections without detection.

The scanner tests whether API endpoints expose credentials or sensitive data in ways that would be easily captured through network interception. For example, it checks if APIs send authentication tokens in query parameters (visible in URLs) rather than secure headers, or if they use weak encryption protocols that could be downgraded by a man-in-the-middle attacker.

Preventing ARP spoofing requires defense-in-depth at both network and application layers. At the network level:

interface GigabitEthernet0/1
 ip arp inspection vlan 10
 arp access-list ARP_INSPECTION
 permit ip any any match any

This Cisco IOS configuration enables dynamic ARP inspection on VLAN 10, validating ARP packets against DHCP snooping bindings.

At the API level, implement these security measures:

// Use HTTPS with strong TLS (TLS 1.3 recommended)
const https = require('https');
const fs = require('fs');

const options = {
  cert: fs.readFileSync('server.crt'),
  key: fs.readFileSync('server.key'),
  ca: fs.readFileSync('ca.crt'),
  requestCert: true,    // Mutual TLS
  rejectUnauthorized: true
};

https.createServer(options, (req, res) => {
  // Verify client certificate
  const clientCert = req.socket.getPeerCertificate();
  if (!clientCert || !clientCert.subject) {
    res.writeHead(401);
    res.end('Unauthorized: Client certificate required');
    return;
  }
  
  // Continue with API logic
}).listen(443);

For mobile and desktop clients, implement certificate pinning to prevent attackers from using their own certificates even if they ARP spoof successfully:

// Certificate pinning example (iOS with URLSession)
let session = URLSession(configuration: URLSessionConfiguration.ephemeral, delegate: self, delegateQueue: nil)

// Store SHA-256 hash of expected certificate
allet expectedCertHash = "a94a8fe5ccb19ba61c4c0873d391e987982fbbd3"

// Validate server certificate
func urlSession(_ session: URLSession, didReceive challenge: URLAuthenticationChallenge, completionHandler: @escaping (URLSession.AuthChallengeDisposition, URLCredential?) -> Void) {
    guard let serverTrust = challenge.protectionSpace.serverTrust else {
        completionHandler(.cancelAuthenticationChallenge, nil)
        return
    }
    
    // Verify certificate hash matches expected value
    if validateCertificateTrust(serverTrust, expectedHash: expectedCertHash) {
        completionHandler(.useCredential, URLCredential(trust: serverTrust))
    } else {
        completionHandler(.cancelAuthenticationChallenge, nil)
    }
}

Additional API protections include:

• Implement mutual TLS (mTLS) so both client and server authenticate each other
• Use short-lived, rotating API keys instead of long-lived credentials
• Implement request signing with HMAC to detect tampering
• Use end-to-end encryption for highly sensitive data
• Deploy network segmentation to limit ARP spoofing scope

ARP spoofing has been used in numerous high-profile attacks. In 2018, attackers used ARP poisoning in a corporate espionage case to intercept sensitive communications between executives and their financial systems. The attackers captured API credentials that provided access to proprietary trading algorithms and customer data.

CVE-2019-11510 (Pulse Connect Secure) demonstrated how network-level attacks like ARP spoofing can be combined with application vulnerabilities. Once an attacker positioned themselves in the network path, they could exploit the authentication bypass to access internal APIs without credentials.

Financial institutions are particularly vulnerable to ARP spoofing attacks on their API infrastructure. In one incident, attackers ARP spoofed a branch office network, intercepted API calls between point-of-sale terminals and the central banking system, and captured merchant credentials. This allowed them to initiate fraudulent transactions totaling over $500,000 before detection.

Public Wi-Fi networks remain a common target for ARP spoofing. Attackers set up rogue access points or use ARP poisoning on legitimate networks to intercept API traffic from mobile apps. Many mobile applications fail to implement proper certificate validation, allowing attackers to present self-signed certificates and establish trusted connections despite the ARP spoofing.

The financial impact extends beyond direct theft. Organizations face regulatory penalties for data breaches resulting from network interception, reputational damage, and the costs of incident response and customer notification. Implementing proper network and API security controls is far more cost-effective than recovering from a successful ARP spoofing attack.