写在前面的话

在最近的一次安全测试过程中,我对Google的应用程序“Richmedia Studio”进行了安全测试,即Google的一个营销活动管理平台。在这篇文章中,我将跟大家分享我在Google Rich Media中发现的几个安全漏洞。

第一个挑战:访问系统

虽然这并不是什么安全问题,但我仍然觉得很有意思,因为从这里才是我们打开Google Rich Media攻击面的第一步。如果你的账户里面没有配置并启用该功能的话,你是没有办法看到这个功能的。其实它并不是一个“未授权”的页面,我们只是被网站重定向到其他地方了,不信你可以尝试访问一下https://www.google.com/doubleclick/studio。这一点很关键,因为一开始我都没发现过这个应用程序,即使我花了大量时间去搜索Google的系统。

如果你想访问这个系统,你需要点击【这里】去填写一个表格,如果Google授权你访问的话,你将收到一封邀请邮件,点击之后你就可以访问这个系统了。

到处看看

这是什么?Richmedia studio?据我所知,,该平台主要用于管理在线广告活动,以及与广告商的关系。角色管理系统允许管理员创建新的活动并将媒体(如HTML页面、视频、图像等)上传到这些活动中。管理员可以给不同的广告客户访问活动,以及通过QA管理它(所有通过权限管理)和留下评论等等。因为我不太了解营销活动的流程,所以我不确定我对这个平台具体功能的定义是否准确。

第一个漏洞:访问其他用户的媒体资源(500美金漏洞奖励)

我开始研究的是其媒体资源上传功能,我希望看到与大多数谷歌应用程序相同的机制,上传的文件存储在用户的谷歌驱动器下,并通过一个带有长随机ID的临时“googleusercontent”链接公开。但事实并非如此,在Google Rich Media中,文件会上传到一个不同的域名-“s0.2mdn.net”。样本链接如下:

https://s0.2mdn.net/preview/CgkIARCom4rX5i4SGQCkoPPIITT873VA4lA-bButtVLChPwsXnU/ads/richmedia/studio/60019864/60019864_20201004010909357_xsspng.png

将文件托管在一个单独的(非“google”)域上会引发授权问题,因为浏览器不持有该域的cookies(当然,可以通过其他方式解决授权问题),而且尝试从匿名浏览器访问示例上传文件时,确实表明不需要授权。然而,这本身并不是一个真正的问题。这种联系是复杂的,不可能可以通过暴力破解或猜解攻击来拿到资源链接。但我们先来看看这个链接,访问之后,一个“预览”按钮出现在了我们的眼前。这是存储文件的实际路径,还是仅仅指向从实际源生成的“预览”的链接?

于是乎,我又上传了另一个文件,然后仔细分析了网络请求,我发现我怀疑的是对的。在一个单独的HTTP响应中,指向该文件的直接链接(而不是它的“预览”)被返回到浏览器。这个链接看起来简单得多:

http://s0.2mdn.net/ads/richmedia/studio/pv2/61580927/20201004040915088/xsspng.png

这些直接链接也可以在没有身份验证的情况下访问,并且可以由攻击者生成(前8位数字只是可以从studio应用程序枚举的商家ID,后8位数字由上载日期和短随机数组成)。

所以这里我们有一个清晰的IDOR-一个到另一个用户文件的可猜测的链接,而且没有任何身份验证。

我已经将该漏洞上报给了Google团队,并拿到了500美元漏洞奖励。

第二个漏洞:访问其他用户的活动(5000美元漏洞奖励)

说实话,这个太简单了,我都没想到。还记得我之前提到过的一个角色管理系统吗?你可以在这里创建一个账户,而无需访问QA仪表盘。事实上,如果您创建这样一个用户,那么仪表盘看起来会不太一样。管理员仪表盘界面如下:

受限账号界面如下:

如果我试图使用受限账号访问SQ页面的话,会怎么样呢,结果着实令人惊讶:

我不仅可以访问与我的用户相关的活动的QA页面,还可以看到所有活动,所有帐户!

我已经将该漏洞上报给了Google团队,并拿到了5000美元漏洞奖励。

第三个漏洞:GWT

Google Rich Media使用了GWT来处理其API请求。我在Google系统中发现的第一个问题就是GWT的授权问题。当我再次研究文件上传过程时,我将注意力放在了GWT请求上。我查看了检索文件下载URL的HTTP请求(与我们之前看到的长而复杂的链接相同),并注意到一些奇怪的字符串会被作为HTTP POST正文的一部分发送:

7|0|8|https://www.google.com/doubleclick/studio/gwt/|9DB073B0A4AFE75F8679003264944EE5|com.google.ads.api.gwt.rpc.client.BatchedInvocationService|invoke|com.google.ads.api.gwt.rpc.client.BatchedInvocationRequest/2983766987|com.google.ads.richmedia.studio.ui.common.grubby.client.BatchedInvocationRequestHeaderImpl/3117963532|java.util.ArrayList/4159755760|com.google.ads.richmedia.studio.service.CreativeServiceGwt$GetDownloadArchiveUrlRequest/1562479252|1|2|3|4|1|5|5|6|0|7|1|8|DlQXE|DlQWU|

仔细研究,你就会发现它很容易破解。最后的两个字符串“DlQXE”和“DlQWU”引起了我的注意—它们似乎是表示我实际要访问的文件的字符串。在系统中,很明显这些字符串实际上是表示系统中特定活动的ID。

没错,-我作为一个不同的用户登录并获得了另一对ID。然后我尝试在第一个用户的cookies中使用这个ID,并且能够获得第二个用户文件的URL链接。我运行了一个脚本来猜测相似的ID,并很快找到了更多有效的ID,即指向更多属于其他用户的文件。

我已经将该漏洞上报给了Google团队,又拿到了500美元漏洞奖励。

第四第五个漏洞

我现在已经非常兴奋了,而且我仍然在围绕该系统的授权机制进行研究,感觉它应该是“漏洞百出”的。果然,我又发现了一个问题:

Google的团队似乎也同意我的观点,也许Google Rich Media的授权机制确实应该好好调整调整了。

总结

研究几天之后,我脑子里想的已经不是授权的问题了,而实最初的目标应用程序发现。我之前肯定见到过https://www.google.com/doubleclick/studio/这个链接,但由于我没有权限的系统,我只是不知道它的存在。还有多少这样的应用在暗中潜伏?确实有些值得思考的东西;)

本文作者:Alpha_h4ck, 转自FreeBuf