2023年8月21日，安全研究人員兼HackerOne顧問委員會成員Corben Leo在社交媒體上宣布，他侵入了一家汽車公司，隨后發(fā)布了一則帖子，解釋如何獲得了數(shù)百個代碼庫的訪問權(quán)限。

圖1

Corben參加了由這家汽車制造商發(fā)起的漏洞懸賞計劃。漏洞懸賞是眾多行業(yè)一種非常普遍的做法，旨在獎勵道德黑客發(fā)現(xiàn)問題并以負(fù)責(zé)任的方式報告問題，這種做法久經(jīng)時間的考驗，為許多公司帶來了顯著的效果。與此同時，有報道稱與其他行業(yè)相比，汽車制造商支付的漏洞賞金往往少得多。

就本文這個案例而言，這家汽車公司給出了合理的獎勵，Corben也有合理的動機(jī)去發(fā)現(xiàn)和報告這個可能引發(fā)危機(jī)的漏洞。Corben在帖子中闡述了其攻擊方法。簡而言之，通過反復(fù)試錯，他找到了所謂的入站控制器，這其實是用于Kubernetes環(huán)境的負(fù)載均衡器，通過蠻力攻擊，操縱主機(jī)報頭，他發(fā)現(xiàn)了一個錯誤配置的Spring Boot Actuator（Sprint Boot框架的子項目），該Actuator使用HTTP端點來公開運行應(yīng)用程序方面的操作信息，他發(fā)現(xiàn)的端點是' /env '和' /heapdump '端點。這時候憑據(jù)登場亮相了。

圖2

' /env '端點擁有經(jīng)過適當(dāng)編輯處理的密碼，這意味著進(jìn)入了死胡同，然而，' /heapdump'端點含有存儲在內(nèi)存中的應(yīng)用程序?qū)ο蟮目煺?，暴露了明文格式的憑據(jù)。在搜索關(guān)鍵字僅僅幾分鐘后，他就找到了oauth2憑據(jù)，他利用這些憑據(jù)訪問了一個之前發(fā)現(xiàn)的config-server實例；同樣由于另一個錯誤配置的Spring Boot Actuator，他找到了另一組' /env '和' /heapdump '端點。

不過這一回，'/env'端點沒有編輯憑據(jù)。Corben現(xiàn)在有了GitHub代碼庫管理員的私鑰和密碼，這個管理員可以訪問30多個GitHub組織，并對數(shù)百個代碼庫擁有讀寫訪問權(quán)。

圖3

如果不道德的黑客先發(fā)現(xiàn)了這個漏洞，這家汽車公司可能會泄露其所有的私有代碼庫或遭到勒索，正如我們所看到的，不是所有的公司都這么幸運，包括三星、英偉達(dá)、微軟和優(yōu)步。

剖析出了什么岔子？

這個場景涉及多個問題：錯誤配置、暴露的明文密碼和范圍確定。

錯誤配置是攻擊者最好的朋友

雖然我們不能確定這家汽車公司的DevOps團(tuán)隊是如何部署其基礎(chǔ)設(shè)施的，但很有可能他們會使用基礎(chǔ)設(shè)施即代碼（IaC），比如Terraform、Crossplane或CloudFormation。IaC有一些重大的優(yōu)點，因為配置可以快速地進(jìn)行版本控制和審查，使整個環(huán)境具有極大的可擴(kuò)展性。然而，最大的缺點之一是代碼中的錯誤配置可能意味著相同的問題推廣到整個環(huán)境中的每個實例，這可能就是相同的錯誤配置出現(xiàn)在多臺服務(wù)器上的原因。

在流程的早期測試錯誤配置，是確保它們不會出現(xiàn)在生產(chǎn)環(huán)境中的最佳方法，GitGuardian的客戶使用gghield用于IaC掃描已有很長一段時間了?，F(xiàn)在，我們通過新的基礎(chǔ)設(shè)施代碼安全模塊將相同的這項掃描功能添加到GitGuardian平臺，客戶可以在儀表板上看到100多次自動掃描的結(jié)果，并協(xié)調(diào)修復(fù)過程。

無論你如何部署基礎(chǔ)設(shè)施（手動部署還是通過IaC部署），都要確保添加了審查過程來覆蓋常見的場景，我們還鼓勵I(lǐng)aC方面剛?cè)胧值淖x者了解《WASP云原生應(yīng)用程序十大安全漏洞》，知道測試時應(yīng)該留意什么漏洞。

暴露密碼

到目前為止，我們希望每個人都知道以明文形式存儲密碼是個壞主意，然而我們也知道，進(jìn)入到公共GitHub代碼庫的暴露密碼數(shù)量每年都在增長。在本文，我們確實看到了為確保機(jī)密（secrets）安全而花費心思的證據(jù)，因為Corben遇到的初始' /env '端點確實擁有經(jīng)過編輯的憑據(jù)，然而，他們忽略了' heapdump '端點中的日志文件。

檢查任何地方的機(jī)密至關(guān)重要，不僅僅是所編寫的代碼中的機(jī)密，還有代碼生成的任何文件（包括日志）中的機(jī)密，這就是ggshield（GitGuardian CLI）可以掃描任意文件或路徑查找機(jī)密的原因之一。手動審查日志的代碼可能會發(fā)現(xiàn)明文憑據(jù)的存在，但是始終使用工具進(jìn)行測試的團(tuán)隊更容易及早發(fā)現(xiàn)問題，如果他們清理了那個端點上的日志，這將是內(nèi)容全然不同的社交媒體帖子。

超級管理員憑據(jù)

Corben發(fā)現(xiàn)的GitHub憑據(jù)不僅授予對單個私有代碼庫的訪問權(quán)，甚至還授予對單個私有組織的訪問權(quán)，他報告自己獲得了對30多個組織和數(shù)百個代碼庫的訪問權(quán)限，需要這種級別的跨組織協(xié)作可能有其合理的理由。然而，這感覺像是有人使用根用戶憑據(jù)來處理所有事情，安全界的共識是始終致力于實現(xiàn)零信任架構(gòu)，并運用最小特權(quán)原則。

Mackenzie Jackson在其文章《管理和存儲包括API密鑰和其他憑據(jù)在內(nèi)的機(jī)密的最佳實踐》中討論了最小權(quán)限的這個原則，所有憑據(jù)都應(yīng)該嚴(yán)格限定在其預(yù)期目的范圍內(nèi)，只授予完成特定任務(wù)所需的最小權(quán)限，創(chuàng)建一個只能訪問非常特定的代碼庫的新用戶可能是一條更好的途徑，這意味著Corben將擁有一些訪問權(quán)限，但無法訪問密鑰。

漏洞懸賞和安全研究的重要性

實際上，互聯(lián)網(wǎng)上的每個應(yīng)用程序都在不斷地接受安全測試。問題就在于誰在測試，以及測試的目的是什么，我們一直在與攻擊者玩貓捉老鼠的游戲，總是試圖比對方領(lǐng)先一步。參與漏洞懸賞計劃、雇用滲透測試人員來發(fā)現(xiàn)和利用應(yīng)用程序和環(huán)境中的漏洞，這些都是確保你在攻擊者之前發(fā)現(xiàn)問題的好方法。

外頭有很多道德黑客等著與你合作，幫助你確保安全，如果你正在尋找有關(guān)漏洞懸賞平臺方面的更多信息，請查看HackerOne、Bugcrowd或Open Bug Bounty，這是三個最受歡迎的平臺。你也可以看看Jason Haddix最近的安全代碼庫播客，他暢談了自己作為漏洞賞金獵人和育碧（UbiSoft）CIO的經(jīng)歷，保證你的應(yīng)用程序和客戶的安全是一個過程。

我們可以從這個例子及其他例子中汲取很多教訓(xùn)。本文提醒我們在確定憑據(jù)的范圍時應(yīng)遵循最小特權(quán)原則，不要添加明文形式的密碼，并進(jìn)行測試，以確保我們的基礎(chǔ)設(shè)施即代碼沒有錯誤配置，無論你在通往更安全的道路上處于哪個階段，我們都鼓勵你不斷學(xué)習(xí)，努力保持安全。