From c77f69c6b21f99c865a257a6109cc39931f4436c Mon Sep 17 00:00:00 2001 From: officialfrancismendoza Date: Thu, 1 Oct 2026 20:47:39 +0700 Subject: [PATCH] Update PENTEST_TASKS_ADVANCED.md with cryptography instructions (#15) --- docs/PENTEST_TASKS_ADVANCED.md | 19 ++++++++++++++++++- 1 file changed, 18 insertions(+), 1 deletion(-) diff --git a/docs/PENTEST_TASKS_ADVANCED.md b/docs/PENTEST_TASKS_ADVANCED.md index 46eb3c4..0006243 100644 --- a/docs/PENTEST_TASKS_ADVANCED.md +++ b/docs/PENTEST_TASKS_ADVANCED.md @@ -1,4 +1,4 @@ -# OpenHack — 100 Advanced / Staff-Level Pentest Tasks +# OpenHack — Advanced / Staff-Level Pentest Tasks The hard stuff. These are the multi-step, chain-required, reasoning-heavy tasks a top-tier bug-bounty hunter or staff security engineer actually does to find @@ -137,6 +137,23 @@ source reasoning across trust boundaries, protocol quirks, or exploit chaining. 99. Full assessment of `@.`: give me the single highest-severity exploitable bug with a working PoC and nothing else — no inventory dump. 100. Take `https://TARGET`: recon → pick the one most promising attack surface → develop and prove one real, high-impact bug end to end. +## 14 · Cryptography / key management / protocol misuse +101. In `@.`, trace every cryptographic RNG call used for keys, nonces, IVs, salts, reset tokens, or authentication challenges and identify where a non-CSPRNG, insufficient entropy, predictable seed/state, or accidental reuse makes a security value recoverable or forgeable. +102. In `@.`, find every AEAD use (AES-GCM, AES-CCM, ChaCha20-Poly1305, etc.) and determine whether a `(key, nonce)` pair can ever repeat — trace nonce construction, persistence, concurrency, crash/restart behavior, and key rotation. +103. In `@.`, find encryption using CBC, CTR, CFB, stream encryption, or another unauthenticated construction and determine whether attacker-controlled ciphertext can be modified to produce a useful plaintext change, malleability attack, or decryption oracle. +104. Audit `@.` for AES-GCM nonce reuse and, where reachable, prove the confidentiality or integrity consequence from ciphertexts produced under the same `(key, nonce)` pair rather than merely flagging the repeated nonce. +105. In `@.`, trace password handling from registration → storage → verification and identify use of a fast/general-purpose hash, unsalted hashes, weak work factors, obsolete KDF settings, or parameters that materially weaken offline resistance. +106. In `@.`, find MAC, authentication-token, signature, or secret comparisons performed with timing-sensitive equality and determine whether attacker-observable timing creates a practical oracle across the actual request boundary. +107. Audit `@.` for RSA misuse — textbook RSA, unsafe or legacy padding in a security-sensitive context, incorrect padding verification, or attacker-influenced OAEP/PSS parameters — and determine whether the misuse creates an oracle, forgery condition, or confidentiality failure. +108. In `@.`, find signature verification where the public key, algorithm, curve, parameters, certificate, key id, or trust source is attacker-influenced; trace whether this permits algorithm/key confusion or verification under an unintended identity or trust root. +109. Trace a long-term cryptographic secret in `@.` from generation → storage → distribution/loading → use → rotation/revocation and find where its lifecycle breaks the intended trust boundary (hard-coded/committed key, logging, plaintext secret storage, key stored beside protected data, excessive sharing, or ineffective rotation). +110. In `@.`, find ECDSA/DSA signing and determine whether per-signature nonce generation can repeat, become biased/predictable, or otherwise permit private-key recovery; trace the randomness/deterministic-nonce implementation rather than assuming the library is safe. +111. Audit `@.` for DH/ECDH using attacker-controlled public values or parameters and determine whether the implementation performs the validation required by the selected group/curve; assess invalid-point, small-subgroup, identity-element, or related key-agreement failures where applicable. +112. In `@.`, find a custom encryption/authentication composition and determine whether ordering, unauthenticated metadata, parsing, error behavior, or verification timing creates a padding, format, decryption, or authentication oracle. +113. In `@.`, trace KDF/HKDF-derived material across its consumers and determine whether inadequate context/domain separation causes the same key material to cross protocol, algorithm, tenant, direction, or security-purpose boundaries that require independent keys. +114. In `@.`, trace TLS/certificate verification from connection setup to trust decision and identify a reachable path that disables hostname verification, bypasses certificate-chain validation, trusts arbitrary/self-signed certificates, pins the wrong identity, or otherwise reduces authenticated TLS to encryption without reliable peer authentication. +115. Find the highest-impact cryptographic misuse in `@.` where the primitive itself may be secure but its composition, parameters, randomness, key lifecycle, state management, or protocol integration makes the resulting system exploitable — prove the path from source-level misuse to concrete security impact. + --- ### Grading these (for the operator)