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