開源最前線（ID：OpenSourceTop） 猿妹整編
地址：https://tillsongalloway.com/finding-sensitive-information-on-github/index.html
每天都有各種各樣的API密鑰、密碼和客戶數據被髮布到Github上。黑客使用這些密鑰登錄服務器，並收取費用，Github洩密可能會給公司造成數千甚至數百萬美元的損失。在Github上收集源碼的情報已經成為每個網安工作人員的必備手段，有研究人員還針對該主題寫了一篇學術論文。
本文是為bug賞金獵人以及其安全團隊編寫的，演示了用戶發佈到Github公共存儲庫的常見敏感信息類型，以及查找這些秘密的啟發性方法。本文中的技術也可以應用到GitHub Gist片段中。
在過去的一年裡，我在沒有訪問程序網站的情況下，通過HackerOne上的漏洞獎賞獲得了近1萬美元的收益。向不同公司提交了30多份協同披露報告，其中包括8家財富500強公司。
我還發布了GitHound，這是一個開源工具，用於在GitHub上自動查找密鑰。GitHound並不侷限於單個用戶或組織，它會篩選整個Github倉庫，使用代碼搜索查詢作為進入存儲庫的入口點，然後使用上下文、正則表達式和其他一些巧妙的技巧快速查找密鑰。
Github代碼搜索
在我們進入自動化工具和漏洞獎賞策略之前，我們先說一說代碼搜索。Github提供了豐富的代碼搜索，可以掃描GitHub公共存儲庫（這裡忽略一些內容，比如fork和非默認分支），像uberinternal.com那樣簡單，也可以包含多個字符串，也可以包含類似"Authorization: Bearer"這樣的多單詞字符串，甚至可以針對特定的文件進行搜索，（如文件名：vim_settings.xml）或特定的語言（如SQL）。還可以搜索vim_settings.xml。
瞭解了Github代碼搜索的規則，我們就可以設計出搜索dork，用它來查詢敏感信息，dork可以在網上找到，但最好的Dork都是自己創造的。
例如，filename: vim_settings.xml針對的是IntelliJ設置文件。有趣的是，vim_settings.xml文件包含最近用Base64編碼的複製粘貼字符串。我也因為發現了這個問題而賺了2400美元，SaaS API密鑰和客戶信息在vim_settings.xml中被暴露。
xml只包含最近複製粘貼的字符串，但是我們可以利用存儲庫的提交歷史來查找整個複製粘貼歷史。只需要克隆代碼庫並運行這個14行腳本，用戶的活動就掌握在你手中，GitHound還可以查找並掃描base64編碼的字符串以查找密鑰，甚至在提交歷史中也是如此。
值得一提的是，通過Github提交搜索，我們可以用GitHound快速掃描查找base64編碼的字符串以查找密鑰，甚至在提交歷史中也是如此。
給Bug賞金獵人的一些啟發
Github的dork通常能找到敏感的密鑰，但如果我們想要尋找某個特定公司的信息呢？GitHub有數百萬個存儲庫和更多的文件，因此我們需要一些啟手段來縮小搜索空間。
想要尋找敏感信息，首先要確定一個目標，最好的辦法就是先從目標公司基礎架構中的域或子域下手。
用company.com搜索可能不會提供有用的結果，大多公司發佈的開源項目都是經過審核的，不太可能包含密鑰，較少使用的域和子域機會還大一些，其中包含主機，如jira.company.com，以及更一般的二級和低級域名。查找模式比查找單個域更有效：corp.somecompany.com、somecompany.net或companycorp.com更有可能只出現在員工的配置文件中。
以下常見的開源情報與域偵查工具可能會對你有所幫助：
- Subbrute - 用於蠻力破解子域的Python dork
- ThreatCrowd - 給定一個域，通過多種OSINT技術查找相關域
- Censys.io- 給定一個域，找到使用它的SSL證書
GitHound還可以幫助進行子域發現:添加一個自定義regex \.company\.com並使用——regex文件標誌運行GitHound。
在找到要搜索的主機或模式後，可以使用GitHub搜索(在使用自動化工具之前，我總是這樣做)。這裡要注意以下幾個問題：
- 搜索出來的結果有多少？如果有超過100個頁面，我可能需要找到一個更好的查詢重新開始（Github將代碼搜索結果限制為100頁）。
- 結果是什麼？如果搜索結果主要是開源項目和使用公共api的人，那麼我可能可以改進搜索把這些去掉。
- 如果改變語言會發生什麼？language:Shell 與 language:SQL可能會產生有趣的結果。
- 這些結果是否揭示了其他域名或主機?前幾頁的搜索結果通常會包含對另一個域名的引用（比如搜索jira.uber.com可能會顯示另一個域名的存在，比如uberinternal.com）。
我在這一方面花了大量的時間，搜索空間的定義和它的準確性是至關重要的，自動工具和手動搜索將更快和更準確的查詢。
一旦我根據上面的標準發現了有趣的結果，我就會使用帶有 --dig-files 及 --dig-commits 參數在GitHound中運行，查看整個存儲庫的歷史。
<code>echo
"uberinternal.com"
| ./git-hound --dig-files --dig-commitsecho
"uber.com"
| ./git-hound --dig-files --language-file languages.txt --dig-commitsecho
"uber.box.net"
| ./git-hound --dig-files --dig-commits/<code>
GitHound還可以找到簡單搜索無法找到的有趣文件，比如.zip或.xlsx文件。重要的是，我還手動查看結果，因為自動化工具經常會漏掉客戶信息、敏感代碼和用戶名/密碼組合。通常，這將會讓你發現更多的子域名或其他有趣的東西，給我更多搜索查詢的想法，最重要的是要記住，開源情報是一個遞歸的過程。
這個過程幾乎都能讓你有所得，洩露通常分為以下幾類（從影響最大到影響最小）：
- SaaS API密鑰——公司很少對API施加IP限制。AWS、Slack、谷歌和其他API密鑰都是機會。這些通常可以在配置文件、bash歷史文件和腳本中找到。
- 服務器/數據庫憑證——這些通常在防火牆後面，所以它們的影響較小。通常可以在配置文件、bash歷史文件和腳本中找到。
- 客戶/員工信息 ——這些信息隱藏在XLSX、CSV和XML文件中，範圍從電子郵件一直到賬單信息和員工績效評估。
- 數據科學腳本 - SQL 查詢、R 腳本以及 Jupyter 項目等都有可能暴露敏感信息。這些庫中也往往帶有“測試數據”文件。
- 主機名/元數據——最常見的結果，大多數公司不認為這是一個漏洞，但他們可以幫助改進未來的搜索。
針對特定 API 提供程序的入侵流程
還可以特定的API提供者及其端口創建Dork，這對於為用戶的API密鑰創建自動檢查的公司尤其有用。通過了解API鍵的上下文和語法，可以明顯減少搜索空間。
通過了解特定的API提供者，我們可以獲得與API提供程序正則表達式相匹配的密鑰，然後我們可以使用內部數據庫或API端點檢查它們的有效性。
例如，假設一家公司(HalCorp)為用戶提供了一個API來讀寫他們的帳戶。通過創建我們自己的HalCorp帳戶，我們發現API鍵的形式是[a-f]{4}-[a-f]{4}-[a-f]{4}。
<code>import
halapi api = halapi.API() api.authenticate_by_key('REDACTED'
) curl -X POST -H"HALCorp-Key: REDACTED"
https://
api.halcorp.biz/userinfo/<code>
有了這些信息，我們可以為HalCorp API響應編寫自己的GitHub程序：
<code>"authenticate_by_key"
"halapi"
language:python"HALCorp-Key"
/<code>
使用GitHound這樣的工具，我們可以使用正則表達式匹配來找到匹配API鍵的正則表達式的字符串，並將它們輸出到文件中:
<code>echo
"HALCorp-Key"
| git-hound --dig-files --dig-commits --many-results --regex-file halcorp-api-keys.txt --results-only > api_tokens.txt/<code>
現在我們有了一個包含潛在API令牌的文件，我們可以根據數據庫檢查這些令牌的有效性（如果沒有API提供者的書面許可，請不要這樣做）。
對於HalCorp，我們可以編寫一個bash腳本來讀取stdin，檢查api.halcorp.biz/userinfo端點，並輸出結果。
最後的啟發
儘管人們對GitHub上的敏感信息曝光的意識有所增強，但每天被曝光的敏感數據依然很多，如果用戶的API密鑰被髮布到網上，Amazon Web服務已經開始通知用戶。GitHub增加了一些安全功能，可以掃描公共存儲庫以獲取通用密鑰。然而這些措施治標不治本，為了遏制源代碼的秘密洩露，我們必須更新API框架和DevOps方法，以防止API密鑰完全存儲在Git/SVN存儲庫中。像Vault這樣的軟件可以安全地存儲產品密鑰，而一些API提供商，像谷歌雲平臺，已經更新了他們的庫，強制API密鑰默認存儲在一個文件中。
徹底根除敏感信息的暴露是一個比較困難的問題，如何才能完全檢測到用戶信息？如果是Word、Excel或編譯文件呢？我們還需要在這個領域進行更多的研究，才有可能找出解決方法。
