hunt-wordpress

WordPress 安全评估

在选择针对特定漏洞的测试之前，先梳理 WordPress 核心、REST、XML-RPC、插件、主题、身份验证边界及相邻安装。仅仅存在 WordPress、某个公开路由或版本匹配，本身都不构成发现。

适用场景

• HTML、标头、资源、Cookie 或路由表明使用了 WordPress。
• /wp-json/、/wp-login.php、/xmlrpc.php 或 /wp-content/ 可访问。
• JavaScript 或源代码引用了 WordPress 后端。
• 预发布或子目录安装可能与主站不同。

前置条件

• 明确的授权和当前目标范围。
• curl 和 jq；wpscan 为可选项。
• 用于角色或授权检查的获批测试身份。
• 仅在获准进行盲 SSRF 测试时使用受控回调服务。
• 在注册、上传、密码、插件或其他会更改状态的测试开始前，获得明确批准。

运行方法

先进行有范围限制的只读梳理：

TARGET="https://www.example.test"
OUTPUT_DIR="${OUTPUT_DIR:-./output/wordpress}"
mkdir -p "$OUTPUT_DIR"

for path in \
  / \
  /wp-json/ \
  /wp-login.php \
  /xmlrpc.php \
  /readme.html \
  /author-sitemap.xml; do
  curl -sS --max-time 10 \
    -o /dev/null \
    -w '%{http_code} %{content_type} %{size_download} %{url_effective}\n' \
    "$TARGET$path"
  sleep 1
done

测试流程

1. 确认 WordPress

使用多个信号：

curl -sS --max-time 10 "$TARGET/" \
  | grep -Eio 'wp-content|wp-includes|wp-json|wordpress' \
  | sort -u

curl -sS --max-time 10 "$TARGET/wp-json/" \
  -o "$OUTPUT_DIR/rest-index.json"

jq -r '.namespaces[]? // empty' "$OUTPUT_DIR/rest-index.json" \
  | sort -u \
  > "$OUTPUT_DIR/rest-namespaces.txt"

通用的 200 响应不足以确认。将可疑路径与随机的不存在路径进行比较，以检测兜底路由。

2. 梳理核心、主题和插件资源

curl -sS --max-time 10 "$TARGET/" \
  | grep -Eo "wp-content/(plugins|themes)/[^/?\"']+" \
  | sort -u \
  > "$OUTPUT_DIR/components.txt"

在可行时，至少通过两个信号确认组件：资源路径、REST 命名空间、readme 或变更日志、HTML 标记，或带版本号的文件。只有确认了确切的受影响版本和前置条件后，才匹配 CVE。

使用 wordpress-plugin-hunt 发现插件并验证版本。

3. 梳理 REST 数据和授权

for path in \
  /wp-json/ \
  /wp-json/wp/v2/types \
  /wp-json/wp/v2/posts?per_page=2 \
  /wp-json/wp/v2/pages?per_page=2 \
  /wp-json/wp/v2/users?per_page=2; do
  curl -sS --max-time 10 \
    -D "$OUTPUT_DIR/headers.tmp" \
    -o "$OUTPUT_DIR/body.tmp" \
    "$TARGET$path"
  printf '%s %s\n' "$path" "$(wc -c < "$OUTPUT_DIR/body.tmp")"
  sleep 1
done

在评估影响前，先对响应分类：

• 已发布的文章和页面通常按设计公开；
• 用户名可能增加钓鱼或身份验证风险，但不等于账户接管；
• 电子邮件地址、角色、草稿、设置、表单条目、订单和日志需要单独进行访问控制审查；
• 插件命名空间可能存在，但其所有操作仍受到保护。

对于授权相关的主张，请使用同一个合成对象，比较匿名用户、用户 A、用户 B 和获批的特权身份。

4. 在浏览器中验证 CORS

curl -sS --max-time 10 \
  -D "$OUTPUT_DIR/cors-headers.txt" \
  -o "$OUTPUT_DIR/cors-body.txt" \
  -H 'Origin: https://attacker.example' \
  "$TARGET/wp-json/wp/v2/users?per_page=2"

标头反射仅是线索。凭据式 CORS 影响需满足以下条件：

1. 响应接受不受信任的来源；
2. 需要 Cookie 时，响应包含 Access-Control-Allow-Credentials: true；
3. 使用获批的已认证浏览器会话；
4. 浏览器 JavaScript 能读取非公开数据；
5. 设置匿名或公开数据负向对照。

使用 cors-credential-wordpress 执行完整的浏览器工作流。

5. 对 XML-RPC 进行分类

curl -sS --max-time 15 \
  -X POST "$TARGET/xmlrpc.php" \
  -H 'Content-Type: text/xml' \
  --data-binary \
  '<methodCall><methodName>system.listMethods</methodName></methodCall>' \
  -o "$OUTPUT_DIR/xmlrpc-methods.xml"

grep -Eo '<string>[^<]+</string>' "$OUTPUT_DIR/xmlrpc-methods.xml" \
  | sed -E 's#</?string>##g' \
  | sort -u

对协议进行分类时，不要跟随重定向。有效的 methodResponse 可证明 XML-RPC 行为；仅凭状态码则不能证明。凭据测试、多调用放大、上传和 SSRF 绕过都需要单独的授权和安全限制。只有在确认相关方法及其前置条件后，才使用 xmlrpc-exploitation。

6. 检查预发布环境和次级安装

证书透明度日志、存档和资源路径可能会暴露预发布主机或子目录安装。比较以下内容：

• WordPress 和插件版本；
• 身份验证和 WAF 行为；
• REST 和 XML-RPC 暴露情况；
• 调试配置和源文件；
• 共享 Cookie、凭据、存储和部署路径。

只有当环境属于测试范围且已证实其影响时，较弱的预发布环境控制才有意义。使用 staging-subdomain-hunt 进行有范围限制的比较。

7. 检查源代码与错误信息泄露

仅探测有观测到的技术栈作为依据的路径。验证内容，而非状态：

候选项	所需内容
.git/HEAD	Git 引用，例如 ref: refs/heads/...
.env	配置赋值，而非通用 HTML
debug.log 或 error_log	真实的应用错误或敏感运行时数据
备份归档	正确的文件签名和有意义的内容
目录列表	目录索引标记和实际条目

使用 source-leak-hunt 和 error-log-mining；仅保留证明存在泄露所需的最少脱敏样本。

8. 构建候选攻击路径

仅连接已验证的前置条件：

observed component
  -> exact version and configuration
  -> reachable vulnerable operation
  -> approved identity or synthetic object
  -> reproduced security impact

注册、XML-RPC、上传路由和可执行的 PHP 配置并不会自动构成 RCE 攻击链。请分别确认角色权限、上传验证、存储路径和执行行为。

注意事项

• WordPress 路由经常位于 CDN、缓存或兜底行为之后。
• GET /xmlrpc.php 返回 405，并不能判定有效的 POST 方法调用。
• REST 命名空间并不能证明插件操作无需身份验证。
• 公开的作者元数据不一定敏感。
• 插件版本可能被隐藏、回移植，或由过时的资源报告。
• 大型日志、站点地图和 REST 集合可能导致不必要的数据收集；请请求有界样本。
• 默认凭据尝试、密码喷洒、注册、上传和写入都需要明确授权，并约定锁定限制。

验证

• 根据内容而非仅凭状态码确认 WordPress。
• 每个组件发现都包含第二个信号，或说明为何无法获得第二个信号。
• 每个 CVE 关联都包含确切版本和前置条件证据。
• REST 授权测试使用获批的身份和负向对照。
• 在浏览器中使用非公开数据复现 CORS 影响。
• XML-RPC 行为使用符合协议的响应或受控回调。
• 有状态变更的测试使用合成记录，保留清理证据，并始终在范围内进行。