Adversarial posture; authorization as the dividing line; CVE records as professional literature. The lab annotates the SB6141 Longenecker CVE; you reproduce nothing yet.
Theme
ADV-101 starts where every adversarial-research engagement starts: with authorization. The dividing line between security research and unauthorized access under the Computer Fraud and Abuse Act is not technical; it is the question of whether you had permission to run the tools you ran. The first week is spent establishing that the discipline of asking for permission, documenting it, and limiting your work to its scope is the discipline that makes the rest of the course possible.
The second part of Week 1 is reading. A CVE record is a professional document, written for an audience that includes vendors, defenders, and other researchers. Reading one carefully (and noticing what it leaves out) is the foundational skill for everything that follows. The Lab 1 deliverable is an annotation of the Longenecker SB6141 advisory: what does the advisory tell you, what does it omit, what would you need to reproduce the issue, what authorization basis would you need.
You touch no hardware in Week 1. The first hardware-contact lab is Week 2; the first tool-running lab is Week 4; the first state-changing lab is Week 5 (under signed authorization). The pacing is deliberate. Engineers who rush past Week 1's framing are engineers who later find themselves explaining to a federal prosecutor why what they did was research, not crime.
By the end of Week 1 you understand: why the academy's cyber-use authorization document exists, what the Longenecker SB6141 CVE actually says and does not say, what the CERT/CC vulnerability-note format looks like, and why a published CVE that is ten years old is still useful as a teaching object.
Schneier weave (~280 words, A Hacker's Mind Ch 1)
Bruce Schneier opens A Hacker's Mind with the observation that hacking is the discipline of finding loopholes in rule systems, and that the discipline applies far more broadly than just to computer systems. His worked examples in Chapter 1 include tax code, the legal system, and casino games before he reaches anything resembling a digital target. The framing matters for ADV-101's first week because it reframes adversarial research as a discipline of careful reading rather than offensive enthusiasm.
A SB6141 CSRF is a loophole in the rule system the modem's web interface implements: the rule is "actions on this interface should be performed only by authorized administrators," and the loophole is "the interface enforces no token that distinguishes the administrator's intentional click from a cross-origin form post the administrator did not write." Reading the advisory carefully (the Lab 1 task) is finding that loophole in the rules-as-written. Reproducing it (Lab 2) is exercising the loophole under authorization. Disclosing it (Lab 9) is reporting the loophole so the rule-system owner can close it.
Schneier's argument is that this discipline, applied broadly, is the discipline that makes a hacker a hacker regardless of domain. Tax lawyers find loopholes in tax code; arbitrage traders find loopholes in market structure; political consultants find loopholes in election rules. The discipline is the same. What distinguishes the professional security researcher from the prosecutable felon is not the discipline but the question of authorization: were you authorized to find this loophole, and were you authorized to demonstrate it.
The course's central commitment is that you operate as a professional. Schneier is the voice that keeps that commitment in front of you while you do.
Reading list (~1 hour)
- Schneier, A Hacker's Mind, Ch 1 ("What Is Hacking?"). Academy library; calibre id 677. The opening framing the course inherits.
- CERT/CC vulnerability note VU#419568 at
https://www.kb.cert.org/vuls/id/419568. The original Longenecker SB6141 advisory. Read every section, including the ones that look like boilerplate. - David Longenecker, "Cable modem pwned" at
https://www.shellntel.com/blog/2015/11/22/cable-modem-pwned. The researcher's own write-up of the SB6141 disclosure. Notice the difference in voice between the formal CERT/CC note and the researcher's blog post. - FIRST.org CVSS v3.1 specification at
https://www.first.org/cvss/v3.1/specification-document. Read the introduction and Section 1. The full specification arrives in Week 8. - U.S. Computer Fraud and Abuse Act, 18 U.S.C. §1030 at
https://www.law.cornell.edu/uscode/text/18/1030. Read §1030(a)(2) and §1030(e)(6) ("exceeds authorized access"). The statute that defines the dividing line.
Lecture outline (~50 min)
Part 1: Authorization as the dividing line (20 min)
- The legal frame. CFAA §1030 makes unauthorized access to a computer a federal crime. "Authorized access" is the phrase that does all the work; without authorization, you are committing a crime regardless of what you find.
- What authorization looks like. A written document, signed by both parties (researcher and system owner), that specifies the target, the scope, the time window, and the negative scope (what is explicitly out of bounds). Verbal authorization is not authorization; you cannot defend it in court.
- The course's authorization. The academy distributes a cyber-use authorization document this week. You read it; you sign it; the instructor counter-signs. The document covers the SB6141 lab target, the isolated lab network, the duration (Week 4 through capstone), and the negative scope. The signed document lives in your lab portfolio.
- What happens if you skip this. You can be prosecuted under CFAA even if your intent is research. The Aaron Swartz and Marcus Hutchins cases are the obvious examples; the less-public cases are the ones that ended quietly when the researcher could not produce documented authorization. The academy's discipline exists because the legal system's tolerance for "I meant well" is finite.
Part 2: Reading a CVE record (20 min)
- The CERT/CC vulnerability-note format. Title, summary, affected products, vulnerability description, impact, solution, vendor information, vendor statements, references, credit, history. Each field is structured; each carries professional meaning.
- What CERT/CC notes typically include. A clear vulnerability description; a reproduction methodology (sometimes including PoC code); an impact assessment; vendor patch status; CVSS scoring; references to the original researcher's write-up.
- What CERT/CC notes typically omit. Weaponized exploit code; details that would enable mass exploitation against unpatched systems; researcher correspondence with the vendor; the full CVD timeline (often summarized).
- The Longenecker SB6141 note specifically. VU#419568. Discloses an unauthenticated CSRF in the SB6141 administrative interface. The note says enough that a researcher with the device can reproduce the issue; it does not provide weaponized code or instructions for mass-exploitation against deployed modems.
- What Lab 1 will ask you to do. Read the note line by line. Annotate three things: what the note says, what the note implies, what the note omits. The third category is the most useful; it is what a vulnerability researcher reading a competitor's advisory has to figure out for themselves.
Part 3: The structural difference (10 min)
- A tool vs a script vs a payload. A tool is engineered for repeat use, with safety controls and documentation. A script is a one-shot artifact, often hand-written for a specific moment. A payload is code that executes on a target as the consequence of an exploit. ADV-101 builds tools; PEN-101 occasionally writes scripts; ADV-101 explicitly does NOT produce weaponized payloads.
- A vulnerability vs an exploit vs a CVE. A vulnerability is a property of a system (a bug or a design flaw that enables undesired action). An exploit is the technique that uses the vulnerability to achieve the action. A CVE is the public record naming the vulnerability. ADV-101 reproduces CVEs (records); the reproduction technique IS the exploit; the underlying flaw IS the vulnerability. Keep the terms straight.
- Forward pointers. Week 2 reproduces the CSRF manually with
curl. Week 3 builds the lab network. Week 4 fingerprints the target. Week 5 adds the authorization gate. By Week 11 you have a tool you can defend. The pacing is the curriculum.
Disclosure-Ethics Sidebar
Authorization sits at the intersection of three norm systems. The discipline of ADV-101 is to recognize all three:
| Norm system | Question | Source |
|---|---|---|
| Responsible disclosure (the CVE process) | Did you report the finding to the vendor before publishing? Did you give the vendor reasonable time to patch? | CERT/CC CVD guide; ISO/IEC 29147 |
| Academic ethics (IRB-like review) | Did you cause harm? Did you minimize harm? Did you respect the autonomy of affected parties? | IRB principles applied to security research |
| Legal authorization | Did you have written permission to test? Did your work stay within scope? | CFAA §1030; state-law variation; DMCA §1201 |
The SB6141 disclosure passed all three. Longenecker reported to ARRIS / Motorola; CERT/CC coordinated; the device was end-of-life with no patch forthcoming so the disclosure went public; Longenecker's work was on his own hardware. Your ADV-101 work follows the same shape: academy-authorized target, academy-coordinated disclosure (instructor as proxy vendor), academy-owned lab portfolio as the documentation chain.
Labs (~3 hr)
Lab 1: SB6141 CVE Annotation (labs/lab-1-cve-annotation.md)
- Goal: annotate the Longenecker SB6141 CVE record (VU#419568) line by line; produce a reproducing-researcher checklist
- Time: ~3 hr (1 hr reading; 2 hr annotation + checklist)
- Artifact:
lab-1-annotation.mdin~/adv-101/lab-1/, committed to Git
Independent practice (~5 hr)
-
Read CFAA §1030 in full (1 hr). The statute is dense; read it slowly. Look up "protected computer" (§1030(e)(2)); look up "exceeds authorized access" (§1030(e)(6)). The Van Buren ruling (2021) narrowed but did not eliminate the "exceeds authorized access" reach; understand the residual ambiguity.
-
Find three other CERT/CC vulnerability notes (1.5 hr). Browse
https://www.kb.cert.org/vuls/for three CVEs in the IoT or consumer-router space. Read each. Notice the format consistency; notice the writing-quality variation. Write a one-paragraph comparison of the three. -
Read Schneier A Hacker's Mind Ch 2 ("Hacking Systems") (1 hr). This Chapter extends Ch 1's framing into non-technical domains. The chapter will be cited in Week 5's tool-safety discussion.
-
Watch the Aaron Swartz documentary "The Internet's Own Boy" or read its Wikipedia summary (1.5 hr). Either is acceptable. The Swartz case is the canonical CFAA-overreach case in security research; understanding the facts (Swartz had legitimate access to JSTOR's network as an MIT visitor; the prosecution argued his bulk-download activity exceeded authorization) is important background for understanding why authorization discipline matters.
Reflection prompts (~30 min)
Journal these at week's end.
- Before this week, did you think of "authorization" as paperwork or as a substantive professional discipline? Has your view changed?
- The Longenecker SB6141 advisory is ten years old. Why is it still useful as a teaching object? What does a ten-year-old CVE teach that a fresh one does not?
- Schneier argues hacking is rule-system loophole-finding. Pick a non-computer rule system you know well (a game, a sport, a tax bracket, a school policy). Identify one "hack" in that system. How does the discipline transfer?
- The CERT/CC note for VU#419568 includes a CVSS score. Did the score match your intuition about the severity? Why or why not? (Week 8 will revisit this.)
- What is one question this week raised that you hope a later week will answer?
Adversary Diary (Week 1)
The Adversary Diary is your running list of practitioner tools you have met. Week 1 introduces (none directly; the lecture is reading-only). The first entries arrive in Week 2.
Initial entries (forward-pointer; you will encounter these starting Week 2):
- The CERT/CC vulnerability database at
https://www.kb.cert.org/vuls/ - The NIST National Vulnerability Database at
https://nvd.nist.gov/ - The MITRE CVE list at
https://cve.mitre.org/
These are reference resources, not tools per se, but they belong in the diary as the documentation infrastructure the discipline runs on.
What would a reviewer ask?
After completing this week, expect these questions in any review setting:
- "Walk me through the authorization document you signed. What does it cover? What does it explicitly exclude?"
- "Why did the academy choose the SB6141 specifically? What would have changed if it picked a different target?"
- "What is one thing the Longenecker advisory does NOT tell you that you would want to know if you were the SB6141 vendor's security team responding to it?"
What comes next
Week 2 is the first hardware-touching lab. You set up Burp Suite, point a browser at the SB6141 administrative interface, capture the request shape, and reproduce the CSRF manually with curl. You will produce a transcript that shows the request and the response; the transcript becomes evidence in Week 9's disclosure-draft.