mirror of https://github.com/CyberSecurityUP/NeuroSploit.git synced 2026-09-29 04:21:44 +02:00

Files

T

CyberSecurityUPandClaude Opus 5 40b047b9e7 feat(agents): 10 skills for techniques the catalogue was missing

Written against what disclosed bug-bounty reports and public write-ups actually
turn up, and chosen by diffing the existing 245 skills rather than restating
them. Each one is built around the same discipline the harness now enforces:
the client-side discovery is a lead, and the finding is what the SERVER did.

Browser instrumentation and client trust:
- browser_runtime_hooking — hook fetch/XHR/postMessage/storage/WebCrypto at
  document_start to find what the client is trusted to decide, then prove the
  server accepts the tampered value with an independent read-back.
- prototype_pollution_gadget_hunt — pollution is a precondition, not a finding.
  Hunt the gadget with a getter on Object.prototype that breaks into the
  debugger, quote it as file:line from the bundle, and prove the end effect.
- js_source_deep_analysis — recover original sources from source maps, extract
  the API surface the UI never shows, and pair every client-side discovery with
  the server request that confirms or refutes it.
- client_side_path_traversal — the evidence is which URL left the browser, and
  it is Low until chained to something otherwise unreachable.

Authentication:
- webauthn_passkey_downgrade — passkeys as a system: the usual finding is a
  weaker factor nobody removed, or enrollment needing only a session.
- email_verification_bypass — the gate is normally on the login screen, not the
  API; address normalisation is where pre-account-takeover lives.
- jwt_jku_x5u_injection — whether the token gets to choose its own verifier.

Server-side reach and money:
- ssrf_render_pipeline — PDF/screenshot/unfurl renderers browse on the server's
  behalf, usually with no egress restrictions and often with JS enabled; the
  returned document is the exfiltration channel.
- payment_webhook_forgery — prove the ORDER changed state, not that the
  endpoint returned 200; idempotency failures are their own finding.
- presigned_url_abuse — the bug is what the API is willing to SIGN, which is an
  IDOR with a cloud signature on top.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>

2026-09-14 00:57:45 -03:00

2.7 KiB

Raw Blame History

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:

1. Map every way in

A passkey is only as strong as the weakest enrolled factor. List all of them:

Password login, magic link, OTP/SMS, social login, recovery codes, support-driven reset
Whether a passkey REPLACES those or merely joins them

2. Downgrade paths

Does the login page offer "use password instead" without any signal to the account owner?
Can an attacker force the fallback by omitting/failing the WebAuthn step?
Is userVerification requested as discouraged/preferred rather than required?
Does the server accept an assertion with "up": false / missing UV flag?

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
Is the new credential bound to the account server-side, or taken from a client-supplied userHandle?
Is rpId validated, or can a subdomain register credentials for the apex?

4. Assertion checks (verify server-side, not in the UI)

Is challenge single-use, random and bound to the session?
Are origin, rpIdHash, signCount and the signature actually verified?
Replay a previous assertion verbatim — is it accepted twice?

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)?

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]
- Server verdict: [what the server accepted]
- 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, omit the flag, enroll from a stolen session, and show what the SERVER did. A challenge accepted twice, a passkey enrolled without re-auth, or recovery that quietly outranks the passkey are each a finding on their own; describe exactly which one you observed.

2.7 KiB Raw Blame History