英文 | https://medium.com/@alex.birsan/messing-with-the-google-buganizer-system-for-15-600-in-bounties-58f86cc9f9a5
翻譯 | web前端開發（ID：web_qdkf)
你聽說過Google錯誤問題追蹤器嗎？可能不是，除非你是最近報告了Google工具錯誤的Google員工或開發人員。我也沒有，直到我注意到我的漏洞報告現在電子郵件通知之外的地方，並通過在其中打開新線程來處理時。
我才立即開始嘗試去了解它。
那麼這個網站到底是什麼？根據文檔，問題跟蹤器（內部稱爲Buganizer系統）是Google內部使用的工具，可用於在產品開發過程中跟蹤錯誤和功能請求。它可以在Google外部使用，供需要在特定項目上與Google團隊合作的外部公共和合作伙伴用戶使用。
換句話說，當某人發現Google產品有問題時，它就會出現在問題跟蹤器中。有道理吧？ 我們作爲外部用戶，我們只能看到冰山一角：一小部分預先批准的類別，以及Google有人明確添加外部帳戶（例如漏洞報告）的問題。但是到底有多少信息呢？
通過觀察分配給最新公共線程的數字ID，我們可以輕鬆估計該工具在內部獲得了多少使用。在Mountain View的工作時間內，每小時大約有2000–3000個問題被打開，其中只有0.1％是公開的。似乎該系統中的數據泄漏會產生很大的影響。讓我們一起來了解它！
1、獲取Google員工帳戶
發現問題跟蹤器後，我注意到的第一件事就是能夠通過將電子郵件發送到特殊地址來參與討論，如下所示：
（其中componentID是代表類別的數字，issueID是你正在響應的線程的唯一標識符）
這使我想起了一個最新的發現，即“票務技巧”，它使黑客能夠利用這種電子郵件系統滲透到組織的聊天系統中。考慮到這是一個@ google.com電子郵件地址，我嘗試使用該地址註冊Google的Slack團隊，並且確認頁面看上去非常有希望：
之前從未出現來自Slack的電子郵件。
我能想到的第二件事是獲得一個具有@ google.com主要電子郵件地址的Google帳戶，希望這可以給我Buganizer帶來的額外特權。Google不允許從Google外部註冊這樣的郵箱帳戶：
但是，我找到了一種繞過此過濾器的方法：如果我使用任何其他僞造的電子郵件地址進行了註冊，但無法通過單擊電子郵件收到的鏈接來確認帳戶，則可以無限制地更改我的電子郵件地址。使用這種方法，我將新的Google帳戶的電子郵件更改爲[email protected]。
不久之後，我在相應的問題頁面上收到了一封確認電子郵件，作爲一條消息：
真好！我單擊了確認鏈接，登錄了“問題跟蹤器”，然後…
我被重定向到公司登錄頁面。不，我的Google帳戶憑據在那裏不起作用。
但是，此帳戶爲我在Internet上其他地方提供了許多額外的好處，包括搭便車的能力（免費，也許嗎？），因此，這仍然是一個安全問題，爲惡意用戶打開了許多大門。
接受時間：11小時 | 賞金：3,133.7美元 | 優先級：P1
2、獲取有關內部票證的通知
在熟悉UI時引起我注意的另一個問題跟蹤器功能是爲項目加註星標的功能。爲問題加註星標意味着你對正在討論的問題感興趣，並且希望有人添加評論時收到電子郵件通知。
我注意到的有關此功能的有趣之處在於，當我嘗試在無法訪問的問題上使用該功能時，明顯沒有錯誤。訪問控制規則似乎從未應用到此終結點上，因此我登錄了第二個帳戶，並嘗試通過替換請求中的“問題ID”來從主帳戶中添加漏洞報告。然後，我看到了此消息，表示該操作已成功完成：
有1人爲該問題加註了星標。
監視公開的Google漏洞是否容易？我很快就此問題發表了評論，以查看我的虛構攻擊者帳戶是否會收到通知。
但是同樣，沒有電子郵件出現過。
出於某種原因，我真的不記得了，我決定對此進行一些進一步的測試。因此，我得到了最近的問題ID，並推斷出數千個ID的範圍，這些ID應該與數據庫中的最新問題一致。然後，我將所有星標了。
幾分鐘後，我的收件箱看起來像這樣：
打開收件箱時，我的第一個念頭是“ Jackpot！”。
但是，經過仔細檢查，這些線程中沒有發生特別有趣的事情。顯然，我只能竊聽與翻譯相關的對話，在該對話中，人們將辯論用不同語言傳達短語含義的最佳方法。
我甚至考慮過幾個小時不報告此情況，希望能找到一種提高嚴重性的方法。最後，我意識到Google安全團隊可能會對尋找可能的樞軸方法和變體感興趣，所以我發送了詳細信息。
接受時間：5小時|賞金：5,000美元|優先級：P0
3、遊戲結束
當你以外部用戶身份訪問問題跟蹤器時，其大多數功能都會被剝奪，從而使您擁有極其有限的特權。如果你想查看Google員工可以完成的所有出色工作，則可以在JavaScript文件中查找API端點。這些功能中的某些功能被完全禁用，其他功能只是隱藏在界面中。
在設計此係統的受限版本時，如果有人對某個問題失去興趣或不想再收到有關該問題的電子郵件，那麼有人會爲我們提供一種方法，讓我們將自己從抄送列表中刪除。這可以通過發送POST請求來實現，如下所示：
POST /action/issues/bulk_edit HTTP/1.1{ "issueIds":[ 67111111, 67111112 ], "actions":[ { "fieldName":"ccs", "value":"[email protected]", "actionType":"REMOVE" } ]}
但是，我注意到這裏的一些疏忽導致了一個巨大的問題：
不當的訪問控制：在嘗試執行給定操作之前，沒有明確檢查當前用戶是否實際有權訪問issueIds中指定的問題。
靜默失敗：如果你提供的電子郵件地址當前不在抄送列表中，則端點將返回一條消息，指出該電子郵件已成功刪除。
完整的問題詳細信息作爲響應：如果操作期間未發生錯誤，則系統的另一部分認爲用戶具有適當的權限。因此，有關給定問題ID的每個細節都將在HTTP響應正文中返回。
現在，我可以通過替換上面請求中的issueIds來查看有關數據庫中每個問題的詳細信息。
我只嘗試查看幾個連續的ID，然後從一個不相關的帳戶進行攻擊以確認此問題的嚴重性。
是的，我可以看到有關漏洞報告的詳細信息以及Buganizer上託管的所有其他內容。
更糟糕的是，我可以在一個請求中提取有關多個票證的數據，因此，實時監視所有內部活動可能不會觸發任何限速器。
我立即將漏洞利用細節發送給Google，一小時後，他們的安全團隊停用了受影響的端點。令人印象深刻的響應時間！
接受時間：1小時|賞金：7,500美元|優先級：P0
當我第一次開始尋找這種信息泄漏時，我以爲這是Google錯誤的聖盃，因爲它會披露其他所有錯誤的信息（例如，HackerOne至少要爲類似的問題支付10,000美元）。
但是在找到它之後，我很快意識到，將影響降到最低，因爲無論如何，所有危險漏洞都會在一小時內被消除。
我對額外的現金感到非常滿意，並期待發現其他Google產品中的錯誤。
