Network services, DNS, TLS, email, and appliances

Open canonical module and reverse references

1. 01Map HTTP processing layers
2. 02Prove isolation
3. 03Establish normal cache behavior
4. 04Change one interpretation input
5. 05Verify second controlled client
6. 06Purge and document

At each step: retain the control → record the observation → continue only while the next boundary is understood.

Setup and invariant

Use a local proxy plus application, or a program-provided isolated cache namespace and upstream pool. Record protocol on each hop, request normalization, cache key, cache policy, authentication placement, and whether connections are reused. The invariant is: all layers agree on the request target, request boundary, and which client may receive a cached representation. These tests can affect requests other than your own; an unproven random query parameter is not isolation.

Numbered test procedure

1. Map the layers. From configuration or operator-provided logs, identify browser → CDN/proxy → application. Capture an ordinary controlled URL from two independent clients. Record Age, cache-status headers where present, Vary, Cache-Control, effective host/path, and origin logs. A header name or latency difference alone does not establish caching.
2. Prove the test namespace. Configure a dedicated local path or verified cache-key component. Request two distinct canary paths and confirm they remain separate through origin and cache logs. A query string may be ignored, normalized, or partially keyed. If separation cannot be established in a shared environment, keep mutation experiments in the replica.
3. Test cache poisoning. On a fresh isolated key, vary one input that changes origin output but may not be in the cache key, such as an observed forwarding header used in a generated absolute link. Use a harmless marker host under your control. Make a second request without that input and inspect whether the marker persists. Confirm a control key remains clean. The evidence must show an altered representation served from shared cache to the second controlled client. Cache poisoning.
4. Test cache deception. Create a private page containing A's unique synthetic marker. In the lab, compare the canonical path with one suffix/path-normalization variant that the origin resolves to the same page but the cache may treat as static. Request that variant as A, then as anonymous B. Verify B receives A's marker because of caching; compare B's direct origin response or a fresh key. Sharing via an intentionally public capability URL is not deception. Cache deception.
5. Test parsing agreement in isolation. Capture the bytes seen by front end and backend for a normal request. In the lab, create one malformed framing case and observe whether both components reject it consistently. For ambiguous length/framing, verify how many requests each layer parsed and where the second controlled request begins. Do not treat a timeout as proof, or use unrelated users' responses to demonstrate desynchronization. HTTP/1.1 framing and HTTP/2-to-HTTP/1 translation must be assessed separately. HTTP/1.1 framing, Request smuggling.
6. Verify consequence and clean up. Save origin/cache logs, exact requests, normalized targets, cache keys, and client identities. Purge only the dedicated test namespace or restart the disposable cache. Report whether the outcome is poisoned content, private response disclosure, authorization normalization bypass, or request-boundary disagreement; those are distinct findings.

Command card

These ordinary requests establish a local cache baseline. Configure /bb-cache/case-01 and /bb-cache/case-02 as separate keys in your own proxy first. A later poisoning probe must vary only a specific source-identified input.

mkdir -p evidence/cache
curl -q --noproxy '*' --max-time 10 -D evidence/cache/first.h \
  -o evidence/cache/first.txt http://127.0.0.1:8080/bb-cache/case-01
curl -q --noproxy '*' --max-time 10 -D evidence/cache/second.h \
  -o evidence/cache/second.txt http://127.0.0.1:8080/bb-cache/case-01
curl -q --noproxy '*' --max-time 10 -D evidence/cache/control.h \
  -o evidence/cache/control.txt http://127.0.0.1:8080/bb-cache/case-02

Report threshold and checklist

Report a controlled second-client effect or demonstrated parser disagreement with a meaningful security boundary. Mere caching, unexpected 400/502 responses, reflected Host values, and differences caused by the testing proxy are common false positives.

• Cache namespace and upstream isolation verified.
• Every HTTP hop and protocol recorded.
• Normal, mutated, second-client, and clean-key controls saved.
• No production response-queue capture or broad desync probing.
• Test cache entries purged after evidence collection.

Local curl examples bypass environment proxies with --noproxy '*'; -q alone only suppresses curl configuration files. These snippets target loopback and do not follow redirects. curl manual.

Cache semantics and revocation control

Interpret response directives precisely: unqualified no-cache permits storage but requires validation before reuse; no-store prohibits storage/reuse subject to the specification's defined exceptions; unqualified private prevents shared-cache storage but permits private-cache storage. Set-Cookie alone does not disable caching. Requests containing Authorization have special shared-cache restrictions, with explicit exceptions such as public and s-maxage; cookie-authenticated requests need their own correct response policy and cache partitioning. Read the effective configuration and observe behavior. RFC 9111, sections 3.5, 5.2 and 7.3.

In an isolated namespace, compare A, anonymous B, and a fresh control key after A changes or deletes the private marker. Also exercise one normal conditional request if the application uses validators. Inspect which identity the origin checked and which stored body the cache reused after a 304. Do not infer privacy from an Age: 0, absent cache header, or an initial miss. Report stale post-revocation access against the product's promised lifecycle, distinguishing a previously downloaded copy from a newly served shared response.

• Storage, revalidation and private/shared-cache behavior distinguished.
• Fresh, cached and post-change responses compared where applicable.

Open canonical module and reverse references

1. 01Choose contract
2. 02Build harness
3. 03Instrument target
4. 04Fuzz within bounds
5. 05Minimize root cause
6. 06Verify consumer impact

At each step: retain the control → record the observation → continue only while the next boundary is understood.

Choose an attacker-relevant parser contract#

Select a public API and a realistic input boundary: imported image, archive, document, packet, model file, project metadata, or CLI input file. Record who supplies bytes, the consumer's preprocessing, format limits, parser options, and the privilege of the process. Fuzzing an internal helper with impossible arguments may reveal a harness defect rather than a violated library contract.

Keep the first harness narrow: one parse operation, deterministic configuration, fresh state for each input, bounded allocations, and cleanup on both success and failure. Remove network and uncontrolled filesystem side effects. Seed with a few valid, small representative samples to reach deeper code; an all-random corpus may spend every iteration failing the magic-header check.

Harness and build cheat sheet#

The following is a template: product_parser.h, ProductDocument, and the parser functions are placeholders to replace with the target's documented API. Return/error ownership must follow that API. The commands have not been executed here.

#include <cstddef>
#include <cstdint>
#include "product_parser.h"

extern "C" int LLVMFuzzerTestOneInput(const uint8_t* data, size_t size) {
    if (size > 65536) return 0;
    ProductDocument* doc = product_parse(data, size);
    if (doc != nullptr) product_document_free(doc);
    return 0;
}

Build the target library itself with compatible sanitizer and coverage instrumentation; instrumenting only the harness misses much of the parser's behavior. Replace the source list with its reviewed build recipe. The example assumes Clang and a compatible C++ project. AddressSanitizer build guidance.

clang++ -g -O1 -fno-omit-frame-pointer \
  -fsanitize=fuzzer,address,undefined -fno-sanitize-recover=undefined \
  ./fuzz_parser.cc ./parser.cc -o ./fuzz_parser
mkdir -p ./corpus ./artifacts ./evidence
./fuzz_parser ./corpus -max_total_time=120 -timeout=2 \
  -rss_limit_mb=512 -max_len=65536 -artifact_prefix=./artifacts/

Add reviewed seed files before running. libFuzzer's time, input-length, timeout, and RSS settings bound the campaign; they are not a VM resource boundary. Run inside your local disposable environment with external memory/CPU limits appropriate for the workload. Track new coverage and distinct root causes rather than raw executions. libFuzzer reference.

Interpret the failure precisely#

-fno-sanitize-recover=undefined makes the selected UBSan failures terminate instead of allowing a fuzzing run to continue after a diagnostic, which helps preserve reproducible failing inputs. UBSan checks selected undefined behaviors, not every arithmetic error. Unsigned integer wrap is defined in C/C++ and is not part of the default undefined group; choose additional checks when the target's threat model requires them. UndefinedBehaviorSanitizer.

Minimize and verify the consumer#

Copy one candidate into ./artifacts/repro.bin, then minimize with a unique output path. Preserve the original input, toolchain, build flags, revision, and symbolized trace.

./fuzz_parser -timeout=2 -rss_limit_mb=512 ./artifacts/repro.bin
./fuzz_parser -minimize_crash=1 -max_total_time=60 -timeout=2 -rss_limit_mb=512 \
  -exact_artifact_path=./artifacts/minimized.bin ./artifacts/repro.bin

Replay the minimized bytes through a supported consumer in the pinned OSS lab. If the consumer rejects them before calling the library, report the library contract separately and leave consumer exposure unproven. A sanitizer crash is not proof of remote code execution, and its absence in an optimized build does not erase a confirmed memory-safety defect.

Hypothetical root cause: a header count is multiplied into a narrow allocation size, then a wider loop trusts the original count. Preserve the values, allocation site, failing access, and missing bound. The fix should bind accepted count to available input and checked allocation size; merely suppressing the crash is insufficient.

• Public API and ownership contract respected.
• Target code, not only harness, instrumented.
• Resources, seeds, revision, and toolchain recorded.
• Minimal input reproduces the same root cause.
• Normal input succeeds in affected and fixed builds.
• Library impact and real consumer exposure are stated separately.

Replay timeout and memory artifacts under the same resource limits as discovery. A minimized crash must retain the original root cause; a shorter input that fails differently is not equivalent evidence.

Open canonical module and reverse references

1. 01Pin owned services and trust promise
2. 02Collect exact protocol baseline
3. 03Run one paired control
4. 04Correlate protocol and receiver evidence
5. 05Remove synthetic mail and fixtures

At each step: retain the control → record the observation → continue only while the next boundary is understood.

Setup and invariant#

Treat DNS, TLS and SMTP as separate services with explicit owners, addresses, ports and test methods. Use an owned miniature zone, known certificate hostname and researcher-controlled mail sender and receiver. A service must enforce the claimed ownership, peer identity or relay boundary. Define the expected result before probing: public DNS answers are normally intentional; private zone transfer or unauthenticated external relay may not be.

Procedure#

1. Inspect DNS ownership without claiming resources. Record the exact CNAME or delegation chain, provider error, TTL and owner-supplied resource inventory. A missing backing resource creates a takeover candidate; it does not prove that another account can bind the hostname. Check provider validation and reservation rules. Do not claim dangling resources as a generic proof step. Azure dangling DNS guidance

2. Separate transfer and recursion. AXFR requests the zone contents, so test only an owned small zone or an explicitly supplied fixture. Compare the permitted transfer source with the denied source. For recursion, query one unique name in an owned authoritative zone through the tested resolver; correlate the authoritative log with the resolver response. Cached answers and the RA flag alone do not prove unrestricted recursion. AXFR protocol, BIND configuration

3. Verify TLS identity as the real client. Use the intended hostname, SNI, port and trust store. Compare the valid fixture certificate with an owned wrong-host certificate in a local client integration test. OpenSSL diagnostics confirm the fixture but do not establish that the product's client accepts an invalid identity. Certificate-chain trust and hostname matching both matter. OpenSSL s_client

4. Test SMTP relay with one synthetic message. Only when message delivery is allowed, use sender and receiver domains controlled by the researcher and outside the tested relay's local destination domains. Start from an untrusted source address with no SMTP authentication. The secure control rejects external-to-external relay; the permitted control uses the documented authenticated submission path. A test from an allowlisted office or VPN address does not prove an open relay.

5. Correlate SMTP acceptance with delivery. Retain the envelope, transcript, unique subject marker and receiver logs. A successful RCPT response or queue ID alone does not establish final delivery. Keep relay testing separate from SPF, DKIM and DMARC alignment findings. For sender-identity tests, the receiving policy and trusted authentication results determine the demonstrated impact. SMTP protocol

Command card#

Replace all example addresses only with owned fixtures. Run one command at a time. The AXFR example is limited to the small fixture zone; it retrieves that zone.

timeout 10 dig -r @192.0.2.53 fixture.example AXFR \
  +tcp +time=2 +tries=1

timeout 15 openssl s_client -connect tls.fixture.example:443 \
  -servername tls.fixture.example \
  -verify_hostname tls.fixture.example \
  -verify_return_error -brief </dev/null

timeout 20 swaks --config --server relay.fixture.example --port 25 \
  --timeout 10 --from probe@sender.fixture.example \
  --to receiver@recipient.fixture.example \
  --header 'Subject: Bounty relay fixture 2026-01' \
  --body 'Synthetic authorized relay test; no action required.'

Use a clean shell with no SWAKS_OPT_* overrides; --config disables automatic configuration files, not environment settings. Confirm the transcript contains no AUTH and exactly one intended recipient. The fixture message contains no credentials; this example does not claim transport-security testing. BIND dig, Swaks reference

Result and cleanup checklist#

• Public records distinguished from restricted zone contents.
• Dangling DNS labeled candidate unless claimability is established.
• TLS finding reproduced in the product's actual client.
• Relay test source is outside trusted networks.
• Acceptance, queueing and delivered fixture correlated.
• No real recipients contacted; synthetic mail and temporary zone/certificate fixtures removed.

Open canonical module and reverse references

1. 01Record exact endpoint and allowed method
2. 02Establish authenticated baseline
3. 03Read one forbidden fixture
4. 04Compare identity and network controls
5. 05Document and remove canaries

At each step: retain the control → record the observation → continue only while the next boundary is understood.

Setup and invariant#

Record one service row: owner, exact IPv4 or IPv6 address, hostname, transport, port, product build, authentication method and intended access boundary. A hostname in web scope does not automatically include every backing service. Prepare a restricted account, an allowed account and one synthetic key, row, queue or management fixture. A network position or low-privilege account must not gain the protected data or administrative operation outside its stated permissions.

Use version banners only to select hypotheses. Vendor backports and disabled features can invalidate a banner-to-CVE match. First establish a normal connection, intended authenticated operation and expected rejection. Keep source network and timestamps constant when comparing identities.

Procedure#

1. Separate reachability from authority. Record a connection outcome without treating an open port as a vulnerability. Check whether the service is intentionally public, behind mutual TLS or protected by native authentication. A health response is not administrative access.

2. Use one exact resource. For Redis, request only the agreed canary key; do not run keyspace enumeration, configuration changes or flush commands. Compare anonymous access, the permitted principal and the restricted principal. Redis network protection, authentication, ACLs and TLS solve different parts of this boundary. Redis security

3. Check connection rules and database grants independently. In PostgreSQL, examine the owner-supplied host-based authentication rule selected by connection type, source, database and user. Establish whether authentication genuinely happened, then test permission for one fixture row. A trusted local administration connection is not evidence of internet exposure. PostgreSQL host authentication

4. Model queues as stateful resources. In an isolated broker, create two fixture virtual hosts and named queues. Compare whether A can declare, publish to or consume B's fixture according to the contract. Use a single marked message and account for acknowledgement behavior; consuming production messages changes application state. Broker login does not imply permissions across all virtual hosts. RabbitMQ access control

5. Evaluate management APIs and network parity. For an owned Docker daemon, review listener and client authentication configuration; use only an approved metadata endpoint for the initial proof. Do not create privileged containers to confirm broad authority on production. Compare an explicitly owned IPv4 and IPv6 service only when both are in scope: different exposure is relevant when it defeats the same promised restriction. Docker daemon protection

Command card#

The Redis endpoint below is an isolated local fixture. The environment removal prevents an inherited password from contaminating the unauthenticated control. The database example uses the supplied test account and private password file, with TLS identity verification and a read-only transaction.

env -u REDISCLI_AUTH timeout 10 redis-cli \
  -h 127.0.0.1 -p 16379 --raw GET bounty:canary

timeout 15 psql -X -w \
  "host=db.fixture.example port=5432 dbname=bounty_fixture user=lab_low sslmode=verify-full sslrootcert=./fixture-ca.pem connect_timeout=5 options='-c statement_timeout=3000'" \
  -v ON_ERROR_STOP=1 \
  -c "BEGIN READ ONLY; SELECT marker FROM bounty_canary WHERE id=1; ROLLBACK;"

An unauthenticated marker demonstrates read access to that fixture. NOAUTH, NOPERM, connection failure and an absent value mean different things; compare the known-good control. For PostgreSQL, distinguish TLS failure, authentication failure and SQL permission denial. Credentials can come from a password file even with -w; that flag disables prompting, not password authentication. Redis CLI, PostgreSQL connection parameters, psql options

Evidence, false positives and cleanup#

Save the endpoint, source, verified account, precise operation, response, fixture ownership and comparison. Public service banners, intentionally anonymous health checks and intended shared queues are not equivalent to data exposure. Reuse authorization matrices for per-resource checks and identity/session testing for revocation behavior.

• Allowed and denied controls have working connectivity.
• No wildcard reads, real queue consumption or configuration mutation.
• Network access distinguished from authentication and authorization.
• Lab result separated from unverified production applicability.
• Canary records, messages and test accounts removed using their recorded identifiers.

Open canonical module and reverse references

1. 01Document access model
2. 02Observe baseline
3. 03Classify interface
4. 04Check protected capability
5. 05Confirm production state

At each step: retain the control → record the observation → continue only while the next boundary is understood.

Setup and security invariant#

Record exact retail SKU, board revision, installed firmware, provisioning state and whether the case must be opened. Distinguish unauthenticated nearby access, opened-case access and already privileged administrator access. Use a recoverable owned bench device, its matching documentation and a passive capture first. The invariant is: the documented physical access level does not expose a protected command, memory region or reusable credential without the required authorization.

Use the shared authorization matrix for local service roles and identity/session checks when the device also has app/cloud identities. Network callbacks or downloaded configuration belong in the shared SSRF boundary procedure; permission to inspect a purchased device does not extend to unrelated cloud services.

Controlled procedure#

1. Preserve the retail baseline. Photograph configuration and interface locations without unnecessary serial numbers. Record whether secure boot, flash encryption and debug locks are configured, using read-only vendor diagnostics when available. A development board or previously unlocked unit cannot establish behavior on a locked retail device.
2. Observe UART without transmitting. Verify pinout, ground and logic voltage before connecting a receive-only capture adapter or logic analyzer. Keep transmit and power pins disconnected for passive observation. Record baud/framing from documentation or the capture, startup stage and visible data. Do not assume that an RS-232 adapter and a TTL UART use compatible electrical levels.
3. Classify the capability. Separate boot logs, an authenticated console, an unauthenticated restricted monitor and a privileged shell. A prompt string proves neither interactivity nor privilege. If a console is within the lab scope, use a benign identity query or read a synthetic fixture after documenting why that access should be restricted. Compare logged-out versus correctly authenticated behavior. OWASP's internal-interface tests distinguish exposed functionality and authorization. OWASP internal interfaces
4. Assess JTAG/SWD conservatively. Start from documented lock state and allowed read-only diagnostics. Prove a specific protected capability only on a suitable lab unit; avoid unlock, erase, fuse and flash commands. Finding pads or a debug identifier is weaker than reading a protected synthetic memory region. CWE-1191 specifically covers access control for on-chip debug and test interfaces. CWE-1191
5. Classify recovered secrets. In offline firmware, distinguish public certificates, password hashes, test credentials, per-device private keys and fleet-wide credentials. Compare two authentic owned-device images if available. Demonstrate a candidate credential's function on a local service, with redacted output; do not try it against vendor infrastructure. Installed-firmware review includes exposed authentication material and configuration. OWASP installed firmware
6. Confirm and restore. Reproduce after a supported clean reset if needed and safe for the unit. Record what access survived, what was configured during testing and whether recovery succeeded. State emulation or missing hardware limitations explicitly.

Offline command cheat sheet#

rg -n -i 'login|console|debug|jtag|swd|password|private.key' extracted-rootfs
readelf -hW extracted-rootfs/usr/sbin/example-daemon
readelf -lW extracted-rootfs/usr/sbin/example-daemon
sha256sum evidence/uart-capture.bin

These commands inspect an already extracted filesystem and saved UART capture. Replace the daemon with an identified ELF; readelf is not useful for arbitrary compressed firmware. -h shows the ELF header, -l program headers and -W wide output. GNU readelf

Evidence and completion#

Capture access level, wiring diagram, voltage, tool version, production lifecycle state, before/after decisions and protected capability. A verbose boot log, root access granted to an intended administrator, generic missing hardening, or readable public key is not automatically a vulnerability.

• Retail and debug configurations are distinguished.
• Passive observation precedes any authorized interaction.
• Prompt visibility and protected capability are separate findings.
• Secret classification is supported without exposing usable values.
• No irreversible debug unlock or device write was performed.