ADV-101 Capstone Specification

Tool v1.0 + CERT/CC-grade disclosure report + 20-minute oral defense. Two intensive weeks (12-13) after the Week 11 workshop. The deliverable is the deliverable a professional vulnerability-research engagement produces.

The brief

You have spent Weeks 4-7 building a tool that exercises the SB6141 CSRF (Longenecker CVE; CERT/CC VU#419568) under authorization, with fingerprinting, --authorized-by enforcement, --dry-run, structured logging, and idempotent semantics. You have spent Weeks 8-9 scoring the CVE under CVSS v3.1 and drafting a CERT/CC-grade disclosure report. Weeks 10-11 added the ethics framework and the workshop polish.

The capstone is what ships when those pieces converge. You hand the academy: a proper Python package (Tool v1.0), a CERT/CC-grade disclosure report, and a 20-minute oral defense before a three-reviewer panel.

The grading panel evaluates the work as if it were a real engagement deliverable. The capstone fails if either the tool or the report is below the practitioner-acceptable bar. Both legs must be solid.

What you ship

A Git repository containing two top-level directories:

adv101-capstone-{your-name}/
├── tool/                          # Tool v1.0 Python package
│   ├── pyproject.toml             # Package metadata (PEP 621)
│   ├── README.md                  # Install + usage + safety controls
│   ├── LICENSE                    # MIT or Apache 2.0 (your choice)
│   ├── CHANGELOG.md               # v0.1 / v0.2 / v0.3 / v1.0 history
│   ├── src/sb6141_csrf/
│   │   ├── __init__.py
│   │   ├── cli.py                 # argparse + main() entry
│   │   ├── fingerprint.py         # target-detection logic
│   │   ├── exploit.py             # the CSRF reproduction
│   │   └── logging_setup.py       # structured log config
│   └── tests/
│       ├── test_fingerprint.py
│       ├── test_cli.py
│       └── test_exploit.py        # mocked HTTP; no live target
├── report/                        # Disclosure-ready report
│   ├── disclosure-report.md       # The CERT/CC-grade report
│   ├── cvss-v3.1-vector.txt       # The vector string + per-metric notes
│   └── reproduction-transcript.md # Annotated transcript (curl + Burp)
└── lab-portfolio.md               # Authorization signatures, lab completions

Naming convention: adv101-capstone-{your-name} (lowercase, hyphens, no spaces).

Tool v1.0 specification

Tool v1.0 promotes Lab 7's Tool v0.3 to a shippable Python package. Required properties:

Package structure (PEP 621)

pyproject.toml:

[build-system]
requires = ["setuptools>=61", "wheel"]
build-backend = "setuptools.build_meta"

[project]
name = "sb6141-csrf"
version = "1.0.0"
description = "Authorized reproduction tool for the Motorola SB6141 CSRF (CERT/CC VU#419568)"
readme = "README.md"
license = {text = "MIT"}
authors = [{name = "Your Name", email = "you@example.com"}]
requires-python = ">=3.11"
dependencies = ["requests>=2.28"]

[project.optional-dependencies]
test = ["pytest>=7.0"]

[project.scripts]
sb6141-csrf = "sb6141_csrf.cli:main"

The [project.scripts] entry creates a sb6141-csrf command on pip install.

Safety controls (all of these must be present and enforced)

1. --authorized-by NAME is REQUIRED. The argparse parser exits with error: --authorized-by is required if absent. The value goes into every log entry.
2. --dry-run prints what the tool WOULD do without doing it. Off by default; on requires no further action.
3. Fingerprint-or-refuse. Before any state-changing action, the tool issues a fingerprint probe and verifies the target is an SB6141. If the fingerprint fails, the tool exits nonzero with a clear message.
4. Idempotent semantics. Running the tool twice has the same effect as running it once. The second run detects the previous run's state (via a fingerprint of the modified configuration) and reports "already done" without re-applying.
5. Rollback path. A --rollback mode restores the configuration the tool modified. If rollback is impossible for the specific operation, the tool documents the irreversibility explicitly in its run-log AND refuses to run unless --accept-irreversible is also passed.
6. Structured logging. Every run writes a JSON log to ~/.sb6141-csrf/runs/{ISO8601}.json AND a human-readable summary to stderr. The JSON log contains: timestamp, target, authorized-by, action, dry-run flag, fingerprint result, exit code, any error.
7. Exit codes. 0 = success or dry-run-confirmed; 1 = runtime failure; 2 = usage error; 3 = fingerprint mismatch; 4 = authorization missing.

Tests (pytest)

Three or more test files. At minimum:

• test_fingerprint.py. Mocks the HTTP response (use unittest.mock.patch or responses library). Verifies the fingerprint logic accepts a known-good response and rejects a known-bad response.
• test_cli.py. Verifies argparse rejects calls without --authorized-by; accepts a complete call; respects --dry-run.
• test_exploit.py. Mocks the HTTP layer; verifies the CSRF request shape is correct (target URL, headers, body) WITHOUT touching a live SB6141.

A pytest invocation from the tool/ directory must pass all tests in under 30 seconds.

README

Three sections (~200 words):

# sb6141-csrf

Authorized reproduction tool for the SB6141 CSRF vulnerability (CERT/CC VU#419568).
For use under written authorization against an isolated lab target only.

## Install

```bash
git clone https://github.com/YOUR-USERNAME/adv101-capstone-NAME.git
cd adv101-capstone-NAME/tool
pip install -e .

Usage

Dry-run (preview the action):

sb6141-csrf --target 192.168.100.1 --authorized-by "Your Name (cohort 2026-A)" --dry-run

Authorized execution (after dry-run review):

sb6141-csrf --target 192.168.100.1 --authorized-by "Your Name (cohort 2026-A)"

The tool refuses to run without --authorized-by. The tool refuses to run if the target does not fingerprint as an SB6141. See --help for full options.

License

MIT. See LICENSE.

### CHANGELOG

```markdown
# CHANGELOG

## v1.0.0 (2026-MM-DD)

- Package shipped: pyproject.toml, LICENSE, README, CHANGELOG.
- pytest suite covering fingerprint, CLI, and exploit-layer behavior.
- Rollback mode added.
- Structured JSON run-logs at ~/.sb6141-csrf/runs/.

## v0.3 (Lab 7)

- Structured logging (JSON + human-readable stderr).
- Idempotent semantics: re-run detects prior state.

## v0.2 (Lab 5)

- --authorized-by required; --dry-run flag added.
- Destructive-action confirmation prompts.

## v0.1 (Lab 4)

- Fingerprint-only tool: probes target, exits with no state change.

Disclosure report specification

A CERT/CC-grade disclosure-ready report. The report SHOULD be publishable as a CERT/CC vulnerability note with minimal editing.

Required sections

1. Title (one line): SB6141 CSRF in Administrative Interface, CERT/CC VU#419568 Reproduction Report. Cohort + your name in the byline.

2. Summary (~200 words). Plain English: what is the vulnerability, what does it let an attacker do, what is the scope. Pitched at the level of an engaged but non-specialist reader (the kind of person who reads the CERT/CC weekly bulletin).

3. Affected products and versions. Motorola SURFboard SB6141 cable modems; firmware versions per the original advisory. Cite the CERT/CC record.

4. Vulnerability description (~500 words). The technical mechanism. How does the SB6141 administrative interface authenticate? How does the CSRF ride that mechanism? Use Stuttard + Pinto's framework if it clarifies. Cite the original Longenecker advisory.

5. Reproduction steps. Numbered, exact, reproducible. The reader should be able to follow these and reproduce the behavior on their own authorized lab SB6141. Include the curl command(s) and the expected response shape. NO weaponized payload; the reproduction stops at "configuration modification observed."

6. Proof-of-concept code reference. Point to the tool's repository. Note the safety controls (--authorized-by required, --dry-run default).

7. CVSS v3.1. Vector string + score. Per-metric justification (one paragraph per metric).

8. Remediation. What would fix this in the SB6141 firmware? CSRF tokens; SameSite cookies; both. Note that the SB6141 is end-of-life; no patch is forthcoming. Recommend pulling the device from service or air-gapping it.

9. Mitigation (operator-level). What can an SB6141 operator do to reduce exposure short of replacing the device? Network-level controls; restricting admin-interface access to a trusted subnet.

10. Negative-scope statement. What this report does NOT do: it does not demonstrate post-exploitation; it does not chain with any other vulnerability; it does not target any device the researcher did not personally own and authorize. This section protects the researcher; it MUST be present.

11. Disclosure timeline. When was the original advisory? When did the researcher reproduce? When was this report drafted? The full CVD timeline applies even though this is a re-reproduction of a 2015 disclosure.

12. References. CERT/CC advisory; Longenecker original write-up; Stuttard + Pinto pages cited; CVSS calculator; ISO/IEC 29147 if cited.

Length

~2500-4000 words total. Long enough to be substantive; short enough to be read. CERT/CC published advisories are typically in this range.

Voice

Practitioner-direct. No em-dashes. No marketing language. The reader is a security engineer or a vendor security team; write to that audience.

Oral defense specification

A 20-minute oral defense before the three-reviewer panel. Format:

• 8 minutes presentation. Walk through the tool's safety controls, the reproduction transcript, and the disclosure report's key sections. Slides optional; a terminal demo of the tool's --help and one --dry-run is often more persuasive than slides.
• 12 minutes Q&A. The panel asks; you answer. The instructor asks; the academy alumnus asks; the external reviewer asks. Common questions in the rubric below.

What the panel will ask

The panel rotates among these question categories. Be prepared for at least one question from each:

• Technical. "Walk us through the exact CSRF request. What headers? What body?" The student should answer without notes.
• Safety controls. "What happens if I run your tool against my home router by accident? Show me." The student demos the fingerprint-mismatch refusal.
• CVSS. "Why did you score Attack Complexity as Low, not High? Defend." The student cites the FIRST.org spec's definitions and the SB6141's behavior.
• Disclosure. "If you found this vulnerability TODAY in a current-shipping vendor's device, what would your disclosure timeline be? What if the vendor refused to acknowledge?" The student walks through the CERT/CC + ISO/IEC 29147 process from memory.
• Ethics. "What is the line between this work and unauthorized access? How would you explain it to a non-technical client?" The student should be able to answer in plain English.
• Limits. "What's the next CVE you'd take on? How would your approach change?" The student should demonstrate reflection on the methodology, not just trophy-hunting.

What the panel watches for

• Honest uncertainty. "I don't know the exact answer to that, but here's how I'd find out" is acceptable. Bluffing is not.
• Safety-first instinct. A student who, when describing a hypothetical, says "first I'd verify scope" demonstrates the discipline. A student who jumps to "first I'd run the tool" needs more time on the safety framing.
• Comfort with the tool. The student should be able to demo the tool live without consulting notes. Memory beats slides.

Two-tier grading rubric

A capstone where the tool runs but the report is weak fails. A capstone where the report is strong but the tool lacks --authorized-by fails. Both legs must be solid.

Success criteria

Your capstone is graded on three things:

1. It is shippable. A peer in the cohort can clone your repo, install the tool, run the tests, read the report, and understand the entire engagement without asking you a question.
2. It is safe. Every safety control in the spec is present and enforced. The panel verifies by running your tool with deliberately-bad inputs (missing --authorized-by, wrong target, repeat invocation).
3. It is yours. You can defend it. The 20-minute defense surfaces who actually built the work; bluffing does not survive the Q&A.

What the capstone does NOT require

• No novel CVE discovery. The capstone reproduces a known CVE; the discipline IS the discipline, not the novelty.
• No weaponized exploit code. The tool exercises the CSRF to demonstrate the vulnerability; it does NOT implement post-exploitation, persistence, or chaining.
• No paid tooling. Burp Community + Python + curl is the entire toolchain. No Burp Pro, no Nessus, no Metasploit.
• No live disclosure submission. The report is "disclosure-ready"; submitting to CERT/CC is the student's choice after course completion, not a course requirement.

Timeline

Submission

Push your capstone repository to GitHub or GitLab. Email the URL to interested@virtuscyberacademy.org with subject ADV-101 capstone, {your-name}. Include in the email:

• The repository URL
• One sentence describing the CVE you reproduced (always SB6141 CSRF for the standard capstone; CVE-2026-5402 for the capstone-arc variant)
• The one safety control you are proudest of (a sentence; the full story is in the defense)

The course team responds within 14 days with the grade and panel feedback.

Outstanding capstones (top decile per cohort) are invited to the academy's public capstone showcase with the student's permission. Outstanding capstones whose authors agree may also be referred to academy industry partners for vuln-research role consideration.

After the capstone

A finished ADV-101 capstone is a portfolio piece. It demonstrates: tool engineering, CVE-reproduction methodology, CVSS scoring, CVD drafting, oral-defense composure, and the professional discipline that distinguishes a vulnerability researcher from an attacker. Students applying to industry vuln-research roles after the academy cite their capstone repository in cover letters; students sitting OSCP+ build directly on the ADV-101 + PEN-101 methodology.

Keep the lab-portfolio.md current; the authorization signatures and per-session logs ARE the documentation that proves your work was conducted ethically. The day a future employer or grant-reviewer asks "how do I know you did this work under authorization?", the lab portfolio is the answer.

Capstone specification v0.1.