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).