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

2018-10-26 78691人围观 ,发现 6 个不明物体 WEB安全

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

测试开始

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

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

01.png该请求的原始响应消息是一个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头信息,就会解析它,再然后处理它!是不是呢?

02.png我想,能和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地址、端口等在内的,中间服务器与后端服务器之间的所有交流信息;

一些授权头信息和其它敏感数据。

03.png

总结

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

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

04.png

*参考来源:sec-down,clouds编译,转载请注明来自FreeBuf.COM

这些评论亮了

发表评论

已有 6 条评论

取消
Loading...
css.php