Ssrf Cloud Metadata Attack

Server-Side Request Forgery (SSRF) targeting cloud metadata services exploits a fundamental trust relationship between cloud instances and their metadata endpoints. Cloud providers embed special IP addresses (like 169.254.169.254 for AWS) that return instance-specific data when queried from within the instance.

The attack works by manipulating an API to make outbound HTTP requests to these metadata endpoints. Since the request originates from the cloud instance itself, the cloud's security controls don't block it. The metadata service then returns sensitive information including:

• Instance identity documents with temporary credentials
• SSH keys and cryptographic certificates
• Configuration files with database credentials
• Network configuration including VPC details
• CloudFormation or Terraform state files

Attackers craft payloads that force the server to request URLs like http://169.254.169.254/latest/meta-data/ or similar endpoints. The server's outbound request library follows the URL, fetches the metadata, and often returns it in error messages or logs accessible to the attacker.

Different clouds use different metadata endpoints: AWS uses 169.254.169.254, Azure uses 169.254.169.254 with different paths, and GCP uses 169.254.169.254 with its own metadata format. Some clouds also support IPv6 metadata endpoints.

APIs become vulnerable to SSRF metadata attacks when they accept URLs as parameters and make HTTP requests without proper validation. Common API patterns include:

• Webhook verification endpoints that fetch URLs to confirm they're valid
• URL shortener services that resolve links
• RSS feed aggregators that fetch external content
• PDF generation services that render web pages
• Payment processing APIs that verify merchant URLs

The attack sequence typically follows this pattern: An API receives a request with a URL parameter, makes an HTTP GET request to that URL, and processes the response. An attacker supplies the metadata endpoint instead of a legitimate URL. The server fetches the metadata and either returns it directly or leaks it through error messages, stack traces, or logs.

For example, a webhook verification API might accept ?url=https://example.com, make a request to verify the endpoint exists, and return success or failure. An attacker modifies this to ?url=http://169.254.169.254/latest/meta-data/identity-credentials/. The server fetches this URL, retrieves AWS credentials, and the credentials appear in the response or logs.

More sophisticated attacks target specific metadata paths. Attackers might request /latest/meta-data/iam/security-credentials/role-name/ to get temporary AWS credentials, then use those credentials to access S3 buckets, EC2 instances, or other cloud resources. Some APIs inadvertently expose the full metadata response in error messages, giving attackers complete access to instance configuration.

Rate limiting and IP restrictions often don't apply to metadata endpoints since they're designed for internal instance access. This makes SSRF attacks against metadata particularly effective and difficult to detect through traditional network monitoring.

Detecting SSRF metadata attacks requires monitoring for outbound requests to known metadata IP ranges. Network security groups should explicitly block egress traffic to 169.254.0.0/16 and similar ranges. Application-level detection involves inspecting URL parameters for metadata patterns and implementing request validation.

Prevention strategies include:

• Input validation: Reject URLs containing metadata IP addresses or private IP ranges
• Allowlist approach: Only permit requests to specific, trusted domains
• Network segmentation: Isolate services that make outbound requests
• Proxy all external requests through a security-aware proxy that blocks metadata endpoints
• Environment hardening: Configure cloud instances to restrict metadata access to specific paths or require additional authentication

Code examples for prevention:

function validateUrl(urlString) {
  try {
    const url = new URL(urlString);
    
    // Block metadata IP ranges
    const metadataIps = [
      '169.254.169.254',    // AWS/Azure
      '169.254.169.253',    // GCP
      '169.254.0.0/16'      // General metadata range
    ];
    
    if (metadataIps.includes(url.hostname)) {
      throw new Error('Metadata endpoint access blocked');
    }
    
    // Block private IP ranges
    const privateRanges = [
      '10.0.0.0/8',
      '172.16.0.0/12',
      '192.168.0.0/16'
    ];
    
    // Additional validation for protocol, port, etc.
    if (!['http:', 'https:'].includes(url.protocol)) {
      throw new Error('Only HTTP/HTTPS allowed');
    }
    
    return true;
  } catch (error) {
    throw new Error(`Invalid URL: ${error.message}`);
  }
}

Security testing tools like middleBrick can automatically scan APIs for SSRF vulnerabilities, including metadata endpoint access. The scanner tests common metadata URLs and reports findings with severity levels and remediation guidance. middleBrick's black-box approach simulates real attack scenarios without requiring credentials or access to source code.

Runtime protection includes implementing API gateways that validate outbound requests, using Web Application Firewalls (WAFs) with SSRF rules, and monitoring logs for metadata access patterns. Regular security audits should include SSRF testing as part of the API security assessment.

For cloud-specific hardening, AWS offers IMDSv2 (Instance Metadata Service version 2) which requires session tokens for metadata access, making SSRF exploitation more difficult. Azure and GCP provide similar protections through their metadata service configurations.