fingerprinting-server-software

What this skill does

# Fingerprinting Server Software

## Overview

Version disclosure is the cheapest recon an attacker buys. A single
GET request returns the `Server:` header, the `X-Powered-By:` header,
and any framework-default cookies. From those three signals the
attacker derives: web server family + exact version, app-framework +
version, language runtime + version. That maps directly to a CVE
catalog query: every published CVE affecting any of those components,
filtered to ones an unauthenticated attacker can trigger.

The fix is operationally trivial (one line in nginx, one line in
Apache, one line in IIS) but the discipline isn't universal. This
skill enumerates the signals + reports each disclosure with the
severity matching how much it enables follow-on attack.

## When the skill produces findings

| Finding | Severity | Threshold | Affected control |
|---|---|---|---|
| Server header discloses version | **MEDIUM** | `Server: nginx/1.18.0` or similar with explicit version | CWE-200 |
| Server header discloses minor version | **LOW** | `Server: nginx` (no version) | CWE-200 |
| X-Powered-By discloses framework version | **MEDIUM** | `X-Powered-By: PHP/7.4.21`, `Express`, `ASP.NET` | CWE-200 |
| X-AspNet-Version present | **HIGH** | Specific dotnet runtime version | CWE-200 |
| X-Runtime / X-Rails / X-Django headers present | **LOW** | Framework identification, no version | CWE-200 |
| X-Generator: drupal/wordpress + version | **MEDIUM** | CMS family + version disclosure | CWE-200 |
| Via header discloses proxy chain | **LOW** | Reveals upstream architecture (Varnish, Squid, CloudFront) | CWE-200 |
| Framework-default Set-Cookie pattern | **LOW** | `PHPSESSID`, `JSESSIONID`, `connect.sid`, etc. | CWE-200 |
| Error page reveals stack trace | **HIGH** | 5xx response body contains source file paths or framework banner | CWE-209 |
| HTTP/2 server-push fingerprint | **LOW** | HTTP/2 `:server` pseudo-header with version | CWE-200 |
| ETag format identifies cluster member | **LOW** | Apache-style hex ETags reveal node | CWE-200 |

## Prerequisites

- Python 3.9+ with `requests`
- Authorization for non-local targets

## Instructions

### Step 1 — Confirm Authorization

```text
"Do you have authorization to perform server-fingerprinting probes on
 this target? I need confirmation before proceeding."
```

### Step 2 — Run the scanner

```bash
python3 ${CLAUDE_PLUGIN_ROOT}/skills/fingerprinting-server-software/scripts/fingerprint_server.py \
    https://target.example.com \
    --authorized
```

Options:

```
Usage: fingerprint_server.py URL [OPTIONS]

Options:
  --authorized       Attest authorization (required for non-local)
  --output FILE      Write findings to FILE
  --format FMT       json | jsonl | markdown (default: markdown)
  --min-severity SEV (default: info)
  --timeout SECS     Per-probe timeout (default: 10)
  --trigger-error    Send a malformed request to surface error-page disclosure
                     (off by default — some WAFs block on this)
```

The scanner sends a baseline GET + an OPTIONS + (optionally) a
malformed request to surface error-page disclosure. For each
response, it parses the standard fingerprinting headers and
classifies each match against the threshold table above.

### Step 3 — Interpret findings

The vast majority of findings will be MEDIUM or LOW. CWE-200 is by
itself rarely a critical vulnerability — it's a recon enabler.

The exception: error-page stack-trace disclosure (CWE-209) is HIGH
because production error pages should never leak server-internal
paths or framework banners. If the error page reveals
`/home/app/src/handlers/auth.py`, the attacker now knows the source
layout AND that the language is Python.

### Step 4 — Cross-skill chaining

After this skill, suggest:

- `detecting-debug-endpoints` (#7) — fingerprinted framework points
  to which debug endpoints to probe (e.g., Server: nginx → check
  /nginx_status; X-Powered-By: Spring → check /actuator/*).
- `detecting-exposed-secrets-files` (#6) — framework fingerprint
  informs which CI / IDE / build-tool configs to probe for.

## Examples

### Example 1 — Post-deploy version-disclosure audit

User: "Make sure we're not leaking nginx version on prod."

```bash
python3 ${CLAUDE_PLUGIN_ROOT}/skills/fingerprinting-server-software/scripts/fingerprint_server.py \
    https://app.example.com --authorized --min-severity medium
```

Expected on a properly-configured host: zero findings of medium+.

### Example 2 — Tech-stack identification on an unknown target

User: "Bug bounty submission. We don't know what stack this runs.
What's the surface?"

```bash
python3 ${CLAUDE_PLUGIN_ROOT}/skills/fingerprinting-server-software/scripts/fingerprint_server.py \
    https://target.example.com --authorized --format markdown
```

Use the output to inform which subsequent skills to chain (debug-
endpoint probe, secrets-file probe).

### Example 3 — Error-page exposure check

User: "Audit production error pages for stack-trace disclosure."

```bash
python3 ${CLAUDE_PLUGIN_ROOT}/skills/fingerprinting-server-software/scripts/fingerprint_server.py \
    https://app.example.com --authorized --trigger-error --min-severity high
```

The `--trigger-error` flag sends a malformed request to provoke a
500. Some WAFs block on this; check with the target's ops team if
the result comes back empty.

## Output

JSON / JSONL / Markdown. Exit codes: 0 clean, 1 high/critical, 2 error.

## Error Handling

- **WAF blocks fingerprinting requests** → expected on
  Cloudflare/Imperva targets. The CDN itself is what gets
  fingerprinted, not the origin.
- **Connection error** → exit 2.

## Resources

- `references/THEORY.md` — Per-header reasoning: what each disclosure
  enables, threat-modeling guidance, CVE-lookup workflow
- `references/PLAYBOOK.md` — Per-server-type remediation snippets
  (nginx server_tokens, Apache ServerTokens, IIS removeHeader,
  Express helmet hidePoweredBy, framework-default cookie renaming)
- `../analyzing-tls-config/references/AUTHORIZATION.md` — Active-scan
  authorization pattern