从XXE到AWS密钥泄露

事情起源于我被邀请去做一次授权渗透测试，由于这是第一个给我报酬的项目，因此我想做到最好。目标客户是一家在15多个国家拥有业务的公司，在全球有120多个子公司和1200多万用户。

他们给了我一个域名和用户名、密码，现在直接开始吧。第一眼我觉得这个网站很大，而且防护的很不错。它有很多功能需要测试，也有很多配置文件，所以我直接开始进行目录扫描(dirsearch)来看看背后有什么。

一些xml配置文件出现了，标志着这可能有tomcat。读了一些xml文件，我发现了<url-pattern>的标签，所以灵感告诉我应该试试用burp来GET请求，看看服务端的响应。

服务端响应里有nginx，所以网站的架构大概是什么样子？应该是这样：

因此可以看出后端不喜欢GET请求，那么我试试POST请求吧。

在响应里面你可以看到一个Content-Type的HTTP header头的值是text/xml，所以响应应该是一个有效的xml文档，但是这里我只得到了一个“Could not access envelope: Unable to create…”的错误。

所以，如果是你，你应该怎么办？

我直接想到了最坏的情况就是存在XXE漏洞，因此我直接去搜索了几个XXE的payloads，我在请求里面也加上了Content-Type: text/xml (这正好是服务端想要的而且也相当于告诉了它我发送给了它什么)

我直接把获取/etc/passwd文件的payload复制过去了，试着读这个文件。然后就出现了这样的情况：

响应码是200没错，似乎服务端想要读取/etc/passwd的内容然后形成一个xml文档作为响应，但是这个文件的第33行不太符合，可能是有什么东西阻碍了解析。

现在我们知道了，/etc/passwd文件大约有33行，我问了一下客户，客户确认了这个文件确实是有33行的。

所以下一个事情就是获得其中的内容然后就完事了。直到现在，在一个漏洞挖掘项目里面这个可能不会认为是poc，因为我们用这个无法造成损害。所以你现在必须继续挖掘直到你发现了新的东西。

所以我生成了一个SSRF请求，然后它确实有效！我知道了tomcat的默认端口就是8080，然后从谷歌浏览器的控制台我发现，在第一个payload请求后返回了405错误，显示出这样：

所以我试了下面这个请求：

服务端请求了它自己，然后去获取DTD，回应给了我们一个错误：它试着解析我让他请求的html文档，但是产生了一个错误，后来我发现html代码是这样的：

所以我试了一下另一个端口来看看是怎么个样子：

所以8081端口是关闭的，我们现在可以用burp intruder检测每个端口，然后看看请求的响应（就类似于http版的nmap）来看看某端口是不是开放，直到现在，我们只知道8080开放。

尝试完nmap的top 1000端口，我发现至少开了8个端口。

所以我希望获得一些有趣的文件的内容，这是需要继续努力的部分。试了非常多的payloads（除了Dos），用我能想到的各种方式修改这些payloads，试了协议类似：file:// php:// dict:// expect:// 等等，但是都被禁用了。我也读了很多的writeup，然后什么都没发现。

机制就像下面的图一样：