Vuln Scanner: operator's manual and detection catalog

What this tool is ¶

qbit404/scanner is a fingerprint-driven, signature-matched non-intrusive scanner. It does not exploit. It probes with safe, well-known requests and matches responses against an internal catalog of known-vulnerable signatures (CVE-tagged), misconfigurations, and known-bad header / cookie / TLS profiles. The matchers are pure pattern + version arithmetic; nothing the scanner sends is destructive or rate-amplifying.

It is meant for systems you own or have written authorization to test. Pointing it at third parties is a felony in most jurisdictions.

What it covers ¶

The catalog ships in 7 modules. Modules can be enabled/disabled per scan.

1. TLS hygiene ¶

• Cert chain validity, expiry < 30 days
• Self-signed in production
• Weak signature alg on cert (MD5, SHA-1, RSA < 2048)
• Cipher suite enumeration; flags any of: NULL, EXPORT, RC4, 3DES, CBC-mode in TLS 1.0/1.1
• Protocol versions: any of TLS 1.0 / 1.1 / SSL 3.0 / SSL 2.0 accepted
• HSTS missing / max-age too low / no includeSubDomains
• OCSP stapling absence
• Heartbleed (CVE-2014-0160) — sends benign heartbeat with normal payload length, checks response length
• ROBOT (CVE-2017-13099) — fingerprint, no exploitation
• PQ readiness: probes for hybrid KEX advertisement (X25519MLKEM768); flags absence on internet-facing endpoints

2. HTTP headers and cookies ¶

• Missing: Content-Security-Policy, X-Content-Type-Options, X-Frame-Options / frame-ancestors, Referrer-Policy, Permissions-Policy
• CORS: Access-Control-Allow-Origin: * with credentials
• Cookies without Secure, HttpOnly, SameSite
• Server / X-Powered-By / X-AspNet-Version disclosure
• Cache-Control on authenticated endpoints

3. Known framework / CMS fingerprints ¶

The scanner walks a list of well-trodden paths (/wp-login.php, /administrator/, /.git/config, /server-status, /actuator/env, /api/v1/swagger.json, /.env, ...) and matches body / header signatures against the CVE feed:

• WordPress < 6.4.x — exposed /wp-json/wp/v2/users (CVE-2017-5487-style enumeration)
• Drupal < 7.58 — Drupalgeddon2 (CVE-2018-7600) fingerprint
• Joomla < 3.4.6 — RCE chain fingerprint
• Apache HTTP < 2.4.49/2.4.50 — Path traversal (CVE-2021-41773 / 42013)
• nginx < 1.20.0 — DNS resolver heap overflow (CVE-2021-23017)
• Tomcat < 9.0.71 — ghostcat (CVE-2020-1938)
• Spring Boot Actuator exposed /env, /heapdump, /jolokia
• Jenkins script console, anonymous read
• Confluence (CVE-2022-26134, CVE-2023-22515) fingerprints
• Atlassian Jira /rest/api/2/user/picker?query=
• GitLab unauthenticated user enumeration
• Log4Shell (CVE-2021-44228) — JNDI fingerprint in HTTP headers via canary callback (only if you supply your own canary host)

4. API / OpenAPI surface ¶

• Spec at /openapi.json / /swagger.json / /v2/api-docs — enumerate endpoints, flag any returning 200 to anonymous
• BOLA / IDOR fingerprints: id path parameters whose responses change but auth scope doesn't
• Verbose error pages leaking stack traces
• GraphQL introspection enabled in production

5. Authentication & session ¶

• Login form posts over HTTP
• Login response leaks user-enumeration (different error for "no such user" vs "wrong password")
• JWT alg: none accepted
• JWT signed with weak HS256 secret (offline dictionary against a captured token)
• OAuth: open redirect URIs, missing PKCE on public clients
• Session fixation: server accepts pre-set session cookie

6. Cloud / metadata ¶

• Open S3 buckets via known naming conventions
• Public Azure blob containers
• GCS bucket listing without auth
• Kubernetes /api/v1/namespaces anonymous
• Cloud metadata endpoint reachable through SSRF probes (only with explicit target opt-in)
• Public docker registry /v2/_catalog

7. Quantum-readiness audit ¶

• TLS endpoint does/does not advertise PQ hybrid KEX
• JWT alg field includes EdDSA / RSA-PSS only — flag for hybrid migration
• Certificate signature alg — flag classical-only for assets with > 5y validity
• Code-signing cert chain freshness
• Disclosed Server: fingerprint mapped against the qbit404 PQ-ready tracker

What it does not do ¶

• It does not exploit. The Log4Shell check requires you to provide a canary host so the scanner can confirm a callback; it never JNDI-loads a payload.
• It does not brute-force live login forms beyond the JWT offline dictionary.
• It does not perform DoS, traffic amplification, or session storm.
• It does not pivot. Each target is scanned in isolation.

How to use it ¶

The frontend at /tools/scanner walks you through:

1. Authorization check: confirm you have permission to scan the target.
2. Target input: https://example.com or an IP range you own.
3. Module selection: TLS, headers, CMS, API, auth, cloud, PQ — toggle.
4. Intensity: light (10 req), normal (50 req), thorough (250 req). Defaults to normal.
5. Run.

The result is a triaged report:

• Critical: known RCE / auth bypass with public exploit. Drop everything.
• High: vulnerable version + public exploit + standard config. Patch this week.
• Medium: misconfig with credible attack path. Schedule.
• Low: hygiene. Roll into next quarterly hardening pass.
• Info: no finding, just signal.

Each finding includes: CVE / CWE id, source rule, raw evidence (request/response snippet), and a remediation paragraph with the upgrade target or config flag.

Output formats ¶

• HTML report (default): inline triage, ready to attach to a ticket
• SARIF 2.1.0: code-scanning tab in GitHub / GitLab
• JSON: pipe into your SIEM
• CycloneDX VEX: for SBOM-aligned tracking

Frequency ¶

A scan is a snapshot. For services with frequent deploys, schedule it on CI post-deploy and on a weekly cron. The cost of a scan against your own infra is negligible; the cost of not knowing is not.

False positives ¶

• Version-based detection sometimes fails behind reverse proxies that strip the Server header. The scanner falls back to behavioral fingerprints, which are noisier.
• WAFs (Cloudflare, AWS WAF) catch and 403 some probes — flagged as WAF_BLOCKED. Re-run authenticated to bypass the WAF and assess the origin.
• TLS modules can mis-detect on endpoints that present different cipher suites per SNI.

If you hit one, file an issue with the request/response pair; the catalog updates weekly.

Legal ¶

You own this when you point it at your stuff. You do not own this when you point it at someone else's stuff. The scanner refuses to run against domains in its built-in deny-list (browsers, government, banks) without an explicit --i-have-written-authorization flag, and even then it writes an audit-log entry to your local machine.

Vulnerability scanning is hygiene, not a substitute for design. The catalog only finds what's been seen before. Use the zero-day hunter for the rest.