mcpField
W
wordpress-cors-xmlrpc-rce-chain

wordpress-cors-xmlrpc-rce-chain

github.com/uphiago安全1.3k41 次安装8 周前更新
代码仓库

关于 wordpress-cors-xmlrpc-rce-chain

面向 WordPress 安全评估，检查已验证的 CORS、XML-RPC、身份权限和上传行为能否构成代码执行路径。强调授权、惰性测试文件、独立证据与清理。

主要功能

  1. 01验证带凭据的 CORS 影响
  2. 02判定 XML-RPC 响应
  3. 03检查测试身份权限
  4. 04使用惰性文件测试上传
  5. 05单独评估执行前提
  6. 06记录证据并清理

适用场景

  1. 01评估疑似 WordPress 上传链
  2. 02验证 CORS 是否暴露非公开数据
  3. 03区分已确认的上传行为与推断的执行能力

安装

复制下面的命令，在终端中运行。

$npx skills add https://github.com/uphiago/recon-skills --skill wordpress-cors-xmlrpc-rce-chain

安装后在 Claude Code 中输入/wordpress-cors-xmlrpc-rce-chain确认已加载。

详细介绍

WordPress CORS、XML-RPC 与上传链

此技能用于评估经过独立验证的 WordPress 行为是否能构成未经授权执行文件的路径。不能仅因 CORS、XML-RPC、注册或某种上传方法存在，就假定其可被利用。

使用时机

  • 带凭据的 CORS 暴露了非公开 WordPress 数据。
  • XML-RPC 返回了符合协议规范的方法列表。
  • 经批准的测试身份具有可上传文件的角色。
  • 插件或核心上传操作可能接受可执行文件。
  • 评估明确允许进行会更改状态的上传和执行测试。

前置条件

  • 每个会更改状态的步骤都获得明确授权。
  • 经批准的合成账户以及测试站点或可随时丢弃的内容。
  • CORS 原语的浏览器证据。
  • 符合协议规范的 XML-RPC 证据。
  • 已确认的角色权限和上传路径。
  • 无害的测试文件和清理流程。

运行方法

发送会更改状态的请求前，先创建证据矩阵：

Primitive                 State       Evidence
Credentialed CORS         observed    browser reads approved non-public data
XML-RPC method            observed    protocol-valid methodResponse
Upload-capable identity   unverified  role and capability still required
Executable storage path   unverified  handler and server behavior required
Cleanup                   planned     test artifact and account removal

只要还有任何前置条件未得到验证，就应停止。

操作步骤

1. 验证带凭据的 CORS

使用 hunt-cors 证明不受信任的来源可通过经批准的浏览器会话读取非公开数据。仅有响应头反射或公开 REST 内容并不足够。

记录此原语为下一步提供了哪些信息。用户名、随机数或插件元数据的安全价值各不相同，且可能无法用于身份验证或上传。

2. 对 XML-RPC 进行分类
TARGET="https://www.example.test"
OUTPUT_DIR="${OUTPUT_DIR:-./output/wordpress-chain}"
mkdir -p "$OUTPUT_DIR"

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"

要求响应包含有效的 methodResponse。存在某个方法，并不能证明当前身份有权调用它。

3. 验证经批准的身份和角色

只能使用经批准的测试身份。确认其当前 WordPress 角色，以及候选操作所需的具体 upload_files 或插件权限。默认的订阅者注册通常不具备上传权限。

不要使用密码喷洒，也不要使用从评估范围之外获取的凭据来弥补缺失的前置条件。

4. 验证上传，不执行代码

明确获得上传测试授权后：

  1. 上传一个名称唯一的惰性文本或图像文件；
  2. 记录方法、身份、响应、媒体 ID 和最终 URL；
  3. 验证已存储的内容及其内容类型；
  4. 删除测试文件并记录清理情况。

这样可以验证上传边界，而不会引入可执行代码。

5. 单独评估执行能力

文件执行是一个独立的前置条件。确认上传目录是否会执行相关文件类型、是否可以绕过扩展名或 MIME 验证，以及特定插件的处理程序是否会移动测试文件。

使用经测试环境批准的无害标记。不要部署命令 shell。如果无法安全地演示执行能力，请将上传能力和执行能力分别报告为已观察到的状态和推断状态。

6. 组装攻击链
CORS read
  -> information required by approved test identity
  -> authorized XML-RPC or plugin operation
  -> inert upload accepted
  -> executable handling independently confirmed
  -> benign marker observed
  -> artifact removed

对于每个箭头，都要记录前一步为何能促成下一步。分配复合影响之前，请使用 cross-attack-chains 和 triage-validation。

常见问题

  • 公开的 REST 用户数据可能无法提供凭据或特权身份。
  • XML-RPC 是一项功能；方法存在并不代表绕过了授权。
  • 订阅者和客户角色通常无法上传任意文件。
  • 接受上传并不能证明存储的文件可执行。
  • 插件版本匹配并不能证明存在易受攻击的路由及相应前置条件。
  • 将多个中等置信度的信号组合起来，并不会形成高置信度攻击链。

验证

  • 已在浏览器中使用经批准的非公开数据复现 CORS 影响。
  • XML-RPC 证据包含符合协议规范的响应。
  • 已记录确切的测试身份和所需权限。
  • 上传验证使用惰性的合成测试文件，并包含清理步骤。
  • 如获授权，执行测试应在可随时丢弃的环境中使用无害标记。
  • 攻击链的每一步都经过独立确认；缺失的步骤仍标记为推断或未测试。

评论

支持 Markdown