2023 年 8 月 21 日，安全研究人員兼 HackerOne 顧問委員會成員 Corben Leo 在社交媒體上宣布，他侵入了一家汽車公司，随後發布了一則帖子，解釋如何獲得了數百個代碼庫的訪問權限。
圖 1
Corben 參加了由這家汽車制造商發起的漏洞懸賞計劃。漏洞懸賞是衆多行業一種非常普遍的做法，旨在獎勵道德黑客發現問題并以負責任的方式報告問題，這種做法久經時間的考驗，爲許多公司帶來了顯著的效果。與此同時，有報道稱與其他行業相比，汽車制造商支付的漏洞賞金往往少得多。
就本文這個案例而言，這家汽車公司給出了合理的獎勵，Corben 也有合理的動機去發現和報告這個可能引發危機的漏洞。Corben 在帖子中闡述了其攻擊方法。簡而言之，通過反複試錯，他找到了所謂的入站控制器，這其實是用于 Kubernetes 環境的負載均衡器，通過蠻力攻擊，操縱主機報頭，他發現了一個錯誤配置的 Spring Boot Actuator（Sprint Boot 框架的子項目），該 Actuator 使用 HTTP 端點來公開運行應用程序方面的操作信息，他發現的端點是 ' /env ' 和 ' /heapdump ' 端點。這時候憑據登場亮相了。
圖 2
' /env ' 端點擁有經過适當編輯處理的密碼，這意味着進入了死胡同，然而，' /heapdump' 端點含有存儲在内存中的應用程序對象的快照，暴露了明文格式的憑據。在搜索關鍵字僅僅幾分鍾後，他就找到了 oauth2 憑據，他利用這些憑據訪問了一個之前發現的 config-server 實例；同樣由于另一個錯誤配置的 Spring Boot Actuator，他找到了另一組 ' /env ' 和 ' /heapdump ' 端點。
不過這一回，'/env' 端點沒有編輯憑據。Corben 現在有了 GitHub 代碼庫管理員的私鑰和密碼，這個管理員可以訪問 30 多個 GitHub 組織，并對數百個代碼庫擁有讀寫訪問權。
圖 3
如果不道德的黑客先發現了這個漏洞，這家汽車公司可能會洩露其所有的私有代碼庫或遭到勒索，正如我們所看到的，不是所有的公司都這麽幸運，包括三星、英偉達、微軟和優步。
剖析出了什麽岔子？
這個場景涉及多個問題：錯誤配置、暴露的明文密碼和範圍确定。
錯誤配置是攻擊者最好的朋友
雖然我們不能确定這家汽車公司的 DevOps 團隊是如何部署其基礎設施的，但很有可能他們會使用基礎設施即代碼（IaC），比如 Terraform、Crossplane 或 CloudFormation。IaC 有一些重大的優點，因爲配置可以快速地進行版本控制和審查，使整個環境具有極大的可擴展性。然而，最大的缺點之一是代碼中的錯誤配置可能意味着相同的問題推廣到整個環境中的每個實例，這可能就是相同的錯誤配置出現在多台服務器上的原因。
在流程的早期測試錯誤配置，是确保它們不會出現在生産環境中的最佳方法，GitGuardian 的客戶使用 gghield 用于 IaC 掃描已有很長一段時間了。現在，我們通過新的基礎設施代碼安全模塊将相同的這項掃描功能添加到 GitGuardian 平台，客戶可以在儀表闆上看到 100 多次自動掃描的結果，并協調修複過程。
無論你如何部署基礎設施（手動部署還是通過 IaC 部署），都要确保添加了審查過程來覆蓋常見的場景，我們還鼓勵 IaC 方面剛入手的讀者了解《WASP 雲原生應用程序十大安全漏洞》（https://owasp.org/www-project-cloud-native-application-security-top-10/?ref=blog.gitguardian.com），知道測試時應該留意什麽漏洞。
暴露密碼
到目前爲止，我們希望每個人都知道以明文形式存儲密碼是個壞主意，然而我們也知道，進入到公共 GitHub 代碼庫的暴露密碼數量每年都在增長。在本文，我們确實看到了爲确保機密（secrets）安全而花費心思的證據，因爲 Corben 遇到的初始 ' /env ' 端點确實擁有經過編輯的憑據，然而，他們忽略了 ' heapdump ' 端點中的日志文件。
檢查任何地方的機密至關重要，不僅僅是所編寫的代碼中的機密，還有代碼生成的任何文件（包括日志）中的機密，這就是 ggshield（GitGuardian CLI）可以掃描任意文件或路徑查找機密的原因之一。手動審查日志的代碼可能會發現明文憑據的存在，但是始終使用工具進行測試的團隊更容易及早發現問題，如果他們清理了那個端點上的日志，這将是内容全然不同的社交媒體帖子。
超級管理員憑據
Corben 發現的 GitHub 憑據不僅授予對單個私有代碼庫的訪問權，甚至還授予對單個私有組織的訪問權，他報告自己獲得了對 30 多個組織和數百個代碼庫的訪問權限，需要這種級别的跨組織協作可能有其合理的理由。然而，這感覺像是有人使用根用戶憑據來處理所有事情，安全界的共識是始終緻力于實現零信任架構，并運用最小特權原則。
Mackenzie Jackson 在其文章《管理和存儲包括 API 密鑰和其他憑據在内的機密的最佳實踐》中讨論了最小權限的這個原則，所有憑據都應該嚴格限定在其預期目的範圍内，隻授予完成特定任務所需的最小權限，創建一個隻能訪問非常特定的代碼庫的新用戶可能是一條更好的途徑，這意味着 Corben 将擁有一些訪問權限，但無法訪問密鑰。
漏洞懸賞和安全研究的重要性
實際上，互聯網上的每個應用程序都在不斷地接受安全測試。問題就在于誰在測試，以及測試的目的是什麽，我們一直在與攻擊者玩貓捉老鼠的遊戲，總是試圖比對方領先一步。參與漏洞懸賞計劃、雇用滲透測試人員來發現和利用應用程序和環境中的漏洞，這些都是确保你在攻擊者之前發現問題的好方法。
外頭有很多道德黑客等着與你合作，幫助你确保安全，如果你正在尋找有關漏洞懸賞平台方面的更多信息，請查看 HackerOne、Bugcrowd 或 Open Bug Bounty，這是三個最受歡迎的平台。你也可以看看 Jason Haddix 最近的安全代碼庫播客（https://open.spotify.com/episode/2270puN1UHeeC7qkvaiaMo?ref=blog.gitguardian.com），他暢談了自己作爲漏洞賞金獵人和育碧（UbiSoft）CIO 的經曆，保證你的應用程序和客戶的安全是一個過程。
我們可以從這個例子及其他例子中汲取很多教訓。本文提醒我們在确定憑據的範圍時應遵循最小特權原則，不要添加明文形式的密碼，并進行測試，以确保我們的基礎設施即代碼沒有錯誤配置，無論你在通往更安全的道路上處于哪個階段，我們都鼓勵你不斷學習，努力保持安全。
