Google Monorail问题跟踪器中发现了XS搜索漏洞

TRex 漏洞 2018年12月5日发布
Favorite收藏

导语:本文详细解释了如何利用Google的Monorail问题跟踪器漏洞,通过XS-Search攻击,从私有漏洞报告中泄露敏感信息。

Monorail是许多“Chromium-orbiting”项目使用的开源问题跟踪器,包括Monorail本身。其他项目包括Angle,PDFium,Gerrit,V8和开放媒体联盟。它也被谷歌的0 day漏洞挖掘团队Project Zero使用。

本文详细解释了如何利用Google Monorail问题跟踪器的漏洞,通过XS-Search攻击,从私有漏洞报告中泄露敏感信息(易受攻击的源代码文件和行号)。

一、开始

我在分析Monorail时首先考虑的功能之一是能够将某个搜索查询的结果下载为CSV。

没多久,我就注意到它很容易受到CSRF攻击。换句话说,如果访问了恶意链接,则可以强制用户下载包含搜索查询结果的CSV。

如图所示,没有包含针对CSRF攻击的保护措施。因此,举个例子,使用“Restrict-View-SecurityTeam”标记发出的请求最终只会过滤未公开的安全相关问题。如果Google安全小组的成员或高权限的漏洞报告者访问此链接,他们将下载包含自己有权访问的所有未公开问题的CSV。

二、复制与攻击

另一个重要发现是搜索结果中显示的列会重复,这使我们可以随意增加生成的CSV的长度。

为便于说明,如果访问以下网址:

https://bugs.chromium.org/p/chromium/issues/csv?can=1&q=id:51337&colspec=ID+Summary+Summary+Summary

下载的CSV将包含3个重复的Summary列,而不是仅包含一个。

查询生成的CSV包含3遍Summary。

三、卷土重来的XS-Search

结合这两个漏洞,我们拥有执行跨站点搜索(XS-Search)攻击所需的全部功能:

1.能够执行复杂的搜索查询。

2.能够夸大搜索查询的响应。

第二点特别重要。如果搜索查询的响应与漏洞匹配,我们可以使CSV明显大于不匹配的查询。

由于响应长度存在很大差异,因此可以计算每个请求完成所需的时间,然后推断查询是否返回结果。这样,我们就可具备询问跨源布尔问题的能力。

短语“跨源布尔问题”听起来很奇怪,但它本质上意味着我们能够提出诸如“是否存在与文件夹`src/third_party/pdfium/`?匹配的私有漏洞”这样的问题并获得答案。这涉及将在以下章节中描述的几个步骤。

目前,如下示例演示了问题的核心:

第一种情形 – 从查询“Summary: This bug exists”生成的CSV。

第二种情形 – 从查询“Summary: This bug doesn’t exist”生成的CSV。

第3种情形 – 从查询“Summary: This bug exists OR Summary: This bug doesn’t exist”生成的CSV

正如我们所看到的,在第一和第三种情形,我们将有一个任意大的CSV,因为两个查询都匹配一个错误摘要“This bug exists”。在第二种情况下,CSV将为空(仅包含标题),因为查询不匹配任何错误摘要“This bug doesn’t exist”。请注意,在第三种情形下,我们使用逻辑运算符OR来一起查询第一和第二种情形。

四、查询

我在尝试创建PoC时遇到的一个问题是决定搜索什么。Monorail的搜索不允许查询报告中的特定字母,只能查询单词。这意味着我们不能通过字符暴力穷尽报告。

在意识到这一点之后,我不得不后退一步,搜索旧的漏洞报告,寻找相关的信息,并且可以通过攻击真实的泄露出来。

那时我才知道许多Chromium bug报告指出了可以找到漏洞的文件路径和行号。

这是一个完美的XS-搜索攻击:由于Chromium的文件夹结构是公开的并且Monorail将斜杠视为字分隔符(查询“path/to/dir”还包含字符串“path/to/dir/sub/dir”的查询结果),我们可以轻松生成相应的搜索查询。

所以我们的攻击是这样:

1.我们发现是否有任何私人漏洞报告在Chromium的源树中提到了一个文件。我们使用https://cs.chromium.org/chromium/src/作为基本查询。

2.我们使用OR运算符搜索src /下所有目录的前半部分(例如src/blink或src/build …)。

3.我们继续使用二分法重复步骤2。如果有结果(即生成了一个大的CSV),我们将搜索空间限制在前半部分。否则(即,生成空CSV),我们将搜索空间限制为后半部分。

4.只保留一个目录,重新启动第2步,将新找到的目录添加到基本查询的末尾。

在此过程结束时,完整的URL将被泄露,我们现在可以(作为攻击者)查看相应的文件并尝试查找报告的漏洞。

五、一个请求搞定一切

你可能想知道我们是如何在步骤3中获得CSV的大小的。由于Same-Origin策略禁止我们访问不同来源的信息,因此response.length将不起作用。

虽然我们无法确切知道响应的确切大小,但我们可以衡量每个请求完成所需的时间。使用前面部分中介绍的响应长度膨胀技术,返回不存在漏洞的搜索比完成漏洞的搜索慢得多。

但是,为提高准确性,仅仅一个请求是不够的。我们需要多次请求同一页面并测量平均响应时间以获得可靠的利用。

这就是Cache API派上用场的时候,只需要发出一个请求并重复计算响应缓存的持续时间,就可以肯定的推断出搜索查询的结果是否返回了漏洞。

换句话说,较小的响应比较大的响应花费更少的时间来缓存。鉴于Cache API几乎没有任何限制(而且速度非常快),我们可以多次缓存和测量相同的响应,然后将其与已知空搜索查询结果的测量结果进行比较,这样我们就可以轻松区分来自小/空的大响应,过滤掉硬件和网络差异,提高漏洞利用的速度和可靠性。

有关如何实现此功能的更多信息,可以查阅漏洞利用代码

六、后话

总的来说,我找到了可以进行此攻击的三个不同的地方,漏洞编号为CVE-2018-10099,CVE-2018-19334和CVE-2018-19335。

每个漏洞获得奖励3133,7美元,总计超过9400美元。

参考

[1] Commit fixing the CSRF in Monorail’s CSV file download (https://chromium.googlesource.com/infra/infra/+/bdb78934b151ac75bf41711797bbf81130c5a502).

[2] Commit fixing the duplicated columns bug (https://chromium.googlesource.com/infra/infra/+/0ff6b6453b6192987bd9240c1e872a7de5fb1313).

[3] Commit disallowing double grid axes and Cc axis (https://chromium.googlesource.com/infra/infra/+/77ef00cb53d90c9d1f984eca434d828de5c167a5).

[4] Commit preventing request inflation through the groupby parameter (https://chromium.googlesource.com/infra/infra/+/e27936ef82d33a5f286e1f2f22817aa682f79e90).

本文翻译自:https://medium.com/@luanherrera/xs-searching-googles-bug-tracker-to-find-out-vulnerable-source-code-50d8135b7549如若转载,请注明原文地址: http://www.4hou.com/vulnerable/14953.html
点赞 6
  • 分享至
取消

感谢您的支持,我会继续努力的!

扫码支持

打开微信扫一扫后点击右上角即可分享哟

发表评论