糟糕！超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
譯者 | 彎月
責編 | 屠敏
以下為譯文：
北卡羅來納州大學（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翻譯，轉載請註明來源出處。
【End】
