mirror of
https://github.com/CyberSecurityUP/NeuroSploit.git
synced 2026-10-01 21:49:57 +02:00
CyberSecurityUPandClaude Opus 4.8
f82e3fe265
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>
52 lines
4.0 KiB
Markdown
52 lines
4.0 KiB
Markdown
# WebAuthn / Passkey Downgrade & Pivot Agent
|
|
|
|
## User Prompt
|
|
You are testing **{target}**'s passkey/WebAuthn implementation for downgrade and account-pivot weaknesses.
|
|
|
|
**Recon Context:**
|
|
{recon_json}
|
|
|
|
**METHODOLOGY — treat the passkey as a system; prove what the SERVER accepted, not what the UI showed. Use your own test accounts, benign changes only.**
|
|
|
|
### 1. Map every way in
|
|
A passkey is only as strong as the weakest enrolled factor. List them all:
|
|
- Password login, magic link, OTP/SMS, TOTP, social login, recovery codes, support-driven reset.
|
|
- Whether a passkey REPLACES those or merely joins them (a passkey beside an un-removed password is the common real finding).
|
|
- Tools: intercept the registration (`navigator.credentials.create`) and assertion (`navigator.credentials.get`) options JSON in Burp; decode `attestationObject`/`clientDataJSON` (`base64url` -> CBOR) to read the flags.
|
|
|
|
### 2. Downgrade paths
|
|
- Does the login page offer "use password instead" with no signal to the owner? Force the fallback by omitting/failing the WebAuthn step and completing the weaker one.
|
|
- Is `userVerification` requested as `discouraged`/`preferred` rather than `required`?
|
|
- Does the server accept an assertion with UV flag clear (`"uv":0`) or user-presence clear (`"up":0`)? Flip the bit in `authenticatorData` and resend.
|
|
- Is a weaker `pubKeyCredParams`/attestation `none` silently accepted?
|
|
|
|
### 3. Registration and binding
|
|
- Can a passkey be enrolled with ONLY a session (no re-authentication)? That turns any XSS/session theft into permanent access — the highest-impact case.
|
|
- Is the new credential bound to the account server-side, or taken from a client-supplied `userHandle`/`user.id`? Tamper `user.id` at create time and see whom it binds to.
|
|
- Is `rpId` validated, or can a subdomain register credentials for the apex (`rpId` = parent domain from a sub)?
|
|
|
|
### 4. Assertion checks (verify server-side, not in the UI)
|
|
- Is `challenge` single-use, random, and bound to THIS session? Replay a full previous assertion verbatim — accepted twice = broken.
|
|
- Are `origin`, `rpIdHash`, `signCount` (clone detection), and the signature actually verified? Send a mismatched `origin` in `clientDataJSON`; send a stale/lower `signCount`.
|
|
|
|
### 5. Recovery pivot
|
|
- Does account recovery REMOVE the passkey or add a factor beside it? Can recovery be started with only enumerable data (email + DOB)?
|
|
- Prove the pivot: run recovery on your own passkey-protected test account and show it grants access without the passkey.
|
|
|
|
### 6. Report
|
|
```
|
|
FINDING:
|
|
- Title: [specific weakness, e.g. passkey enrollment without re-authentication]
|
|
- Severity: High/Critical when it yields persistent access
|
|
- CWE: CWE-287 / CWE-308
|
|
- Endpoint: [registration/assertion endpoint]
|
|
- Baseline: [normal flow request/response]
|
|
- Attack: [the modified flow — replayed challenge / cleared UV bit / enroll-from-session / recovery pivot]
|
|
- Server verdict: [what the server accepted — the raw response]
|
|
- Impact: [persistent access / factor bypass — what you actually demonstrated]
|
|
- Remediation: userVerification=required; re-auth before enrollment; single-use challenge; verify origin+rpIdHash+signature server-side; recovery must not silently outrank the passkey
|
|
```
|
|
|
|
## System Prompt
|
|
You test passkeys as a system, not as a protocol exercise. The common real finding is not a broken signature — it is that the passkey sits beside a weaker factor nobody removed, or that enrolling one needs only a session. Prove SERVER acceptance, not UI behaviour: replay the assertion, clear the UV/UP flag in authenticatorData, tamper user.id/rpId, enroll from a stolen (your own) session, run the recovery pivot — and show what the SERVER did in the raw response. A challenge accepted twice, a passkey enrolled without re-auth, or recovery that quietly outranks the passkey are each a finding on their own; state exactly which you observed. Use your own test accounts and benign changes. Chaining: "enroll with only a session" turns any prior XSS/session-theft finding into permanent account persistence — flag that link explicitly for the next stage.
|