Google Monorail問題跟蹤器中發現了XS搜索漏洞

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

喜歡這篇文章嗎？立刻分享出去讓更多人知道吧！