每天都有各種各樣的API密鑰、密碼和客戶數(shù)據(jù)被發(fā)布到Github上。黑客使用這些密鑰登錄服務(wù)器，并收取費(fèi)用，Github泄密可能會(huì)給公司造成數(shù)千甚至數(shù)百萬(wàn)美元的損失。在Github上收集源碼的情報(bào)已經(jīng)成為每個(gè)網(wǎng)安工作人員的必備手段，有研究人員還針對(duì)該主題寫了一篇學(xué)術(shù)論文。

本文是為bug賞金獵人以及其安全團(tuán)隊(duì)編寫的，演示了用戶發(fā)布到Github公共存儲(chǔ)庫(kù)的常見敏感信息類型，以及查找這些秘密的啟發(fā)性方法。本文中的技術(shù)也可以應(yīng)用到GitHub Gist片段中。

在過(guò)去的一年里，我在沒有訪問程序網(wǎng)站的情況下，通過(guò)HackerOne上的漏洞獎(jiǎng)賞獲得了近1萬(wàn)美元的收益。向不同公司提交了30多份協(xié)同披露報(bào)告，其中包括8家財(cái)富500強(qiáng)公司。

我還發(fā)布了GitHound，這是一個(gè)開源工具，用于在GitHub上自動(dòng)查找密鑰。GitHound并不局限于單個(gè)用戶或組織，它會(huì)篩選整個(gè)Github倉(cāng)庫(kù)，使用代碼搜索查詢作為進(jìn)入存儲(chǔ)庫(kù)的入口點(diǎn)，然后使用上下文、正則表達(dá)式和其他一些巧妙的技巧快速查找密鑰。

Github代碼搜索

在我們進(jìn)入自動(dòng)化工具和漏洞獎(jiǎng)賞策略之前，我們先說(shuō)一說(shuō)代碼搜索。Github提供了豐富的代碼搜索，可以掃描GitHub公共存儲(chǔ)庫(kù)(這里忽略一些內(nèi)容，比如fork和非默認(rèn)分支)，像uberinternal.com那樣簡(jiǎn)單，也可以包含多個(gè)字符串，也可以包含類似"Authorization: Bearer"這樣的多單詞字符串，甚至可以針對(duì)特定的文件進(jìn)行搜索，(如文件名：vim_settings.xml)或特定的語(yǔ)言(如SQL)。還可以搜索vim_settings.xml。

了解了Github代碼搜索的規(guī)則，我們就可以設(shè)計(jì)出搜索dork，用它來(lái)查詢敏感信息，dork可以在網(wǎng)上找到，但最好的Dork都是自己創(chuàng)造的。

例如，filename: vim_settings.xml針對(duì)的是IntelliJ設(shè)置文件。有趣的是，vim_settings.xml文件包含最近用Base64編碼的復(fù)制粘貼字符串。我也因?yàn)榘l(fā)現(xiàn)了這個(gè)問題而賺了2400美元，SaaS API密鑰和客戶信息在vim_settings.xml中被暴露。

xml只包含最近復(fù)制粘貼的字符串，但是我們可以利用存儲(chǔ)庫(kù)的提交歷史來(lái)查找整個(gè)復(fù)制粘貼歷史。只需要克隆代碼庫(kù)并運(yùn)行這個(gè)14行腳本，用戶的活動(dòng)就掌握在你手中，GitHound還可以查找并掃描base64編碼的字符串以查找密鑰，甚至在提交歷史中也是如此。

值得一提的是，通過(guò)Github提交搜索，我們可以用GitHound快速掃描查找base64編碼的字符串以查找密鑰，甚至在提交歷史中也是如此。

給Bug賞金獵人的一些啟發(fā)

Github的dork通常能找到敏感的密鑰，但如果我們想要尋找某個(gè)特定公司的信息呢?GitHub有數(shù)百萬(wàn)個(gè)存儲(chǔ)庫(kù)和更多的文件，因此我們需要一些啟手段來(lái)縮小搜索空間。

想要尋找敏感信息，首先要確定一個(gè)目標(biāo)，最好的辦法就是先從目標(biāo)公司基礎(chǔ)架構(gòu)中的域或子域下手。

用company.com搜索可能不會(huì)提供有用的結(jié)果，大多公司發(fā)布的開源項(xiàng)目都是經(jīng)過(guò)審核的，不太可能包含密鑰，較少使用的域和子域機(jī)會(huì)還大一些，其中包含主機(jī)，如jira.company.com，以及更一般的二級(jí)和低級(jí)域名。查找模式比查找單個(gè)域更有效：corp.somecompany.com、somecompany.net或companycorp.com更有可能只出現(xiàn)在員工的配置文件中。

以下常見的開源情報(bào)與域偵查工具可能會(huì)對(duì)你有所幫助：

• Subbrute - 用于蠻力破解子域的Python dork
• ThreatCrowd - 給定一個(gè)域，通過(guò)多種OSINT技術(shù)查找相關(guān)域
• Censys.io- 給定一個(gè)域，找到使用它的SSL證書

GitHound還可以幫助進(jìn)行子域發(fā)現(xiàn):添加一個(gè)自定義regex \.company\.com并使用——regex文件標(biāo)志運(yùn)行GitHound。

在找到要搜索的主機(jī)或模式后，可以使用GitHub搜索(在使用自動(dòng)化工具之前，我總是這樣做)。這里要注意以下幾個(gè)問題：

• 搜索出來(lái)的結(jié)果有多少?如果有超過(guò)100個(gè)頁(yè)面，我可能需要找到一個(gè)更好的查詢重新開始(Github將代碼搜索結(jié)果限制為100頁(yè))。
• 結(jié)果是什么?如果搜索結(jié)果主要是開源項(xiàng)目和使用公共api的人，那么我可能可以改進(jìn)搜索把這些去掉。
• 如果改變語(yǔ)言會(huì)發(fā)生什么?language:Shell 與 language:SQL可能會(huì)產(chǎn)生有趣的結(jié)果。
• 這些結(jié)果是否揭示了其他域名或主機(jī)?前幾頁(yè)的搜索結(jié)果通常會(huì)包含對(duì)另一個(gè)域名的引用(比如搜索jira.uber.com可能會(huì)顯示另一個(gè)域名的存在，比如uberinternal.com)。

我在這一方面花了大量的時(shí)間，搜索空間的定義和它的準(zhǔn)確性是至關(guān)重要的，自動(dòng)工具和手動(dòng)搜索將更快和更準(zhǔn)確的查詢。

一旦我根據(jù)上面的標(biāo)準(zhǔn)發(fā)現(xiàn)了有趣的結(jié)果，我就會(huì)使用帶有 --dig-files 及 --dig-commits 參數(shù)在GitHound中運(yùn)行，查看整個(gè)存儲(chǔ)庫(kù)的歷史。

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還可以找到簡(jiǎn)單搜索無(wú)法找到的有趣文件，比如.zip或.xlsx文件。重要的是，我還手動(dòng)查看結(jié)果，因?yàn)樽詣?dòng)化工具經(jīng)常會(huì)漏掉客戶信息、敏感代碼和用戶名/密碼組合。通常，這將會(huì)讓你發(fā)現(xiàn)更多的子域名或其他有趣的東西，給我更多搜索查詢的想法，最重要的是要記住，開源情報(bào)是一個(gè)遞歸的過(guò)程。

這個(gè)過(guò)程幾乎都能讓你有所得，泄露通常分為以下幾類(從影響最大到影響最小)：

• SaaS API密鑰——公司很少對(duì)API施加IP限制。AWS、Slack、谷歌和其他API密鑰都是機(jī)會(huì)。這些通?？梢栽谂渲梦募ash歷史文件和腳本中找到。
• 服務(wù)器/數(shù)據(jù)庫(kù)憑證——這些通常在防火墻后面，所以它們的影響較小。通常可以在配置文件、bash歷史文件和腳本中找到。
• 客戶/員工信息——這些信息隱藏在XLSX、CSV和XML文件中，范圍從電子郵件一直到賬單信息和員工績(jī)效評(píng)估。
• 數(shù)據(jù)科學(xué)腳本 - SQL 查詢、R 腳本以及 Jupyter 項(xiàng)目等都有可能暴露敏感信息。這些庫(kù)中也往往帶有“測(cè)試數(shù)據(jù)”文件。
• 主機(jī)名/元數(shù)據(jù)——最常見的結(jié)果，大多數(shù)公司不認(rèn)為這是一個(gè)漏洞，但他們可以幫助改進(jìn)未來(lái)的搜索。

針對(duì)特定 API 提供程序的入侵流程

還可以特定的API提供者及其端口創(chuàng)建Dork，這對(duì)于為用戶的API密鑰創(chuàng)建自動(dòng)檢查的公司尤其有用。通過(guò)了解API鍵的上下文和語(yǔ)法，可以明顯減少搜索空間。

通過(guò)了解特定的API提供者，我們可以獲得與API提供程序正則表達(dá)式相匹配的密鑰，然后我們可以使用內(nèi)部數(shù)據(jù)庫(kù)或API端點(diǎn)檢查它們的有效性。

例如，假設(shè)一家公司(HalCorp)為用戶提供了一個(gè)API來(lái)讀寫他們的帳戶。通過(guò)創(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響應(yīng)編寫自己的GitHub程序：

# Python 
"authenticate_by_key" "halapi" language:python 
 
# REST API 
"HALCorp-Key" 

使用GitHound這樣的工具，我們可以使用正則表達(dá)式匹配來(lái)找到匹配API鍵的正則表達(dá)式的字符串，并將它們輸出到文件中：

echo "HALCorp-Key" | git-hound --dig-files --dig-commits --many-results --regex-file halcorp-api-keys.txt --results-only > api_tokens.txt 

現(xiàn)在我們有了一個(gè)包含潛在API令牌的文件，我們可以根據(jù)數(shù)據(jù)庫(kù)檢查這些令牌的有效性(如果沒有API提供者的書面許可，請(qǐng)不要這樣做)。

對(duì)于HalCorp，我們可以編寫一個(gè)bash腳本來(lái)讀取stdin，檢查api.halcorp.biz/userinfo端點(diǎn)，并輸出結(jié)果。

最后的啟發(fā)

盡管人們對(duì)GitHub上的敏感信息曝光的意識(shí)有所增強(qiáng)，但每天被曝光的敏感數(shù)據(jù)依然很多，如果用戶的API密鑰被發(fā)布到網(wǎng)上，Amazon Web服務(wù)已經(jīng)開始通知用戶。GitHub增加了一些安全功能，可以掃描公共存儲(chǔ)庫(kù)以獲取通用密鑰。然而這些措施治標(biāo)不治本，為了遏制源代碼的秘密泄露，我們必須更新API框架和DevOps方法，以防止API密鑰完全存儲(chǔ)在Git/SVN存儲(chǔ)庫(kù)中。像Vault這樣的軟件可以安全地存儲(chǔ)產(chǎn)品密鑰，而一些API提供商，像谷歌云平臺(tái)，已經(jīng)更新了他們的庫(kù)，強(qiáng)制API密鑰默認(rèn)存儲(chǔ)在一個(gè)文件中。

徹底根除敏感信息的暴露是一個(gè)比較困難的問題，如何才能完全檢測(cè)到用戶信息?如果是Word、Excel或編譯文件呢?我們還需要在這個(gè)領(lǐng)域進(jìn)行更多的研究，才有可能找出解決方法。