糟糕！超100000萬個 GitHub 倉庫泄露了 API 及加密密鑰！

日前，來自北卡羅來納州大學（NCSU）的團隊對全球知名的開發者社區 GitHub 開展了一項深入的研究，研究人員在使用 GitHub Search API 獲取並分析了代表681784個代碼庫的4394476個文件，以及代表谷歌的BigQuery資料庫中記錄的3374973個代碼庫的另外2312763353個文件之後，令人詫異的結果出現了，其中，研究人員發現了575456個 API 和加密密鑰，其中 201642 個是唯一的，所有這些密鑰分布在100000多個 GitHub 項目中，而且使用 Google Search API 找到的密鑰和通過 Google BigQuery 數據集找到的密鑰是幾乎沒有重疊。

最終，該團隊表示，他們跟蹤的 API 和加密密鑰中有6％在泄漏後一小時內被刪除，超過12％的密鑰在一天後被刪除，而19％的密鑰暴露了16天。

作者 | Adrian Colyer

譯者 | 彎月

責編 | 屠敏

出品 | CSDN（ID：CSDNnews）

以下為譯文：

北卡羅來納州大學（NCSU）的團隊發布的論文《How bad can it git? Characterizing secret leakage in public GitHub repositories》

• https://www.ndss-symposium.org/wp-content/uploads/2019/02/ndss2019_04B-3_Meli_paper.pdf

你可能會說，這不是什麼新鮮事。我們知道開發人員不應該提交密鑰，我們也知道泄漏到GitHub上的密鑰很快就會被人發現和利用。不過這篇論文進行了更深入的研究，所以能夠為我們提供一些非常切合實際的信息。

「……我們不僅注意到了泄漏發生的情況，而且還對泄漏進行了保守的縱向分析，以及對其根本原因的分析和當前緩解措施的局限性。」

在我看來，避免密鑰提交的最佳時機在提交之前。而在Git的pre-commit鉤子中使用這篇論文附錄中介紹的正則表達式就是個非常好的辦法。TruffleHog（https://github.com/dxa4481/truffleHog）就採用了pre-commit鉤子的方法，但是在該論文撰寫的時候，TruffleHog的密鑰檢測機制（僅能檢測到25-29%）明顯低於這篇論文的成果（§VII.D節）。你還可以看一下為防止AWS密鑰提交而開發的git-secrets（https://github.com/awslabs/git-secrets），你可以在這個工具的基礎上自行用其他正則表達式進行擴展。為了做到萬無一失，你還可以考慮與GitHub集成，在密鑰被泄漏時提醒你，這樣你就可以及時廢除密鑰了。

下面來簡要介紹一下這篇論文的主要內容：

前言

• 使用GitHub API可以很容易地實時檢測到密鑰的泄漏，即使在實現中僅使用一個API key，並採用默認的速率限制，也能達到很好的效果。這篇論文中介紹的方法實現了99%的目標文件覆蓋率。
• 即使我們都心懷善意，但還是有很多密鑰被泄漏（每天被泄漏的密鑰中位數為1793個）。
• 通過論文中介紹的搜索方法，找到泄露到GitHub上的密鑰的時長為半秒到4分鐘以上，中位數為20秒。也就是說，一眨眼的功夫就能找到，等你發覺自己不小心提交了密鑰時就已經晚了。
• 泄露的密鑰中看似非常敏感的密鑰佔了很高的比例（89%），也就是說這些都不是用於測試的密鑰。
• 使用多元認證方式（例如Google OAuth ID）的情況下，如果其中一個密鑰key被泄漏時，另一個也會被泄漏的概率高達80%。
• 許多泄漏的密鑰都會在GitHub代碼倉庫中保存很長一段時間（16天後仍有81%還在）。
• 即使重寫歷史記錄也無法在密鑰泄露後隱藏密鑰。（你需要立即廢除密鑰，這很顯然，對吧？）

如果沒有保護措施，人類就很容易犯錯。（也就是說，如果你的流程不完善，請不要責怪開發人員！）。

「我們的數據顯示，即使是由經驗豐富的開發人員負責的重要密鑰也有可能泄漏。舉個例子，美國數百萬學生申請大學時使用的一個主要網站採用了AWS認證，然而我們發現該認證使用的密鑰可能被一個工作人員泄漏了。我們還發現西歐國家的主要政府機構的網站也採用了AWS認證……」

如何檢測GitHub中的密鑰

至少有兩個非常好的信息來源可以用來檢測密鑰：GitHub Search API以及Google BigQuery維護的GitHub公共數據集。檢測過程的第一步是通過精心設計的一組搜索詞，查詢可能包含密鑰的候選文件：

拿到一組候選文件後，接下來你需要的是一組流行密鑰格式的正則表達式。論文的作者研究了很多流行系統和服務的關鍵結構，並發現了下圖所示的結果。事實證明，論文附錄中提供的下列正則表達式在尋找密鑰時非常準確。例如：

然後，你可以使用這些正則表達式掃描上述第一階段獲得的候選文件，所有的匹配都可能是「候選密鑰」。然後，通過一組過濾器篩查這些候選密鑰。例如，密鑰模式「AKIAXXXEXAMPLEKEYXXX」很可能是在測試時使用的，該密鑰將在這個階段被過濾掉。順利通過這些過濾器的密鑰集即是真正遭到泄漏的密鑰。論文的作者手動驗證了一個隨機的密鑰集合樣本，這個過程發現的密鑰中估計有89.1%確實屬於敏感信息。

GitHub搜索

GitHub Search API具有速率限制。但是只需要使用一個API key，那麼每隔30分鐘就可以運行完所有用來查找候選文件的查詢。論文的作者發現，這個頻率足以發現99%可能包含密鑰的文件，而且沒有速率限制。

「這一結果表明，一個用戶在GitHub的API速率限制內，完全可以合法地運行敏感搜索查詢，從而幾近完美地找到所有提交到GitHub上的文件。當然，有強烈動機的攻擊者可以獲取多個API key，並實現全面的覆蓋。」

在另一項測試中，論文的作者故意將「密鑰」push到了某個已知的代碼庫中，並持續查詢API，直到該字元串出現。該實驗以每分鐘一次的頻率進行了24小時。

「我們發現找到密鑰的時長為半秒到4分鐘，中位數為20秒，而且沒有明顯的時段影響。重要的是，這項實驗表明我們的搜索API方法幾乎可以立即發現密鑰，也就是說幾乎可以實時地發現密鑰。」

GitHub Search API搜索了從2017年10月31日到2018年4月20日的所有文件。在此期間收集了440萬候選文件，並從30.7萬文件中找到了40萬個密鑰。這項搜索每天發現新密鑰的中位數為1793個。

Google BigQuery數據集

Google在許可下維護著公共GitHub代碼倉庫的BigQuery數據集。論文作者的這個數據集是於2018年4月4日查詢到的，當時掃描了330萬個代碼倉庫中的23億個文件，總共發現了73,799個唯一的密鑰字元串。

有效性過濾器

該數據集使用了如下三個有效性的過濾器來過濾掉假陽性：

• 熵過濾器，可以過濾掉熵非常低的密鑰。
• 單詞過濾器，可以過濾掉包含長度不小於5的常用單詞的密鑰。
• 模式過濾器，可以過濾掉重複字元（例如"AAAA"），升序字元（"ABCD"）和降序字元（"DBCA"）。

至少這些過濾器表明，正則表達式檢測到的密鑰中只有一小部分是虛假密鑰。與正則表達式相匹配的字元串中99.29%通過了過濾器。如果你的工作中也需要實現這樣的過濾器，那麼可以使用「所有虛假的密鑰中都包含EXAMPLE之類的單詞」這種更為簡單的實現。

作者團隊發現了哪些類型的密鑰？

作者團隊提出的每一種密鑰類型中都找到了泄露的密鑰！下表只給出了一部分，而最常見的泄露密鑰是針對Google API的密鑰。

我認為所有密鑰類型的泄漏概率應該都差不多，因此上述表格表明GitHub代碼倉庫中不同API的流行程度。

重寫歷史記錄

「很明顯，實時監控代碼提交的人可以馬上發現泄漏的密鑰，即使泄漏的密鑰被簡單地刪除也能被捕獲到。然而根據我們的發現，即使重寫提交歷史記錄，密鑰也仍然可以被恢復……我們發現只需要使用commit的SHA-1 ID就可以從GitHub中恢復已刪除提交的全部內容。」

通過Events API可以很容易地恢復提交的哈希值。這個API的歷史數據也可通過GitTorrent項目獲得。

總結

「這項工作表明公共代碼倉庫平台上的密鑰泄漏問題非常嚴重，這個問題尚未得到解決，開發人員和服務都置身於泄漏和濫用的風險之中。」

GitHub的測試版中有一個掃描token的功能，該功能可以從一組有限的提供者中查找token，並在密鑰提交到公共代碼倉庫時通知提供者（不是你）。

原文：https://blog.acolyer.org/2019/04/08/how-bad-can-it-git-characterizing-secret-leakage-in-public-github-repositories/

本文為CSDN翻譯，轉載請註明來源出處。

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