0x00 前言
在之前公佈的2020年春季雲端威脅報告中，我們側重於DevOps實踐內容，介紹了雲端出現的一些錯誤配置情況。在本文中，我們詳細分析了GitHub上的數據洩露情況，使DevOps、工程及安全團隊能夠重視該問題，及早發現並解決安全風險。
在代碼從開發到生產的快速跟蹤流程上，很少有其他數據倉庫能夠跟得上GitHub的腳步。然而俗話說的好，“速度越快，風險越高”。研究人員發現，如果使用了公共GitHub賬戶，那麼DevOps就有可能洩露敏感信息。與此同時，數據丟失或者被入侵的風險也會相應提高。然而，如果正確實現DevSecOps、使用GitHub Event API掃描器，就能大大降低洩露敏感信息的風險。
Unit 42研究人員通過GitHub Event API 分析了超過24,000份GitHub公開數據，發現有數千個文件中可能包含敏感信息，整體情況如下：
0x01 GitHub Event API
GitHub為開發者提供了一個Event API搜索功能，利用這一功能，開發者可以近乎實時地獲取上傳至GitHub服務器的文件及代碼列表。Event API可以幫助研究人員查看並掃描推送到GitHub公共區域的文件（比如公開分享的數據），但使用起來有些限制條件，每個賬戶每小時請求次數不超過5,000次。目前有多款工具用到了這一功能。在商業領域，GitHub自身提供並維護著GitHub Token Scanner解決方案，可以檢查文件中的令牌字符串，避免被用於欺詐、濫用等惡意場景。AWS使用了git-secrets來掃描用戶名、密碼及其他關鍵字符串，避免出現敏感數據洩露。此外還有一些開源GitHub Event API掃描器，如gitrob及trugglehog，紅方、滲透測試人員以及惡意用戶等都使用過這些工具來識別潛在的敏感信息。
0x02 ShhGit
Unit 42研究人員（以下簡稱我們）使用eth0izzle開發的shhgit來近實時讀取GitHub事件，並嘗試回答如下3個問題：
1、文件中是否可能發現潛在的敏感數據？
2、這些數據是否可以與某個單位關聯起來？
3、安全預防措施是否可以避免不必要的潛在敏感信息洩露？
以上3個問題的答案都是肯定的。經過分析後，我們發現有超過24,000個不同GitHub文件會觸發shhgit預定的120個特徵規則以及Unit 42設置的特徵規則。研究人員發現了一些潛在的敏感數據條目，包括：
- 4109個配置文件
- 2464個API密鑰
- 2328個硬編碼的用戶名及密碼
- 2144個私鑰文件
- 1089個OAuth令牌
進一步分析後，我們確認了結果的有效性，識別出文件所有者、項目名，在某些情況下還能識別出公開此信息的企業名稱。
0x03 研究結果
硬編碼密碼
我們經研究發現，最敏感的還是硬編碼密碼。我們總共找到了2328個用戶名及密碼條目，其中包括880個不同的密碼、797個不同的用戶名。這些密碼位於服務URL API以及SSH配置文件中。我們注意到，找到的密碼條目中只有18%與最常見的10個密碼有關。密碼“password”以72次排在榜首，第二名為密碼“secret”，共有51次。最常見的10個密碼如表1所示：
密碼次數password72secret51admin46123441db_password40*38pass45635root34pass-word-pass-word-pass-word29token26
表1. 最常見的10個密碼
比較有趣的是，在880個不同的密碼中，有817個密碼出現的次數等於或者少於3次，而有655個密碼只出現1次。這些密碼本身的非常獨特，因此也非常有趣。比如，我們抽樣了10個密碼，如下所示：
<code>p4ssW0rdeP@##w0rdPassword!qwerty123456789simplepass123sqluser2019supersecretwilson1234567xxxxxxxxxxxxxxxxxxxxZ*NsqgS5$@jHsF2/<code>
從直觀感受來看，我們注意到有些密碼在企業中非常常見。大多數密碼滿足最低密碼設置要求，並且也很容易記住（比如前兩個“password”變種密碼）。然而攻擊者很容易猜測出這些密碼，並且這些密碼也經常出現在大多數暴力破解字典中。此外，其餘8個密碼也屬於簡單密碼，只包含大小寫和數字組合，甚至只包含重複20次的x字符。由於這些密碼滿足偽複雜度模式，並且具有唯一性，因此我們認為這些密碼“很有可能是合法密碼”。也就是說，這些密碼很有可能是工程師在生產環境中實際使用的密碼。由於這些密碼的出現頻率很高，經常出現在常見雲服務（如Redis、PostgreSQL、MongoDB以及AMPQ等）的URL API請求中，因此雲環境本身也很有可能使用相同的偽複雜密碼。
相比之下，我們發現只有27個不同的實例使用了可變密碼字段，這表明這些實例使用的是臨時或者動態密碼。比如，有些實例中使用了$password、{password}或者%Password%佔位符。在我們找到的2328個密碼中，這27個不同的密碼實例總數只有67個，不到3%。
硬編碼API密鑰及OAuth令牌
在觸發規則的24,000多個GitHub文件中，我們共發現了2464個API密鑰、1998個OAuth令牌。這些元素大多互不相同，只有15個密鑰或令牌出現超過4次，只有1個元素出現次數最多（共12次），如表2所示。
API密鑰次數AIzaSyxxxxxxxxxxy2TVWhfo1VUmARKlG4suk12AIzaSyxxxxxxxxxx4kQPLP1tjJNxBTbfCAdgg9AIzaSyxxxxxxxxxxYmhQgOjt_HhlWO31cYfic8AIzaSyxxxxxxxxxxq_V7x_JXkz2llt6jhI5mI6AIzaSyxxxxxxxxxxnpxfNuPBrOxGhXskfebXs6AIzaSyxxxxxxxxxxRJ4c2tVRJxu8hZzcWA1fE5AIzaSyxxxxxxxxxxfUutD2aeWE1WFdnTBd_Jc5AIzaSyxxxxxxxxxxPdQUkRUerdohx28Fuv4wE5AIzaSyxxxxxxxxxxc2127s6TkcilVngyfFves4AIzaSyxxxxxxxxxx7SALQhZKfGBN3sFDs27Ps4AIzaSyxxxxxxxxxxJFdebWiX5KqyLHdakBOUU4AIzaSyxxxxxxxxxxVtidHrO1LXtfT3TFZuEOA4AIzaSyxxxxxxxxxxrzdcL6rvxywDDOvfAu6eE4AIzaSyxxxxxxxxxxEnTs4EfSxFIdFIdowigCs4AIzaSyxxxxxxxxxx4o82um7Gj1rY7R9W0apWg4
表2. 出現次數最多的前15個API密鑰
由於API密鑰及OAuth密鑰的特殊性，這些元素可以讓用戶直接訪問指定雲環境。如果API密鑰或者OAuth令牌落入他人之手，那麼惡意攻擊者可以仿冒工程師合法身份，獲得目標的控制權。在最壞的場景下，如果雲環境中API密鑰使用管理員權限創建，那麼使用該密鑰的任何人都具備雲賬戶的完全訪問權限。之前的確發生過合法API密鑰洩露事故，大家可以參考之前的UpGuard事件。在這次事件中，該公司通過GitHub洩露了將近1GB的數據，包括AWS API密鑰、日誌文件以及IaC模板。該事件中，服務及基礎設施配置文件中的合法API密鑰被公之於眾，這些憑據及API密鑰與商業組織所擁有的root賬戶有關。
與密碼一樣，密鑰及令牌必須受到嚴格保護及控制，確保只有合法用戶掌握這些信息。如果API密鑰或OAuth令牌丟失或者可能被洩露，那麼應當及時撤銷並重新生成。我們找到的2464個API密鑰及1098個OAuth令牌如表3所示，其中也列出了關聯的環境。
關聯環境次數Google Cloud API Key1998Google OAuth Token1098Miscellaneous – API_KEY358SonarQube Docs API Key84MailGun API Key19NuGet API Key4Twilo API Key1
表3. 洩露API及OAuth密鑰所關聯的環境
配置信息及私鑰文件
我們通過分析配置信息及私鑰文件，完成了對雲環境的深入分析。在觸發sshgit及Unit 42特徵規則的24,000個文件中，配置文件佔了絕大部分，將近17%。大多數配置文件類型為Django配置文件。在我們找到的所有配置文件類型中，這類配置文件將近佔了1/3，參考表4。Django是基於python的一個web框架，可以用來快速開發和設計。PHP是web設計中非常常見的一種腳本語言，在結果中排名第3。基於web的這些配置文件會暴露目標組織的雲架構信息，使攻擊者能夠輕鬆訪問內部雲服務器，也將使後續攻擊過程更加輕鬆。
配置文件數量Django配置文件1473環境配置文件601PHP配置文件587Shell配置文件（.bashrc、.zshrc、.cshrc）328潛在的Ruby On Rails數據庫配置文件266NPM配置文件233Shell profile配置文件211Shell命令別名配置文件130Git配置文件113SSH配置文件35
表4. 最常見的10類配置文件類型
我們發現環境及shell配置文件佔比較高，這類配置文件可以用來設置目標系統或服務的環境。Shell、SSH、profile及Git配置文件同樣排名前列。目標服務經常在配置文件中存放所需的用戶名、密碼、API密鑰或者令牌佔位符。我們發現有將近80%的配置文件會包含某些用戶名/密碼、API密鑰或者OAuth令牌。
0x04 總結
經過研究後，我們發現用戶會將敏感數據上傳到GitHub，這些敏感數據包括：
1、硬編碼的用戶名及密碼；
2、硬編碼的API密鑰；
3、硬編碼的OAuth密鑰；
4、內部服務及環境配置信息。
正如我們在雲端威脅報告中提到的，在CI/CD處置過程中，我們強烈建議從公共倉庫（如GitHub）拉取的所有IaC模板都要經過徹底掃描，確認是否存在漏洞。根據研究結果，我們掃描的每個CFT（CloudFormation template）中有將近一半都包含潛在的易受攻擊的配置信息，部署易受攻擊的雲模板的可能性非常大。此外，各種組織應當使用GitHub Event API掃描器，避免在GitHub上公開的代碼洩露敏感內部信息。
0x05 緩解措施
如果用戶及組織向GitHub倉庫提交代碼，我們建議部署如下緩解措施，確保配置文件不會洩露敏感信息：
1、採用可變且基於CLI參數的代碼開發實踐，從示例代碼中移除硬編碼用戶名及密碼、API密鑰以及OAuth令牌；
2、採用密碼安全策略，強制使用複雜密碼；
3、採用發佈策略，規範並防止通過外部資源共享內部敏感數據；
4、使用GitHub的企業賬戶功能，確保嚴格審查公開數據；
5、使用AWS-git secrets、GitHub TokenScanner、gitrob或者trugglehog 來識別並移除被公開的令牌。
大家可以下載 Unit 42的2020年春季雲端威脅報告，針對性強化環境中的安全措施。
原文鏈接：https://www.anquanke.com/post/id/198361
閱讀更多 安全客 的文章
