挖洞经验 | 一个价值$3133.7美金的Google漏洞

在对Google的安全研究中，由于其云服务平台“cloud.google.com” 具备多种功能，感觉有点意思，所以某天我决定来深入测试一下它。

测试开始

测试一开始，我就在Burp Proxy中发现了以下这个有趣的链接请求：

https://cloudusersettings-pa.clients6.google.com/batch?%24ct=multipart%2Fmixed%3B%20boundary%3Dbatch392541909285510985

该请求的原始响应消息是一个JSON格式的404 NOT FOUND。但这里的请求内容引起了我的注意，首先是，和请求的头消息一起，GET请求也被包含在了这个POST请求中；另外是，可以通过主请求URL中的值来对content-type进行控制；还有，可以注意到，在POST请求的发送内容中，包含了一个key值。

思路考虑

我的想法是：

该请求执行过程，服务器“cloudusersettings-pa.clients6.google.com” 通过POST请求内容，把GET请求中继转发给了一个中间服务器，这个中间服务器可以是一个反向代理或负载均衡器，然后，这个中间服务器会以某种方式来解析这个GET请求，之后再对其进行处理或将其转发给另一个服务器。中间服务器并不关心原始POST请求的header头信息，它只解析包含在POST请求中的GET请求header头信息。

总结起来可以概括为以下几点：

1.我可以控制中间服务器将要处理的header头信息； 2.可以通过以下链接中的multipart%2Fmixed%3B%20boundary%3Dbatch392541909285510985来控制响应内容类型： https://cloudusersettings-pa.clients6.google.com/batch?%24ct=multipart%2Fmixed%3B%20boundary%3Dbatch392541909285510985 3.在请求内容中包含了一个key和授权头值（authorization header value）

各种测试

为了实现我的这种猜测，我进行了一系列的测试验证，上述第2和第3种情况是行不通的，但我发现其中的消息是无验证机制的（validated），只有第1种情况是可以实现。为了实现对POST请求内容中的GET请求进行测试，我大概实验的方法如下：

1.在HOST主机头中尝试做一些虚拟主机名枚举，如dev、localhost、portal等都来一遍，借希望从一些曝露的webserver中发现本地的虚拟主机名配置信息，以此能得到内容网络环境的些许线索。（尝试过后，这种方法行不通）

2.通过把我的IP地址用以下方式伪装，欺骗Google后端服务器，试图让其给出响应。（但最终，这种方法也行不通）

X-Forwarded-For: 127.0.0.1 X-Client-IP: 127.0.0.1 Client-IP: 127.0.0.1

3.促使Google后端服务器发生错误，比如，向其发送大量的AAAAA等垃圾消息等，或是把HTTP协议版本1.1更改为其它、向发送消息中添加随意的header信息、操纵利用现有的content-type类型等。（最终，这种方法还是行不通）

4.看看userAgent值中是否会出现Blind XSS或SQLI漏洞，如果有，那就太好了！（最终，这种方法还是行不通）

5.我也尝试了对 origin header 头进行操纵，希望能从中发现CORS跨资源共享的某些错误配置信息，但是人家的origin有着很好的安全验证。

突出一计

到了这个地步，完全没有思路了，直到我想到了：为什么不直接和Google后端服务器，以一种它可以理解的方式进行“对话”呢？！这些Web服务器的交流语言就是请求的header头信息啊，它们只要看到header头信息，就会解析它，再然后处理它！是不是呢？

我想，能和Web服务器“对话”的一种header头信息就是“X-HTTP-Method-Override”了，该头信息可以实现一些奇妙的东西，比如，你可以向服务器端发送GET请求，然后服务器会按照你在其中声明的PUT、POST和DELETE方法来执行相应处理！是的，尽管它是一个GET请求中，但这种方法也行！就像下面这样的：

GET /test.php HTTP/1.1 Host: google.com User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Firefox/45.0 Accept: text/html,application/xhtml+xml,application/xml;q=0.9,/;q=0.8 Accept-Language: en-US,en;q=0.5 X-HTTP-Method-Override: PUT Accept-Encoding: gzip, deflate Connection: close

一旦服务器端接收到了上述GET请求之后，会对其进行解析，然后会发现其中包含了一个方法为PUT的X-HTTP-Method-Override属性，这样一来，服务器端会有以下反应：

“这是一个GET请求，但是用户希望我把它当成PUT命令来执行，我知道了！”，就这样，这个GET请求就被服务器当成PUT方法来处理了。

X-HTTP-Method-Override属性的这种操作存在原因在于，一些中间服务器在其支持的HTTP方法中受到限制，如只支持GET和POST，但是，开发人员有时间会用到比如“PATCH, DELETE, PUT”的方法，所以，X-HTTP-Method-Override属性就可以用上了。

哦，我曾经在F5 WAF流量监控环境，在后端服务器启用了webdav服务的情况下，通过HTTP PUT方法触发了某个RCE漏洞，大概思路如下：

我的Burp repeater —-> Web服务器你好，我希望通过PUT方法来让你创建一个文件 —-> F5 WAF说: 这样的话你得先过了我这关，而且我只支持 GET和POST方法 —-> 没戏! 我的Burp repeater —-> F5 WAF你好，我知道后端服务器支持PUT方法，我在发起的GET请求中把X-HTTP-Method-Override属性更改为了PUT，请你把它传递给后端服务器吧 —-> F5 WAF说: 哦，好吧，听起来好像是合法的了！ —-> 后端服务器: 啊, 又来了一个要处理的PUT请求，因为我支持PUT方法，我懂你的需求，所以，你的文件可以成功创建 —-> 成功了!

测试利用

也就是说，在上述环境中，在后端服务器启用了webdav服务的情况下，我通过把X-HTTP-Method-Override属性更改为PUT方法，由此触发了一个RCE漏洞执行。那么，这种方法在这里可行吗？？我满怀喜悦的测试了一把，NO，没有RCE，但却有了一些意外的发现！

由于中间服务器不知道如何解析处理我设置的header信息，所以它抛出了一大堆错误消息来，但在这些消息中却包含了很多服务器的内部配置消息和敏感数据，如：

HTTPOnly 和 Secure cookies； 包括SSL握手交互、IP地址、端口等在内的，中间服务器与后端服务器之间的所有交流信息； 一些授权头信息和其它敏感数据。

总结

还记得之前我提到的第2和第3种情况中消息无验证机制的话吗，基于此，可以构造出一种CSRF攻击来针对Google用户，进行反射型XSS情况下的信息窃取。理论上来讲，在XSS攻击场景下，HTTPOnly cookies是相对安全的，但是利用这个漏洞，有可能从被骗点击恶意链接的Google用户那里窃取到HTTPOnly cookies。而且，这种攻击只有在更改X-HTTP-Method-Override属性方法的前提下来实现。

我把这个漏洞上报给Google之后，其安全团队把该漏洞分类为重要的P1级别，并迅速着手修复，之后，我也很快地收到了Google官方奖励的3133.7美金。

*参考来源：sec-down，clouds编译，转载请注明