带外通道Bind XML外部实体注入漏洞：PayPal案例研究

Posted 2021-04-25 FreeBuf

应用程序如果存在解析XML的功能可能会存在XML外部实体注入漏洞，当输入包含对外部实体引用的XML而由不安全配置的XML解析器处理时，会造成漏洞。它会导致机密数据泄露，拒绝服务，服务器端请求伪造风险，以及进行内网端口扫描等其他系统影响。PayPal官方网络应用程序(PayPal Inc – PayPal Multi-Order Shipping Application [Core])则存在此安全漏洞。

背景：

PayPal Multi-Order Shipping是一种工具，允许一次从PayPal账户打印多达50个国内美国邮政服务运输标签。

包括多项服务如下：

• 从eBay和/或PayPal导入交易

• 手动创建一个或多个ad-hoc标签

• 获取订单准备打印标签

• 修改订单的送货详细信息

• 为订单添加保险和签名确认

• 将多个订单合并为一个货件

• 还原合并订单

• 在“发运订单”选项卡中添加或删除列

• 应用程序设置和省时工具

• 打印标签和支持文档Carrier Pickup™和装运后管理

识别阶段：

在通过拦截环境中的请求来测试应用程序的功能时，以下请求引起了我的注意，发现该应用程序是基于XML的，与服务器交换的请求是XML格式的结构化数据。

在第一次测试中，我们需要确认实体是以最基本的形式解析的。所以我们用内联实体替换VALUE来分析服务器行为：

返回的响应是无效的输入错误，因此服务器有一个反射点来显示注入的payload，因为XML请求是用户提供的，我测试了基本的XML注入，通过尝试使用注入实体提取文件来检查应用程序的XML处理方法，将读取远程文件回显在客户端。此攻击的思路是声明外部通用实体并引用网络资源或本地的内部文件：

我们注意到应用程序只检查的位置：字符串，数字，CDATA值。不使用从文档内的元数据或实体引用的值。因此，在提交请求后无法获得直接回显。

XXE带外通道的利用

XXE处理概述：

默认情况下，XML解析器通常支持外部引用，外部实体可以引用解析器文件系统上的文件。外部实体通常也可以通过HTTP协议处理程序引用网络资源。向其他系统发送请求的能力可以使易受攻击的服务器用作攻击代理。通过提交合适的有效payload，攻击者可以使应用程序服务器来攻击可以与之交互的其他系统。这可能包括公共第三方系统，同一组织内的内部系统，或应用程序服务器本身的本地环回适配器上可用的服务。根据网络架构，这可能会暴露给外部攻击者无法访问的高度脆弱的内部服务。

我们注意到应用程序只检查的位置：字符串，数字，CDATA值。不使用从文档内的元数据或实体引用的值。因此，在提交请求后无法获得直接回显。

攻击方法：

1.绕过XXE注入点无法直接回显

经过多次测试后，我确认没有直接回显通道，但可以强制服务器在响应中显示结果。所以我使用了一种技术，我们使用“DOCTYPE”中的外部实体注入XML payload而不是一般实体，带有SYSTEM关键字的DOCTYPE声明会导致XML解析器从URI读取数据并允许它继续进入文档：

应用程序服务器响应了内部服务器错误消息，在我发送请求后，我的服务器从PayPal的内部服务器收到连接：

现在我们确认了外部实体已激活，这意味着允许从被攻击的服务器连接到其他远程系统，并且可以使用外部DTD通过Web请求读取本地文件。这种技术将允许我们从我们控制的主机请求任何网络资源，而资源可以托管在HTTP服务器，FTP服务器等上。

1.通过带外XXE参数实体搜索数据：

为了克服解析限制，例如（有限使用外部实体，在主XML文档中引用通用/参数实体），我想到：

• 在DTD定义中使用参数实体。

• 使服务器与我的外部域交互并解析XXE payload，而不是直接在XML文档中执行攻击。

可以通过仅引用托管的DTD资源来执行此攻击。只要服务器处理XML请求，该请求甚至不必包含任何XML主体。

A.通过协议处理程序进行XXE数据搜索：

参数实体帮助我们使用上述技术通过外部实体访问来从被攻击的服务器中向外部服务器传输文件资源内容。虽然解析器存在漏洞，但不支持直接输出回显。

现在的目标是访问服务器的内部本地文件/资源（文件泄露），利用支持各种URL方案/协议的许多平台/解析器中使用的协议处理程序（封装）：

从目标应用程序执行数据提取并连接到我的服务器以获取DTD，然后发送文件内容。假设有严格的防火墙限制，我测试了不同的协议处理程序和公共端口（21,23,80,443,8080，…）然后我意识到目标服务器阻止到某些TCP端口的传出连接，例如：21（FTP），8080,8000,1337,2222 ……等。

但是，我们仍然可以选择通过HTTP / HTTPS请求将任意文件提取回受控域。在提取“/etc/passwd”文件之后，经过几次尝试，几秒钟就会打开连接并收到文件内容：

注意到URL中发送的数据长度几乎肯定是有限的，这取决于某些特定的实现，这就是为什么使用这种方法只能读取一行/etc/passwd的内容。URL通常必须由正确形成的Unicode数据组成，并且还必须符合特定XML库对URL中允许的字符的限制。有时解析器不会检查创建的URI的长度，并且许多解析器会自动转换换行符（Xerces用空格替换它们，而System.XML进程用URL编码替换）。

B.Bypass URI长度和服务器防火墙限制：

考虑以下：

控制将在我们受控服务器侧检查的数据块长度。

从易受攻击的服务器建立到远程系统的连接，可以使用外部DTD来泄露数据。

使用PayPal远程服务器控制TCP通信协议。

模拟自定义服务器并监听端口，包括（HTTPS，HTTP）。

因此，为了克服此限制而不是来设置HTTP服务器的配置，我使用了一种技术来欺骗目标服务器以开启与端口443（https）上的自定义FTP服务器的连接，来自多行URI的每一行将作为单独的命令被请求。XML解释器解析外部DTD文件后，要读取的文件内容将发送到自定义FTP服务器上，并仅在一个请求中收集到所有数据。

因此，我们的最终payload：

POC源代码：

自定义FTP服务器 https://github.com/Gitr007/Bug-Bounty-Vulnerability-Research/blob/master/Paypal%20MultiOrder%20Shipping%20XXE/custom_ftp_server.rb

HTTP服务器 https://github.com/Gitr007/Bug-Bounty-Vulnerability-Research/blob/master/Paypal%20MultiOrder%20Shipping%20XXE/http_server.py

在fuzz更多功能之后，我可以利用带外XXE来发现一些文件，并且可以进行更多的攻击。

这种风险使远程攻击者（没有特权或用户交互）访问PayPal服务器及其内部系统。

远程执行代码场景：

这种后果非常危险，攻击者能够有效地绕过严格的防火墙，授权方案，造成敏感数据泄露和PayPal内部网络访问。在我们的案例中，我在运行XXE之后成功地将任何类型的数据泄露到我的外部服务器，这使我能够看到目标系统并识别已安装的应用程序，从而获得RCE的立足点。我想方法来读取配置文件，服务器日志文件，用户历史记录和内部主机信息等。由于PayPal信息的敏感性，我不允许分享RCE利用部分。

1. 通过历史记录日志访问Web管理门户：

2. 检查历史日志的内容（例如：~/.bash_history），查找已部署的服务。

3. 执行本地系统文件扫描。

4. 确定Apache Tomcat应用程序。

5. 通过XXE进行探测来发送Apache Tomcat配置文件，身份验证凭据返回给我们的服务器。

6. 在配置中找到URL后，Web浏览器将访问Web管理控制台。

7. 确认RCE，授予访问权限。

*参考链接：r00thunt，由生如夏花编译，转载请注明来自FreeBuf.COM