本年3月份时，我曾上报过Google的恣意html/javascript网页在线嵌入东西Caja的一个XSS缝隙，到5月份时，这个缝隙才被修正。之后，我想看看谷歌协作渠道（Google Sites）网站调用的Caja服务是否还存在这个未修正缝隙。所以，对Google Sites进行了一番测验，惋惜这个Caja XSS缝隙是不存在的，但经过其它方向的深化测验，我发现了Google内部出产 *** 的SSRF缝隙。
布景介绍
Google Sites：谷歌协作渠道是一款在线协作修改东西，它能够协助企业创立企业内网、项目办理盯梢、外延网、以及其它类型的定制网站。用户能够经过Google Sites将一切类型的文件包括文档、视频、图片、日历等与老友、团队或整个 *** 共享。
Google Caja服务会解析html/javascript文件，并会消除去其间像iframe、object对像符号和document.cookie等灵敏javascript内容，起到安全过滤作用。一般，Caja服务首要针对客户端的HTML符号进行解析和安全过滤，可是，关于一些相似的长途调用javascript符号来说，长途资源的获取、解析和过滤是在服务端进行的。
端倪发现
我曾企图在我的自架服务器上保管了一个javascript文件，像这样https://[attacker].com/script.js，之后把它嵌入到一个长途调用符号中，以此来测验 Google Sites 服务端的XSS缝隙，但惋惜Google Sites 服务端的呼应显现，https://[attacker].com/script.js无法拜访。
经过许多测验，我才意识到Google Sites中的Caja服务只会调用谷歌本身的资源文件，就像https://www.google.com 或 https://www.gstatic.com 网站保管的文件才行，但像https://www.facebook.com 这样的外部资源就不可啦。
这就有点奇怪了，因为Caja服务长途调用功用原本便是能够获取到任何外部资源的啊，这种设置看起来就像一个被损坏的功用。更有意思的是，因为谷歌的服务网站十分之多，要确认某个外调URL链接是否归于谷歌，仍是有些难度的。除非……
发现Google的SSRF缝隙
每逢我能经过服务端运用获取到恣意内容时，我都会趁便测验一下SSRF缝隙。针对Google的运用服务，我做过许多SSRF测验，但没有一次是成功的。对Google Caja服务端奇怪行为的解说，仅有的或许便是，Caja的链接提取动作发生在Google内部 *** 的，并且Google只能调用提取本身的资源文件音讯，而其它的外部资源文件就不可。这从逻辑上来说，能够算是一个bug，现在的问题是，它是否算得上一个安全缝隙！
在Google服务器上保管和运转恣意代码十分简单，例如运用Google云服务啊！所以，我创立了一个Google App Engine运用实例，并在上面保管了一个javascript文件。然后，我将这个javascript文件的URL链接，作为外部资源引证链接在我的Google Sites页面上作了装备。之后，Google Caja服务端成功获取并解析了该javascript文件。据此，我检查了我的Google App Engine实例日志，看看这个外部资源链接到底是谁来恳求它的，啊哈，呈现了一个IP地址：10.x.x.201，这显着是一个内部 *** IP地址啊！有点期望了！
那么，我用包括这个Google内部 *** 的IP地址作为Google Sites页面的javascript调用外链会发生什么作用呢？试试吧，一起来静待本相。但在恳求之后快半分钟了，仍是没啥反响，我都觉得是不是恳求被阻拦了，就快要把页面封闭了。可是，当我检查 Google Caja 服务的呼应时，却发现其呼应数据并不象一般的1KB左右的典型过错音讯，而是有1MB容量的内容！这些1MB的呼应音讯是来自Google内部 *** 的某IP地址 10.x.x.x，此刻，我是适当的振奋！翻开这个1MB文件，我发现其间包括了许多Google内部 *** 体系的灵敏信息！
运用SSRF缝隙获取到的Google内部信息
首要，我想说的是，我并没有对Google内部 *** 进行过勘探扫描，我仅仅对其内网测验了3个恳求就确认了该SSRF缝隙，并立刻上报给了谷歌的缝隙团队VRP，48小时之后，Google团队修正了该缝隙。在此之前，我也好奇心激烈地创立了其它2到3个恳求，想看看能否根据该SSRF缝隙，深化运用发现其它的未约束文件拜访或RCE缝隙，但惋惜最终都没有。
我创立的之一个恳求是发向 http://10.x.x.201/ 的，它呼应了一个 “Borglet” 的服务器状况监控页面。我对此进行了一些Google查询，发现这是Google内部的大规模集群办理体系Borg。阅历多种架构演化，Google曾在2014年开源了 Borg的继任体系Kubernetes，尽管Kubernetes越来越受欢迎，但谷歌内部的出产 *** 架构依然严峻依靠Borg体系。Borg单元由一组机器，一个称为Borgmaster的逻辑中心控制器和单元中每台机器上运转的称之为Borglet的署理进程构成。

我创立的第二个恳求是发向 http://10.x.x.1/ 的，它呼应了另一个 “Borglet”  服务器状况监控页面，我创立的第三个恳求则是 http://10.x.x.1/getstatus，它的呼应主体也是一个 “Borglet”  服务器状况监控页面，但其间包括了许多进程使命的权限和参数等详细信息。
每个Borglet代表一台服务器，从硬件方面来说，10.x.x.1 和 10.x.x.201 这两台服务器都运用了英特尔第四代架构的Haswell 2.30GHz 72内核CPU，适当于一组2到3个Xeon E5 v3 CPU处理器。这两台服务器都运用了 77%的CPU，它们具有250 GB内存，运用量达 70%。它们的硬盘容量都是2TB硬盘，且每台硬盘容量简直都是空的，只要15个G的运用占有空间。所以，重要数据或许存储在其它当地。

[1] [2]  黑客接单网