wordpress-full-compromise

WordPress 入侵路径分析

使用此技能确定已验证的 WordPress 原语是否确实能够组合成管理控制权，或作为无害的代码执行证明。这是一个链路闸门，而不是在某个前置条件未满足后仍强行升级的检查清单。

适用场景

• 插件漏洞有精确的版本和路由证据。
• 已获批准的身份可能拥有意料之外的 WordPress 权限。
• 上传或配置写入可能触发可执行文件处理。
• CORS、XML-RPC、暂存环境或源码暴露可能满足缺失的前置条件。

前置条件

• 明确授权进行注册、身份验证、上传、写入和执行测试。
• 已批准的合成账号和一次性内容。
• 精确的 WordPress、插件、主题和托管环境行为信息。
• 执行测试使用无害标记。
• 清理方案和停止条件。

运行方法

构建前置条件表：

Step                         State       Required evidence
Component vulnerability      observed    exact version and affected operation
Authorized identity          confirmed   approved account and current role
Write or upload capability   unverified  synthetic artifact accepted
Executable handling          unverified  benign marker executed
Administrative control       not tested  approved admin-only action
Cleanup                      planned     artifact and account removal

不要越过未经验证的前置条件继续操作。

流程

1. 确认组件

使用 hunt-wordpress 和 wordpress-plugin-hunt 确认：

• 通过多个信号识别组件；
• 确切版本或提交；
• 易受攻击的路由或处理程序；
• 身份验证和角色前置条件；
• 受影响的配置和文件类型。

仅凭公开的 readme 或过时的资源文件不足以确认。

2. 确认身份和权限

仅使用已批准的测试身份。记录当前角色，以及该操作检查的具体权限。订阅者、客户、作者、编辑和管理员角色不可互换。

不要使用密码喷洒、凭证填充或无关的泄露凭证来弥补授权缺失。

3. 使用合成数据验证状态变更

使用名称唯一的合成文章、对象或无害文件。记录：

• 请求和身份；
• 响应和生成的对象 ID；
• 位置和内容；
• 预期的授权策略；
• 清理结果。

如果无法安全删除对象，请在创建前停止。

4. 区分上传与执行

接受上传只能证明存在上传边界。需单独确认是否会执行：

• 服务器将存储的扩展名映射到解释器；
• MIME 类型和扩展名验证允许所测类型；
• 存储路径可通过 Web 访问；
• 插件处理不会重命名或清理文件；
• 无害标记可在获批环境中执行。

切勿将命令 shell 作为通用证明进行部署。

5. 评估管理影响

管理控制权需要通过获批的、仅限管理员的操作来证明，例如读取合成的私有设置，或更改一次性配置值后将其还原。用户枚举、REST 元数据或可访问的登录页面均不足以证明账号接管。

6. 组装路径

使用 cross-attack-chains 连接已确认的转换。仅当 CORS 和 XML-RPC 是实际前置条件时，才使用 wordpress-cors-xmlrpc-rce-chain，而不能仅因为同一安装中还存在这些发现就使用。

注意事项

• 开放注册通常只会创建低权限角色。
• 存在 XML-RPC 方法并不代表有权调用该方法。
• 启用 PHP 进程函数并不会产生上传原语。
• 插件版本证据可能已过时或已通过回移植修复。
• 暂存站点可能使用独立数据库，且与生产环境之间不存在信任路径。
• 前置条件未满足，说明拟议的链路在此处中止。

验证

• 已确认组件身份、版本、路由和前置条件。
• 获批身份拥有确切的所需权限。
• 状态变更使用合成资源，并已还原。
• 上传和执行作为独立步骤得到证明。
• 管理影响通过获批的一次性操作验证。
• 所有缺失步骤均保留为推断或未测试状态。