2023年8月21日，安全研究人員兼HackerOne顧問委員會成員Corben Leo在社交媒體上宣布，他侵入了一家汽車公司，隨后發(fā)布了一則帖子，解釋如何獲得了數(shù)百個代碼庫的訪問權(quán)限。
圖1
Corben參加了由這家汽車制造商發(fā)起的漏洞懸賞計(jì)劃。漏洞懸賞是眾多行業(yè)一種非常普遍的做法，旨在獎勵道德黑客發(fā)現(xiàn)問題并以負(fù)責(zé)任的方式報(bào)告問題，這種做法久經(jīng)時間的考驗(yàn)，為許多公司帶來了顯著的效果。與此同時，有報(bào)道稱與其他行業(yè)相比，汽車制造商支付的漏洞賞金往往少得多。
就本文這個案例而言，這家汽車公司給出了合理的獎勵，Corben也有合理的動機(jī)去發(fā)現(xiàn)和報(bào)告這個可能引發(fā)危機(jī)的漏洞。Corben在帖子中闡述了其攻擊方法。簡而言之，通過反復(fù)試錯，他找到了所謂的入站控制器，這其實(shí)是用于Kubernetes環(huán)境的負(fù)載均衡器，通過蠻力攻擊，操縱主機(jī)報(bào)頭，他發(fā)現(xiàn)了一個錯誤配置的Spring Boot Actuator(Sprint Boot框架的子項(xiàng)目)，該Actuator使用HTTP端點(diǎn)來公開運(yùn)行應(yīng)用程序方面的操作信息，他發(fā)現(xiàn)的端點(diǎn)是' /env '和' /heapdump '端點(diǎn)。這時候憑據(jù)登場亮相了。
圖2
' /env '端點(diǎn)擁有經(jīng)過適當(dāng)編輯處理的密碼，這意味著進(jìn)入了死胡同，然而，' /heapdump'端點(diǎn)含有存儲在內(nèi)存中的應(yīng)用程序?qū)ο蟮目煺?，暴露了明文格式的憑據(jù)。在搜索關(guān)鍵字僅僅幾分鐘后，他就找到了oauth2憑據(jù)，他利用這些憑據(jù)訪問了一個之前發(fā)現(xiàn)的config-server實(shí)例;同樣由于另一個錯誤配置的Spring Boot Actuator，他找到了另一組' /env '和' /heapdump '端點(diǎn)。
不過這一回，'/env'端點(diǎn)沒有編輯憑據(jù)。Corben現(xiàn)在有了GitHub代碼庫管理員的私鑰和密碼，這個管理員可以訪問30多個GitHub組織，并對數(shù)百個代碼庫擁有讀寫訪問權(quán)。
圖3
如果不道德的黑客先發(fā)現(xiàn)了這個漏洞，這家汽車公司可能會泄露其所有的私有代碼庫或遭到勒索，正如我們所看到的，不是所有的公司都這么幸運(yùn)，包括三星、英偉達(dá)、微軟和優(yōu)步。
剖析出了什么岔子?
這個場景涉及多個問題：錯誤配置、暴露的明文密碼和范圍確定。
錯誤配置是攻擊者最好的朋友
雖然我們不能確定這家汽車公司的DevOps團(tuán)隊(duì)是如何部署其基礎(chǔ)設(shè)施的，但很有可能他們會使用基礎(chǔ)設(shè)施即代碼(IaC)，比如Terraform、Crossplane或CloudFormation。IaC有一些重大的優(yōu)點(diǎn)，因?yàn)榕渲每梢钥焖俚剡M(jìn)行版本控制和審查，使整個環(huán)境具有極大的可擴(kuò)展性。然而，最大的缺點(diǎn)之一是代碼中的錯誤配置可能意味著相同的問題推廣到整個環(huán)境中的每個實(shí)例，這可能就是相同的錯誤配置出現(xiàn)在多臺服務(wù)器上的原因。
在流程的早期測試錯誤配置，是確保它們不會出現(xiàn)在生產(chǎn)環(huán)境中的最佳方法，GitGuardian的客戶使用gghield用于IaC掃描已有很長一段時間了?，F(xiàn)在，我們通過新的基礎(chǔ)設(shè)施代碼安全模塊將相同的這項(xiàng)掃描功能添加到GitGuardian平臺，客戶可以在儀表板上看到100多次自動掃描的結(jié)果，并協(xié)調(diào)修復(fù)過程。
無論你如何部署基礎(chǔ)設(shè)施(手動部署還是通過IaC部署)，都要確保添加了審查過程來覆蓋常見的場景，我們還鼓勵I(lǐng)aC方面剛?cè)胧值淖x者了解《WASP云原生應(yīng)用程序十大安全漏洞》(https://owasp.org/www-project-cloud-native-application-security-top-10/?ref=blog.gitguardian.com)，知道測試時應(yīng)該留意什么漏洞。
暴露密碼
到目前為止，我們希望每個人都知道以明文形式存儲密碼是個壞主意，然而我們也知道，進(jìn)入到公共GitHub代碼庫的暴露密碼數(shù)量每年都在增長。在本文，我們確實(shí)看到了為確保機(jī)密(secrets)安全而花費(fèi)心思的證據(jù)，因?yàn)镃orben遇到的初始' /env '端點(diǎn)確實(shí)擁有經(jīng)過編輯的憑據(jù)，然而，他們忽略了' heapdump '端點(diǎn)中的日志文件。
檢查任何地方的機(jī)密至關(guān)重要，不僅僅是所編寫的代碼中的機(jī)密，還有代碼生成的任何文件(包括日志)中的機(jī)密，這就是ggshield(GitGuardian CLI)可以掃描任意文件或路徑查找機(jī)密的原因之一。手動審查日志的代碼可能會發(fā)現(xiàn)明文憑據(jù)的存在，但是始終使用工具進(jìn)行測試的團(tuán)隊(duì)更容易及早發(fā)現(xiàn)問題，如果他們清理了那個端點(diǎn)上的日志，這將是內(nèi)容全然不同的社交媒體帖子。
超級管理員憑據(jù)
Corben發(fā)現(xiàn)的GitHub憑據(jù)不僅授予對單個私有代碼庫的訪問權(quán)，甚至還授予對單個私有組織的訪問權(quán)，他報(bào)告自己獲得了對30多個組織和數(shù)百個代碼庫的訪問權(quán)限，需要這種級別的跨組織協(xié)作可能有其合理的理由。然而，這感覺像是有人使用根用戶憑據(jù)來處理所有事情，安全界的共識是始終致力于實(shí)現(xiàn)零信任架構(gòu)，并運(yùn)用最小特權(quán)原則。
Mackenzie Jackson在其文章《管理和存儲包括API密鑰和其他憑據(jù)在內(nèi)的機(jī)密的最佳實(shí)踐》中討論了最小權(quán)限的這個原則，所有憑據(jù)都應(yīng)該嚴(yán)格限定在其預(yù)期目的范圍內(nèi)，只授予完成特定任務(wù)所需的最小權(quán)限，創(chuàng)建一個只能訪問非常特定的代碼庫的新用戶可能是一條更好的途徑，這意味著Corben將擁有一些訪問權(quán)限，但無法訪問密鑰。
漏洞懸賞和安全研究的重要性
實(shí)際上，互聯(lián)網(wǎng)上的每個應(yīng)用程序都在不斷地接受安全測試。問題就在于誰在測試，以及測試的目的是什么，我們一直在與攻擊者玩貓捉老鼠的游戲，總是試圖比對方領(lǐng)先一步。參與漏洞懸賞計(jì)劃、雇用滲透測試人員來發(fā)現(xiàn)和利用應(yīng)用程序和環(huán)境中的漏洞，這些都是確保你在攻擊者之前發(fā)現(xiàn)問題的好方法。
外頭有很多道德黑客等著與你合作，幫助你確保安全，如果你正在尋找有關(guān)漏洞懸賞平臺方面的更多信息，請查看HackerOne、Bugcrowd或Open Bug Bounty，這是三個最受歡迎的平臺。你也可以看看Jason Haddix最近的安全代碼庫播客(
https://open.spotify.com/episode/2270puN1UHeeC7qkvaiaMo?ref=blog.gitguardian.com)，他暢談了自己作為漏洞賞金獵人和育碧(UbiSoft)CIO的經(jīng)歷，保證你的應(yīng)用程序和客戶的安全是一個過程。
我們可以從這個例子及其他例子中汲取很多教訓(xùn)。本文提醒我們在確定憑據(jù)的范圍時應(yīng)遵循最小特權(quán)原則，不要添加明文形式的密碼，并進(jìn)行測試，以確保我們的基礎(chǔ)設(shè)施即代碼沒有錯誤配置。無論你在通往更安全的道路上處于哪個階段，我們都鼓勵你不斷學(xué)習(xí)，努力保持安全。
參考及來源：https://dzone.com/articles/researcher-finds-github-admin-credentials-of-car-c
來源：嘶吼專業(yè)版
在線咨詢
在線咨詢
0371-63319761