diff --git a/strix/skills/custom/safe_mode_crawling.md b/strix/skills/custom/safe_mode_crawling.md new file mode 100644 index 00000000..1de358d3 --- /dev/null +++ b/strix/skills/custom/safe_mode_crawling.md @@ -0,0 +1,145 @@ +--- +name: safe-mode-crawling +description: Systematic guard against destructive side effects when crawling and testing — recognize irreversible operations before invoking them, prefer read-only reconnaissance, and surface high-risk actions to the operator +--- + +# Safe-Mode Crawling Guard + +Autonomous agents that drive browsers, submit forms, and fire HTTP requests can cause real damage to target environments — deleting data, triggering payments, sending emails, or mutating production state. This skill teaches agents to recognize destructive operations **before** executing them, prefer read-only reconnaissance, and escalate to the operator when an action's side effects are uncertain. + +## Why This Matters + +An agent pointed at a staging or production application with admin credentials can: +- `DELETE` database records, user accounts, or storage objects +- Trigger email/SMS notifications to real users +- Process payments or refunds through payment gateways +- Reset passwords, revoke API keys, or invalidate sessions +- Execute bulk operations (purge caches, drop tables, wipe logs) +- Submit forms that create real orders, tickets, or support requests + +These are not hypothetical — they are the natural consequence of an autonomous agent exploring admin panels and API endpoints without constraint. + +## Recognizing Destructive Operations + +### HTTP Method Heuristics + +| Method | Default Risk | Notes | +|--------|-------------|-------| +| `GET`, `HEAD`, `OPTIONS` | 🟢 Usually Safe | Read-only by specification, but **not guaranteed** — some apps use GET for state changes | +| `POST` | 🟡 Caution | Creates resources; may trigger side effects | +| `PUT`, `PATCH` | 🟡 Caution | Modifies existing resources | +| `DELETE` | 🔴 High Risk | Removes resources; often irreversible | + +**Critical:** HTTP method alone is NOT sufficient to determine safety. Some applications expose state-changing operations through `GET` (e.g., `GET /api/users/delete?id=5`, `GET /admin/reset-password?user=admin`, `GET /logout`, `GET /unsubscribe`). Similarly, `POST` is used for destructive operations (e.g., `POST /api/users/delete`, `POST /admin/purge-cache`). **Always check endpoint semantics — URL path, query parameters, and context — regardless of HTTP method.** + +### High-Risk Endpoint Patterns + +Watch for these patterns in URLs, form actions, and API routes: + +**Deletion / Removal** +- `/delete`, `/remove`, `/destroy`, `/purge`, `/wipe`, `/drop` +- `/api/*/delete`, `/admin/*/remove` +- Bulk variants: `/bulk-delete`, `/delete-all`, `/clear-all` + +**State Mutation** +- `/reset`, `/revoke`, `/invalidate`, `/deactivate`, `/disable` +- `/password/reset`, `/api-keys/revoke`, `/sessions/invalidate` + +**Financial / Transactional** +- `/payment`, `/charge`, `/refund`, `/purchase`, `/checkout` +- `/subscribe`, `/cancel-subscription`, `/billing` + +**Communication Triggers** +- `/send`, `/notify`, `/email`, `/sms`, `/webhook/trigger` +- `/invite`, `/broadcast`, `/publish` + +**Admin / System** +- `/admin/*/execute`, `/admin/*/run` +- `/migrate`, `/seed`, `/truncate`, `/backup/delete` + +### Form Analysis + +Before submitting any form, check: +1. **Action URL** — does it match a high-risk pattern above? +2. **Submit button text** — "Delete", "Remove", "Reset", "Send", "Pay", "Confirm" +3. **Confirmation dialogs** — JavaScript confirms are a signal the app considers the action risky +4. **Hidden fields** — `_method=DELETE`, `action=destroy`, `confirm=true` +5. **CSRF tokens** — presence indicates state-changing operation + +## Decision Framework + +``` +1. Does the endpoint match a high-risk pattern (e.g., /delete, /payment, /reset)? + ├── YES → STOP. Log the finding. Do NOT execute. + │ Surface to operator with: URL, method, parameters, and risk assessment. + └── NO → Continue to step 2. + +2. Does the endpoint semantics suggest state change? (Check URL path, query params, + button text, form action, API docs — even for GET/HEAD/OPTIONS.) + ├── YES or UNCERTAIN → Treat as mutating. Go to step 3. + └── NO, confirmed read-only → Proceed. + +3. Can this action be reversed? + ├── YES (e.g., create a test user that can be deleted) → Proceed with caution. + └── NO or UNCERTAIN → STOP. Surface to operator. +``` + +> **Why GET/HEAD/OPTIONS are not auto-approved:** The HTTP spec says these methods _should_ be safe, but real-world applications violate this. A `GET /admin/deleteUser?id=5` is just as destructive as `DELETE /api/users/5`. The decision tree checks endpoint semantics for **every** request, regardless of method. + +## Operational Rules + +### Before Any Mutating Request + +1. **Identify the operation** — What does this endpoint actually do? Read the endpoint name, form labels, button text, and API documentation if available. +2. **Assess reversibility** — Can the action be undone? Creating a test record is usually reversible; deleting a production record is not. +3. **Check scope** — Is this a single-resource operation or a bulk operation? Bulk operations are categorically higher risk. +4. **Prefer read-only alternatives** — Can the same vulnerability be demonstrated with a GET-based information disclosure instead of a destructive POST? + +### Idempotency Checks + +Before repeating any mutating request: +- Has this exact request already been sent in this session? +- Did the first attempt succeed? If so, do not retry — the side effect has already occurred. +- For test data creation: use unique, identifiable values (e.g., `strix_test_`) so cleanup is possible. + +### When to Stop and Surface + +**Always stop and report to the operator when:** +- The action would delete or modify real user data +- The action would trigger external communication (email, SMS, webhook) +- The action involves payment processing or financial transactions +- The action would modify authentication state (password reset, key revocation) +- The action is a bulk/batch operation affecting multiple resources +- You are uncertain about the side effects + +**Format for surfacing:** +``` +⚠️ HIGH-RISK ACTION DETECTED +Endpoint: DELETE /api/v1/users/42 +Method: DELETE +Risk: Irreversible deletion of user account +Context: Found during IDOR testing on user management panel +Recommendation: Test with a disposable test account instead, or confirm with operator +``` + +## Validation + +1. Demonstrate that the safe-mode guard prevents execution of destructive operations by showing the agent correctly identifies and skips high-risk endpoints +2. Confirm that read-only testing paths still discover the vulnerability (e.g., proving IDOR via GET before attempting DELETE) +3. Document any high-risk operations that were surfaced to the operator instead of executed +4. Verify that test data created during scanning uses identifiable prefixes for cleanup + +## Integration with Other Skills + +- **IDOR testing** — Prove authorization bypass with GET requests first; only attempt state-changing operations with disposable test data +- **CSRF testing** — Demonstrate the vulnerability exists without actually triggering the destructive action on real data +- **Business logic** — Map the workflow read-only before attempting to exploit state transitions +- **Authentication/JWT** — Test token manipulation without invalidating real sessions + +## Pro Tips + +1. Start every engagement by mapping the application **read-only** — enumerate endpoints, understand data model, identify admin functions — before attempting any writes +2. If the target has a test/sandbox mode, prefer it over production endpoints +3. When testing APIs, use obviously fake data (`test@strix-pentest.example`, `strix_test_*`) so the operator can identify and clean up agent-created records +4. Document every mutating request you *choose not to send* — this is valuable information for the operator and demonstrates responsible testing methodology +5. A vulnerability that could cause damage is still a valid finding even if you don't trigger the damage — describe the attack path, show the preconditions are met, and let the operator decide on full exploitation diff --git a/strix/skills/protocols/smb_netbios_enumeration.md b/strix/skills/protocols/smb_netbios_enumeration.md new file mode 100644 index 00000000..947ca168 --- /dev/null +++ b/strix/skills/protocols/smb_netbios_enumeration.md @@ -0,0 +1,110 @@ +--- +name: smb-netbios-enumeration +description: SMB/NetBIOS enumeration covering null sessions, share discovery, user enumeration, and known protocol vulnerabilities (e.g., EternalBlue, SMBGhost) +--- + +# SMB/NetBIOS Enumeration + +Server Message Block (SMB) and NetBIOS are critical attack surfaces on Windows networks (and Samba on *nix). Misconfigured SMB can expose file shares, user lists, password policies, and domain information. Vulnerable SMB versions (SMBv1) or unpatched SMBv3 implementations can lead to unauthenticated remote code execution. + +## Attack Surface + +**Scope** +- TCP 445 (Direct SMB over TCP) +- TCP 139 (SMB over NetBIOS) +- UDP 137 (NetBIOS Name Service) +- UDP 138 (NetBIOS Datagram Service) + +**What to Test** +- Authentication requirements (Null session, Guest access) +- Share permissions (Read/Write access on IPC$, C$, ADMIN$, custom shares) +- Information disclosure (Users, groups, domain info, password policies) +- Vulnerability to known RCE/DoS flaws (MS17-010, CVE-2020-0796) +- Message signing configuration (SMB relay susceptibility) + +## Key Vulnerabilities + +### Null Sessions and Guest Access + +**Anonymous Enumeration** +Historically, Windows allowed "Null Sessions" (anonymous access without credentials) to IPC$. This permits enumeration of users, groups, shares, and password policies. While restricted in modern Windows versions by default, misconfigurations or legacy systems still exhibit this. + +**Guest Access** +The built-in Guest account might be enabled and have access to shares, leading to sensitive data exposure. + +### Protocol Vulnerabilities + +| Vuln | CVE | Description | Test | +|------|-----|-------------|------| +| EternalBlue | MS17-010 / CVE-2017-0144 | RCE in SMBv1. Exploited widely (WannaCry). | `nmap --script smb-vuln-ms17-010 -p 445 ` | +| SMBGhost / CoronaBlue | CVE-2020-0796 | RCE/DoS in SMBv3.1.1 compression. | `nmap --script smb-vuln-cve-2020-0796 -p 445 ` | +| SMBleed | CVE-2020-1206 | Information disclosure in SMBv3.1.1 decompression. | Often tested alongside SMBGhost. | + +### SMB Message Signing + +**SMB Relay Attacks** +If SMB signing is not required (`Message signing enabled but not required`), the server is vulnerable to SMB relay attacks. An attacker can intercept NTLM authentication traffic and relay it to the server to gain unauthorized access. + +## Testing Methodology + +### 1. Protocol and Configuration Check + +```bash +# General SMB discovery and signing check +nmap -n -Pn -p 139,445 --script smb-os-discovery,smb-security-mode +``` + +### 2. Null Session and Share Enumeration + +```bash +# Using smbclient (anonymous) +smbclient -N -L // + +# Using enum4linux (comprehensive enumeration) +enum4linux -a + +# Using nmap for shares +nmap -n -Pn -p 445 --script smb-enum-shares +``` + +### 3. Vulnerability Scanning + +```bash +# Check for known SMB vulnerabilities +nmap -n -Pn -p 445 --script "smb-vuln-*" +``` + +## Validation + +1. **Demonstrate Access** — Show the output of an anonymous/guest connection listing shares or reading a file. +2. **Prove Enumeration** — Extract valid usernames or password policy details using a null session. +3. **Confirm Vulnerabilities** — Run specific vulnerability checks (e.g., MS17-010) and verify the output indicates vulnerability. + +## False Positives + +- **Firewall Filtering** — Ports appear open, but deep inspection or scripts fail due to intermediate firewalls. +- **SMB Signing "Enabled"** — The service might support signing, but if it's not *required*, it's still vulnerable to relay. Pay attention to the exact wording. +- **Honeypots** — Deliberately vulnerable-looking SMB services that trap scanners. + +## CVSS Context + +| Finding | Typical CVSS | Rationale | +|---------|-------------|-----------| +| EternalBlue (MS17-010) | 9.3 (Critical) | Remote Code Execution | +| SMBGhost (CVE-2020-0796) | 10.0 (Critical) | Remote Code Execution | +| Anonymous Share Access (Read/Write) | 7.5 - 9.0 (High/Critical) | Data exposure or modification depending on share content | +| Null Session User Enumeration | 5.3 (Medium) | Information disclosure aiding further attacks | +| SMB Signing Not Required | 5.3 (Medium) | Enables relay attacks, requiring adjacent network position | + +## Pro Tips + +1. When testing shares, look for configuration files, backups, and scripts that might contain hardcoded credentials. +2. `IPC$` is for inter-process communication; you can't typically browse files on it, but it's used for enumeration. +3. If anonymous access fails, always test with any valid credentials you've obtained, no matter how low-privileged. + +## Tooling + +- **nmap** — Essential for discovery and vulnerability checks (`smb-os-discovery`, `smb-enum-shares`, `smb-vuln-*`). +- **smbclient** — Command-line SMB client, excellent for testing connectivity and manual browsing. +- **enum4linux** — Comprehensive tool for extracting information from Windows and Samba hosts. +- **CrackMapExec / NetExec** — Advanced post-exploitation and enumeration tools (if available in the environment). diff --git a/strix/skills/protocols/ssl_tls_analysis.md b/strix/skills/protocols/ssl_tls_analysis.md new file mode 100644 index 00000000..01d9f86e --- /dev/null +++ b/strix/skills/protocols/ssl_tls_analysis.md @@ -0,0 +1,170 @@ +--- +name: ssl-tls-analysis +description: SSL/TLS configuration assessment covering cipher suite enumeration, certificate chain validation, protocol downgrade attacks, and known implementation vulnerabilities +--- + +# SSL/TLS Configuration Analysis + +SSL/TLS misconfigurations remain among the most common network-layer findings. Weak cipher suites, expired certificates, protocol downgrade vulnerabilities, and implementation flaws expose encrypted communications to interception, decryption, and man-in-the-middle attacks. + +## Attack Surface + +**Scope** +- Any service exposing TLS: HTTPS (443), SMTPS (465/587), IMAPS (993), LDAPS (636), database TLS, custom ports +- Load balancers, reverse proxies, CDN edge nodes (each may have independent TLS configuration) +- Internal services using self-signed or improperly chained certificates + +**What to Test** +- Protocol versions supported (SSLv3, TLS 1.0/1.1/1.2/1.3) +- Cipher suite selection and ordering +- Certificate validity, chain completeness, and trust anchoring +- Key exchange strength and forward secrecy +- Known implementation vulnerabilities (BEAST, POODLE, Heartbleed, ROBOT, etc.) +- HSTS, certificate transparency, OCSP stapling configuration + +## Key Vulnerabilities + +### Protocol Downgrade + +**Legacy Protocol Support** +- SSLv3 → POODLE attack (CVE-2014-3566); padding oracle on CBC ciphers +- TLS 1.0 → BEAST attack (CVE-2011-3389); CBC IV predictability +- TLS 1.1 → No known critical attacks but lacks modern security features; deprecated by RFC 8996 + +**Detection** +```bash +# Check for SSLv3 support +nmap --script ssl-enum-ciphers -p 443 | grep -i "SSLv3" + +# Or with openssl +openssl s_client -ssl3 -connect :443 2>&1 | grep -i "alert" +``` + +### Weak Cipher Suites + +**Critical Weaknesses** +- `NULL` ciphers — no encryption at all +- `EXPORT` ciphers — 40/56-bit keys; trivially breakable (FREAK, Logjam) +- `RC4` ciphers — biased keystream; practical plaintext recovery (CVE-2013-2566) +- `DES`/`3DES` — 56/112-bit effective; Sweet32 birthday attack (CVE-2016-2183) +- `CBC` mode without TLS 1.3 — vulnerable to padding oracle attacks in older implementations + +**No Forward Secrecy** +- `RSA` key exchange (not `ECDHE`/`DHE`) — compromised server key decrypts all past traffic +- Static `DH` parameters — precomputed logjam tables for common 1024-bit groups + +### Certificate Issues + +**Chain Problems** +- Expired certificate or intermediate +- Self-signed certificate in production +- Incomplete chain (missing intermediates) +- Wrong hostname (CN/SAN mismatch) +- Revoked certificate (CRL/OCSP) + +**Key Weakness** +- RSA key < 2048 bits +- ECDSA key < 256 bits (P-256) +- SHA-1 signed certificates (deprecated since 2017) + +### Implementation Vulnerabilities + +| Vuln | CVE | Test | +|------|-----|------| +| Heartbleed | CVE-2014-0160 | `nmap --script ssl-heartbleed -p 443 ` | +| POODLE | CVE-2014-3566 | Check for SSLv3+CBC support | +| ROBOT | CVE-2017-13099 | `nmap --script ssl-robot -p 443 ` (if script available) | +| DROWN | CVE-2016-0800 | Check for SSLv2 support on any server sharing the RSA key | +| CCS Injection | CVE-2014-0224 | `nmap --script ssl-ccs-injection -p 443 ` | +| CRIME/BREACH | CVE-2012-4929 | Check TLS compression; `Accept-Encoding: gzip` response analysis | +| Renegotiation | CVE-2009-3555 | `openssl s_client -connect :443` then type `R` | + +## Testing Methodology + +### 1. Enumerate Supported Protocols and Ciphers + +```bash +# Comprehensive nmap scan +nmap -n -Pn --script ssl-enum-ciphers -p 443,8443 + +# Quick openssl check for specific protocol +openssl s_client -tls1 -connect :443 < /dev/null 2>&1 +openssl s_client -tls1_1 -connect :443 < /dev/null 2>&1 +openssl s_client -tls1_2 -connect :443 < /dev/null 2>&1 +openssl s_client -tls1_3 -connect :443 < /dev/null 2>&1 +``` + +### 2. Inspect Certificate Chain + +```bash +# Full certificate details +openssl s_client -connect :443 -showcerts < /dev/null 2>&1 | openssl x509 -noout -text + +# Check specific fields +openssl s_client -connect :443 < /dev/null 2>&1 | openssl x509 -noout \ + -subject -issuer -dates -fingerprint -ext subjectAltName +``` + +### 3. Test for Known Vulnerabilities + +```bash +# Heartbleed +nmap -n -Pn --script ssl-heartbleed -p 443 + +# CCS Injection +nmap -n -Pn --script ssl-ccs-injection -p 443 + +# Multiple checks in one pass +nmap -n -Pn --script "ssl-*" -p 443 +``` + +### 4. Check Security Headers + +```bash +# HSTS header +curl -sI https:// | grep -i strict-transport + +# Expected: Strict-Transport-Security: max-age=31536000; includeSubDomains; preload +``` + +## Validation + +1. **Demonstrate the weakness** — Show the specific weak protocol/cipher is negotiable, not just advertised +2. **Prove impact** — For protocol downgrade, show the client can be forced to use the weak protocol; for weak ciphers, confirm the server selects them when offered exclusively +3. **Certificate issues** — Show the exact chain failure (expired date, hostname mismatch, missing intermediate) +4. **Implementation vulns** — Confirm with Nmap NSE scripts or equivalent tool output +5. **Rate accurately** — TLS 1.0 support alone is Medium; combine with CBC ciphers for High; SSLv3 or Heartbleed is Critical + +## False Positives + +- Server advertises weak ciphers but never selects them (server preference enforced) — verify by offering only the weak cipher +- Certificate expired in alternate SAN but primary domain is valid +- CDN/WAF terminates TLS before reaching origin — the finding applies to the edge, not the origin +- HSTS missing on a non-browser API endpoint — lower severity than a user-facing site +- TLS 1.0 enabled but only for specific legacy clients behind a load balancer policy + +## CVSS Context + +| Finding | Typical CVSS | Rationale | +|---------|-------------|-----------| +| SSLv3 enabled + CBC ciphers (POODLE) | 7.5 (High) | Network-exploitable padding oracle | +| TLS 1.0 only (no TLS 1.2/1.3) | 5.3 (Medium) | Deprecated protocol, known weaknesses | +| Heartbleed (confirmed) | 9.1 (Critical) | Memory disclosure, key extraction | +| Self-signed cert in production | 5.9 (Medium) | No trust chain; enables MITM | +| Missing HSTS | 4.3 (Medium) | Protocol downgrade on first visit | +| Weak DH parameters (< 2048 bit) | 5.3 (Medium) | Logjam precomputation feasible | +| No forward secrecy (RSA key exchange) | 5.3 (Medium) | Past traffic decryptable if key leaked | + +## Pro Tips + +1. Always test all TLS-enabled ports, not just 443 — SMTP STARTTLS (587), database TLS, and custom service ports often have weaker configurations +2. Check if the same RSA key is shared across multiple services — one SSLv2 service enables DROWN on all of them +3. For CDN-fronted targets, also test the origin directly if accessible — CDN may mask origin TLS weaknesses +4. Certificate transparency logs (crt.sh) can reveal additional subdomains and cert history +5. Modern TLS 1.3 has no known cipher suite weaknesses — if the server supports only TLS 1.3, focus testing on certificate chain and implementation instead + +## Tooling + +- **nmap** (preinstalled) — `ssl-enum-ciphers`, `ssl-heartbleed`, `ssl-ccs-injection` NSE scripts +- **openssl** (preinstalled) — Protocol probing, certificate inspection, manual cipher testing +- **nuclei** (preinstalled) — TLS misconfiguration templates: `nuclei -u https:// -tags ssl,tls`