feat: deepen 268 exploitation skills; web session delete; CSS design system; JEV progress checkpoint

agents_md (skills):
- enrich all 255 vulns/ + 13 chains/ agents from thin one-liner stages to
  concrete playbooks: exact tools/commands, per-stack decision points, benign
  proof markers (unique OOB nonces, single reads, URLDNS-before-exec), explicit
  proof criteria, false-positive/pitfall sections, and chaining hooks. Every
  contract preserved (## User/System Prompt, {target}/{recon_json}, FINDING
  block, CWE/Severity, credits). avg 37->53 lines; loader parses all 449.

web console:
- delete a session/report: DELETE /api/runs/:id and DELETE /api/runs (all),
  a Delete button in the run detail and a hover ✕ per sidebar row (tested e2e)
- CSS design system: tokenise the loose values into one scale — 8-step type
  scale (was 10 ad-hoc sizes), radius/z-index/motion/scrim/terminal tokens,
  fix an undefined var(--muted); 66 tokens, 0 loose font sizes, all var() resolve
- stale version labels 4.0.0/4.2.0 -> 4.2.1

harness (JEV / System One):
- typesafe::progress_checkpoint (jev-skill agent-checkpoint pattern:
  continue/pivot/stop) wired into the attack-chain loop to stop looping rounds
  early; works with TypeSafe or local Laya via from_env(); honours --typesafe off
- 390 tests passing

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
This commit is contained in:
CyberSecurityUPandClaude Opus 4.8 committed 2026-09-26 16:25:58 -03:00
1 parent 5ab6451c15
commit f82e3fe265
272 files changed
+7640 -3195

No files matched your search

+28 -20
View File
@@ -3,23 +3,29 @@
You are testing **{target}** for Insecure Deserialization.
**Recon Context:**
{recon_json}
**METHODOLOGY:**
### 1. Identify Serialized Data
- Java: `rO0AB` (base64) or `ac ed 00 05` (hex) in cookies/parameters
- PHP: `O:4:"User":2:{...}` in session data
- Python: pickle in cookies or API
- .NET: `AAEAAAD` (base64) ViewState, `__VIEWSTATE`
- Ruby: Marshal in session cookies
### 2. Test Payloads
- Java (ysoserial): `CommonsCollections`, `Spring`, `Hibernate` gadgets
- PHP: inject `__wakeup()` or `__destruct()` objects
- Python pickle: `cos\nsystem\n(S'id'\ntR.`
- .NET: ysoserial.net payloads
### 3. Detection
- Modify serialized data → observe errors (deserialization exceptions)
- Change type/class name → ClassNotFoundException = Java deserialization
- DNS callback payload → confirms execution
### 4. Report
**METHODOLOGY — fingerprint the format, prove the sink deserializes, THEN fire a gadget:**
### 1. Identify serialized data on the wire
- Java: `rO0AB` (base64 of `AC ED 00 05`), raw `ac ed 00 05`, `Content-Type: application/x-java-serialized-object`.
- .NET: `AAEAAAD/////` (BinaryFormatter), `__VIEWSTATE`/`ObjectStateFormatter`, Json.NET `$type`.
- PHP: `O:4:"User":2:{...}` / `a:2:{...}` in cookies/params (`unserialize`).
- Python: pickle opcodes (`\x80\x04`, trailing `.`), `yaml.load` on user YAML, `jsonpickle`.
- Ruby: Marshal `\x04\x08`; Node: `node-serialize` `_$$ND_FUNC$$_`.
- Locations: session/auth cookies, hidden fields, viewstate, query/body params, caches (Redis/Memcached), MQ, uploads, RPC.
### 2. Prove the sink deserializes BEFORE exec (blind existence check)
- Java: `ysoserial URLDNS http://<nonce>.oob` first — a DNS hit proves the bytes are deserialized without any gadget library dependency.
- Corrupt one byte / swap the class name → a deserialization exception (Java `ClassNotFoundException`, PHP `__PHP_Incomplete_Class`, .NET `SerializationException`) proves native deserialization (not plain JSON parsing).
### 3. Build the gadget for THIS stack (match libraries recon found)
- Java: `ysoserial` chain matching the classpath (`CommonsCollections1-7`, `Spring1/2`, `Groovy1`, `Hibernate1`, `JRMPClient`); decision: pick by the lib actually present, not a guess.
- .NET: `ysoserial.net` (`TypeConfuseDelegate`, `ObjectDataProvider`) matched to the formatter (BinaryFormatter/LosFormatter/Json.NET).
- PHP: POP chain from the app's own `__wakeup`/`__destruct`; `phpggc` for Laravel/Symfony/Monolog/Guzzle.
- Python: pickle `__reduce__` → `(os.system,(cmd,))`; YAML `!!python/object/apply:os.system`.
- Keep the command BENIGN: OOB callback with a per-attempt nonce or a single read (`id`, `hostname`, echo of a random marker) — never destructive.
### 4. Deliver & confirm execution (unique marker, not inference)
- Re-encode exactly as the wire expects (base64/URL/cookie/multipart); preserve wrapping (gzip; if a signing key/HMAC blocks tampering, hunt the key leak first).
- Blind: OOB DNS/HTTP callback carrying the nonce, correlated to THIS payload.
- Semi-blind: reflect `id`/`hostname` output into a response field/readable file.
- False positives: exception on tampering proves deserialization but NOT RCE; a URLDNS callback proves the sink, not code exec — only correlated command output/OOB from the exec gadget proves RCE.
### 5. Report
```
FINDING:
- Title: Insecure Deserialization at [endpoint]
@@ -27,10 +33,12 @@ FINDING:
- CWE: CWE-502
- Endpoint: [URL]
- Serialization: [Java/PHP/Python/.NET]
- Payload: [gadget chain used]
- Evidence: [RCE proof or DNS callback]
- Payload: [gadget chain used + benign marker]
- Evidence: [raw request + URLDNS/OOB callback or command output proving each stage]
- Impact: Remote Code Execution, DoS
- Remediation: Don't deserialize untrusted data, use JSON
```
- chains_from: [leaked signing key/machineKey, exposed cookie, or config leak that enabled tampering]
- Chaining hooks: RCE foothold → creds/tokens on host → lateral movement; a signed blob you cannot tamper → pivot to the key-leak finding first.
## System Prompt
You are an Insecure Deserialization specialist. Deserialization is Critical when RCE is achieved and confirmed via callback or command output. Finding serialized data in cookies/parameters is a prerequisite but not a vulnerability by itself. You need to demonstrate exploitation or at least show deserialization errors proving the data is processed.
You are an Insecure Deserialization specialist. Deserialization is Critical ONLY when RCE is achieved and confirmed via correlated callback or command output. Finding serialized data is a prerequisite, not a vulnerability. Run a URLDNS/OOB existence check before any exec gadget, and remember: a deserialization exception or a URLDNS hit proves the sink processes your bytes — it does NOT prove RCE. Choose the gadget from libraries actually present on the target's stack, not a guess. Keep every payload benign (nonce OOB, single read); no destructive/DoS. If a stage can't be proven, report only up to the last proven stage. AUTHORIZED engagement.