Dns Rebinding in APIs

DNS rebinding is a network attack technique that exploits the trust relationship between a web browser and a local network service. The attack works by manipulating DNS records to trick a victim's browser into making requests to what it believes is a remote server, but is actually a local network resource.

The attack sequence typically follows this pattern:

• An attacker registers a domain (e.g., evil.com) and configures it with a short TTL (Time To Live) DNS record
• The victim visits a malicious website or loads malicious content that includes JavaScript from evil.com
• The JavaScript makes requests to evil.com, which initially resolves to the attacker's server
• After the victim's browser caches the DNS response, the attacker changes the DNS record to point to a private IP address (like 192.168.1.1)
• The browser, still executing JavaScript from what it thinks is evil.com, makes requests to the local network IP
• Same-origin policy is bypassed because the domain remains evil.com, but the requests hit internal services

This technique effectively bypasses browser security restrictions that normally prevent web pages from accessing local network resources.

DNS rebinding poses significant risks to API endpoints, particularly those that:

• Trust requests based on IP address or network location
• Lack proper authentication mechanisms
• Expose administrative interfaces on local networks
• Have default credentials or weak authentication

Common attack scenarios include:

• Router Compromise: An attacker uses DNS rebinding to access a router's admin interface at 192.168.1.1, changes DNS settings, or opens ports for persistent access
• API Server Hijacking: Internal API endpoints that trust local requests can be manipulated to expose sensitive data or modify configurations
• Database Exposure: Local database services listening on localhost or private IPs can be accessed to extract or modify data
• Container Orchestration: Docker APIs, Kubernetes dashboards, or similar orchestration tools can be compromised to deploy malicious containers

The vulnerability is particularly dangerous because it allows an attacker to pivot from an external web context into a trusted internal network position without requiring any network-level access.

Detecting DNS rebinding requires both proactive scanning and defensive monitoring. Here's what to look for:

• Unauthenticated API Endpoints: APIs that accept requests without proper authentication are prime targets
• IP-based Trust Relationships: Services that grant elevated privileges to requests from certain IP ranges
• Local Network Services: Any API accessible from a web browser that runs on private IP ranges
• Missing Rate Limiting: Endpoints without rate limiting can be abused for enumeration attacks

middleBrick's Detection Approach: middleBrick's black-box scanning methodology includes specific checks for DNS rebinding vulnerabilities. The scanner tests whether your API endpoints:

• Respond to requests without proper authentication
• Trust requests based on network location rather than credentials
• Expose administrative functionality that could be abused through local network access
• Have inconsistent authentication requirements across different endpoints

The scanner runs 12 parallel security checks, including authentication bypass testing and privilege escalation detection, which can identify APIs vulnerable to DNS rebinding attacks. When you submit your API URL to middleBrick, it simulates unauthenticated access patterns to reveal these trust relationships.

For manual testing, you can use tools like rbndr.us to generate DNS rebinding domains and test your APIs' responses to requests from what appear to be local network sources.

Preventing DNS rebinding requires a defense-in-depth approach. Here are concrete code-level fixes and architectural patterns:

1. Implement Strong Authentication Everywhere

// Never trust requests based on IP alone
app.use('/api/admin', authenticateJWT); // Require auth for all admin routes
app.use('/api/internal', requireAuth); // No unauthenticated access

2. Use CSRF Protection

// Implement CSRF tokens for state-changing operations
app.post('/api/update-settings', csrfProtection, updateSettings);

3. Validate Host Headers

// Reject requests with unexpected host headers
app.use((req, res, next) => {
  const allowedHosts = ['api.example.com', 'localhost:3000'];
  if (!allowedHosts.includes(req.headers.host)) {
    return res.status(400).json({ error: 'Invalid host' });
  }
  next();
});

4. Implement CORS Correctly

// Restrict origins, not just allow all
app.use(cors({
  origin: ['https://example.com'], // Specific origins only
  credentials: true,
  methods: ['GET', 'POST', 'PUT', 'DELETE']
}));

5. Use SameSite Cookies

// Prevent cross-site request forgery
res.cookie('session', sessionId, {
  httpOnly: true,
  secure: true,
  sameSite: 'strict'
});

6. Network-Level Protection

# Nginx configuration to block private IP ranges
location / {
  if ($http_host ~* (localhost|127\.0\.0\.1|10\.|172\.(1[6-9]|2[0-9]|3[0-1])|192\.168)) {
    return 403;
  }
}

For comprehensive protection, combine these code-level fixes with network segmentation, proper firewall rules, and regular security scanning with tools like middleBrick to identify vulnerable endpoints before attackers do.

DNS rebinding attacks have been responsible for numerous high-profile security incidents. While specific CVEs for DNS rebinding are rare (since it's often a technique rather than a specific vulnerability), several notable incidents highlight its impact:

• 2010 Google Chrome DNS Rebinding Attack: Researchers demonstrated how Chrome's WebSockets implementation could be exploited for DNS rebinding, allowing attackers to bypass network security measures
• 2018 Ethereum Wallet Theft: Attackers used DNS rebinding to access local Ethereum wallets running on users' machines, stealing cryptocurrency
• Smart Home Device Exploits: Multiple incidents have shown how DNS rebinding can control smart home devices, from door locks to security cameras
• 2020 Zoom Vulnerability: A DNS rebinding flaw in Zoom's Windows client allowed attackers to access local network resources through the application

The technique remains relevant because it exploits fundamental trust relationships in network architecture. As more services move to cloud environments while maintaining local network dependencies, the attack surface for DNS rebinding continues to evolve.

middleBrick's scanning methodology specifically tests for the trust relationships and authentication gaps that make DNS rebinding possible, helping organizations identify vulnerable endpoints before they can be exploited in real attacks.