Ssrf Blind Attack

Server-Side Request Forgery (SSRF) is a web security vulnerability where an attacker tricks a server into making requests to unintended locations. Blind SSRF occurs when the attacker cannot directly observe the response from the target system, making it harder to extract data but still dangerous.

The attack typically follows this pattern:

• Initial Request: The attacker sends a crafted request to the vulnerable API endpoint, including a URL parameter that will be used to make an internal request
• Server Processing: The server processes the request and makes an outbound connection to the attacker-specified URL without proper validation
• Hidden Response: The server receives the response but doesn't return it to the attacker directly
• Indirect Exfiltration: The attacker uses side channels like timing, error messages, or DNS lookups to infer information about the target system

Common blind SSRF techniques include:

• Time-based detection: Measuring response times to determine if a port is open or closed
• Error-based detection: Analyzing error messages or HTTP status codes
• DNS exfiltration: Forcing the server to resolve DNS names under the attacker's control to leak information
• Out-of-band (OOB) attacks: Using external services to receive callbacks with data

APIs are particularly vulnerable to SSRF attacks because they often need to make outbound requests as part of their normal operation. Common API scenarios include:

• Webhook processing: APIs that call user-provided URLs to send notifications or callbacks
• URL fetchers: APIs that download content from external URLs for processing
• API aggregation: Services that call other APIs based on user input
• Configuration endpoints: APIs that read configuration from remote locations

A blind SSRF attack against an API might look like this:

POST /api/process-webhook HTTP/1.1
Host: vulnerable-api.com
Content-Type: application/json

{
  "callback_url": "http://internal-service:8080/health"
}

The API processes this request, makes an internal call to http://internal-service:8080/health, and returns a generic success message. The attacker cannot see the internal service's response directly but can use timing analysis to determine if the service is reachable.

More sophisticated attacks might target:

• Cloud metadata services: http://169.254.169.254/latest/meta-data/ (AWS, Azure, GCP metadata endpoints)
• Database services: Redis on port 6379, MongoDB on port 27017
• Container orchestration: Docker API on port 2375, Kubernetes API
• Development tools: Debug endpoints, admin consoles

Real-world examples include the Capital One breach (2019) where SSRF was used to access internal metadata services, and the Verizon breach (2020) involving SSRF to access internal cloud resources.

Detecting SSRF vulnerabilities requires both static analysis and runtime testing. middleBrick's black-box scanning approach tests API endpoints for SSRF by attempting to make requests to known internal IP ranges, loopback addresses, and cloud metadata services.

Prevention strategies include:

Input Validation and Sanitization

Implement strict URL validation:

function validate_url(url) {
  const parsed = new URL(url);
  
  // Block private IP ranges
  const privateRanges = [
    /^10\./,
    /^172\.(1[6-9]|2[0-9]|3[0-1])\./,
    /^192\.168\./,
    /^127\./,
    /^169\.254\./,
    /^0\.0\.0\.0/,
    /^255\.255\.255\.255/
  ];
  
  if (privateRanges.some(range => range.test(parsed.hostname))) {
    throw new Error('Private IP address not allowed');
  }
  
  // Block cloud metadata services
  if (parsed.hostname === '169.254.169.254' || 
      parsed.hostname === '169.254.254.169') {
    throw new Error('Metadata service access denied');
  }
  
  return true;
}

Network Layer Controls

Implement outbound firewall rules to restrict API server access:

# Block internal network access
iptables -A OUTPUT -d 10.0.0.0/8 -j DROP
iptables -A OUTPUT -d 172.16.0.0/12 -j DROP
iptables -A OUTPUT -d 192.168.0.0/16 -j DROP
iptables -A OUTPUT -d 127.0.0.0/8 -j DROP

# Block cloud metadata services
iptables -A OUTPUT -d 169.254.169.254 -j DROP

# Allow only specific external domains
iptables -A OUTPUT -d allowed-domain.com -j ACCEPT

API Security Scanning

middleBrick tests for SSRF vulnerabilities by attempting requests to:

• Private IP ranges (10.x, 172.x, 192.168.x, 127.x)
• Loopback and localhost addresses
• Cloud metadata endpoints (169.254.169.254)
• Common internal ports (2375, 3306, 5432, 6379)

The scanner reports findings with severity levels and provides specific remediation guidance for each vulnerability discovered.

Monitoring and Detection

Implement logging for outbound requests:

# Log all outbound HTTP requests from API servers
auditctl -w /usr/bin/curl -p rwxa
auditctl -w /usr/bin/wget -p rwxa

# Monitor for metadata service access
auditctl -a exit,always -F arch=b64 -S connect -F dir=169.254.169.254

Set up alerts for suspicious patterns like rapid requests to multiple internal IPs or access to known cloud metadata endpoints.