最近軟件供應鏈事件屢屢成為頭條新聞。盡管這些安全事件有相似之處，但并非所有的供應鏈攻擊都是一樣的。

軟件供應鏈攻擊的定義

“軟件供應鏈攻擊”這個統稱涵蓋了攻擊者干擾或劫持軟件制造過程（軟件開發生命周期）的任何情況，從而使最終的產品或服務的多個消費者受到不利影響。當軟件構建中使用的代碼庫或單個組件被污染、軟件更新二進制文件被植入木馬、代碼簽名證書被竊取，甚至托管軟件即服務（SaaS）的服務器被闖入時，都可能會發生供應鏈攻擊。

對于任何軟件供應鏈攻擊，攻擊者潛伏于供應鏈上游或中游，導致其惡意活動及后續影響波及下游的許多用戶。因此，與孤立的安全攻擊相比，成功的供應鏈攻擊規模大得大，影響也深遠得多。

軟件供應鏈的風險有多大？

任何代碼存儲庫或庫都可能含有惡意代碼，盡管我們努力監視并刪除可疑的軟件包。雖然像GitHub這樣的代碼存儲庫正在采取積極的措施，防止惡意軟件進入其網站，但攻擊者正在想方設法，將其代碼成功地分發給毫無戒備的開發人員。

這個問題越來越嚴重。Phylum公司的《2023年第三季度軟件供應鏈安全演變報告》顯示，大多數類別的可疑軟件包都有所增加。在掃描的300萬個軟件包中，1萬多個文件引用了已知的惡意URL。近86000個軟件包含有預編譯的二進制文件，這使得它們很難掃描出惡意軟件。另有5500個軟件包企圖混淆其代碼，還有5000個軟件包是作者用一次性電子郵件帳戶注冊的。

更重要的是，報告顯示了攻擊手法上的轉變，更多的惡意軟件編寫者瞄準特定的公司，而不是采取更廣泛的方法。近1000個惡意軟件包針對特定組織或企業，比2023年第二季度猛增47.4%。這些針對性攻擊的目標包括收集憑據、竊取源代碼或知識產權。

開發人員似乎并沒有通過安全實踐提高軟件供應鏈的安全性。Phylum特別指出，開發人員每周從JavaScript軟件包注冊中心npm下載大約240億個軟件包，但幾乎沒有人驗證所下載代碼的完整性。報告稱，攻擊者知道這一點，這可能會鼓勵他們在未來發起更廣泛的活動，比如大規模勒索軟件攻擊或僵尸網絡。

軟件供應鏈攻擊的例子

下面我們分析最近實際的成功軟件供應鏈攻擊中使用的六種不同技術。

1. 入侵上游服務器：Codecov攻擊

就大多數軟件供應鏈攻擊而言，攻擊者入侵上游服務器或代碼倉庫，并注入惡意載荷（比如一行惡意代碼或被植入木馬的更新版），然后載荷被分發到下游的許多用戶。然而從技術的角度來看，實際情況并非始終如此。

Codecov供應鏈攻擊就是這樣一個例子。雖然這起事件與SolarWinds事件相似，但兩種攻擊還是存在顯著的差異。SolarWinds供應鏈攻擊是復雜攻擊者的杰作，他們篡改了合法的更新二進制文件：SolarWinds.Orion.BusinessLayer.dll，這是SolarWinds IT性能監控產品Orion的一部分。

正如FireEye之前所分析，這個假冒DLL的RefreshInternal()方法中所含的惡意代碼如下所示。當Orion加載Inventory Manager插件時，這種方法調用基于HTTP的后門。

圖1. 被植入后門的DLL的版本2019.4.5200.9083，附有惡意的RefreshInter

然而，只有當被篡改的二進制文件一路進入到下游的18000多個SolarWinds Orion客戶（包括政府部門），SolarWinds上游攻擊才完全發威。

然而以Codecov為例，沒有惡意代碼向下游分發，但攻擊的余波卻向下游波及。按照官方的安全公告，Codecov攻擊者從有缺陷的Docker鏡像創建過程獲得了憑據，可以用來篡改Codecov Bash Uploader。攻擊者隨后篡改托管在其Codecov服務器上的Codecov Bash Uploader本身，以收集從客戶的持續集成/持續交付（CI/CD）環境上傳的環境變量：

圖2. 被篡改的一行Codecov Bash Uploader，它收集環境變量，并將它們發送給攻擊者的IP地址。

雖然Codecov Bash Uploader 腳本在Codecov服務器（位于Codecov[.]io/bash）上存在時間很短（并繼續存在），但數千個代碼存儲庫已經指向該鏈接，將信息從其 CI/CD 環境向上游發送到該Bash Uploader。因此，惡意代碼僅存在于（受攻擊的）上游服務器上，并沒有出現向下游分發任何代碼的情況，因為所謂的下游代碼存儲庫已經指向托管 Bash Uploader 腳本的 Codecov 服務器。然而，這些下游代碼存儲庫受到了這次攻擊的影響，因為它們被配置成將數據上傳到Codecov的Bash Uploader：

實際上，Codecov 攻擊者據稱使用從受攻擊的Bash Uploader收集的憑據闖入了數百個客戶網絡。不久后，HashiCorp披露Codecov事件導致其用于軟件包簽名和驗證的GPG私鑰被暴露。Twilio也披露受到了這起攻擊的一些影響，其他公司紛紛披露類似的情況。

2. 中游受攻擊，以傳播惡意更新

術語“中游”在這里主要指攻擊者破壞中間軟件升級功能或 CI/CD工具而非原始上游源代碼庫的情況。近日，Click Studios通知客戶遭到了供應鏈攻擊，這家公司開發的Passwordstate企業密碼管理器被許多《財富》500強公司所使用。攻擊者破壞了Passwordstate的“原地升級功能”，將惡意更新分發到Passwordstate用戶。

非法更新含有一個經過篡改的DLL文件，文件名為Moserware.SecretSplitter.dll，其一小部分如下所示：

Click Studios在安全公告中表示：“攻擊持續了大約28小時才被關閉。只有在此時間段內執行原地升級的客戶才受到影響。手動升級Passwordstate 并不受到攻擊。受影響的客戶密碼記錄可能已被收集。”

不出所料，此后就發生了針對Click Studios 用戶的網絡釣魚攻擊，攻擊者將指向更新后的惡意軟件版本的非法鏈接放入到這些電子郵件中。

除了涉及技術方面（比如升級過程被篡改）外，這起供應鏈攻擊還涉及社會工程方面。在一份大小超過300 MB的偽造的更新zip文件中，研究人員發現，攻擊者設法更改了用戶手冊、幫助文件和PowerShell構建腳本，以指向其惡意內容分發網絡（CDN）服務器：

圖5. 闡明惡意CDN服務器為官方CDN服務器的幫助手冊文檔之一。

圖6. 含有惡意CDN服務器鏈接的PowerShell安裝腳本。

這起攻擊的社會工程方面還表明了另一個弱點：人類（尤其是新手開發人員或軟件消費者）可能并不總是懷疑內容分發網絡（CDN）鏈接，無論這些鏈接是否真的可疑。這是由于CDN被軟件應用程序和網站合法用于提供更新、腳本及其他內容。

Magecart等在線信用卡竊取攻擊是這類供應鏈攻擊的另一個例子。在一些攻擊中，Amazon CloudFront CDN存儲桶受到攻擊，將惡意JavaScript代碼分發到數量更多的依賴這類CDN的網站。

3. 依賴項混淆攻擊

2021年，說到供應鏈攻擊免不了提及“依賴項混淆”，特別是由于這種攻擊的簡單化和自動化特性。由于多個開源生態系統存在固有的設計缺陷，依賴項混淆攻擊不需要攻擊者花多大的力氣，就能自動執行。

簡而言之，如果您的軟件構建使用私有的、內部創建的依賴項，該依賴項在公共開源代碼存儲庫中又不存在，依賴項混淆（或命名空間混淆）就會起作用。攻擊者能夠在公共代碼存儲庫上以相同的名稱注冊版本號更高的依賴項。然后，攻擊者創建的擁有更高版本號的公共依賴項（而不是您的內部依賴項）很有可能被拉入到軟件構建中。

圖7. 困擾多個生態系統的依賴項混淆弱點。

利用 PyPI、npm和RubyGems等常用生態系統中的這個簡單弱點，道德黑客Alex Birsan 成功地入侵了35家大型科技公司，為此獲得了超過130000美元的漏洞賞金。

在Birsan的研究成果披露幾天后，成千上萬個依賴項混淆山寨軟件包開始涌入PyPI、npm 及其他生態系統。雖然其中大多數山寨軟件包由其他志在必得的漏洞賞金獵人創建，但其中一些甚至惡意攻擊知名公司。

有多種方法可以解決依賴項混淆，包括在攻擊者之前搶先在公共代碼存儲庫上注冊（預留）你的所有私有依賴項的名稱，并使用自動化解決方案，比如軟件開發生命周期（SDLC）防火墻，以防止沖突的依賴項名稱進入到供應鏈中。

此外，開源代碼存儲庫的所有者可以采用更嚴格的驗證過程，并實施命名空間/范圍界定。比如說，如果想要在“CSO”命名空間或范圍下注冊依賴項，開源代碼存儲庫可以驗證上傳軟件包的開發人員是否有權以“CSO”之名來上傳。

Java 組件代碼存儲庫Maven Central采用了一種簡單的基于域的驗證方式來驗證命名空間所有權——這種做法很容易被其他生態系統所仿效。

同樣，發布到Go軟件包存儲庫的軟件包以指向其GitHub代碼存儲庫的URL命名，從而使得依賴項混淆攻擊即使并非完全不可行，至少難度大大加大。

4. 被盜的SSL和代碼簽名證書

隨著HTTPS網站不斷增加，SSL/TLS證書現在無處不在，保護你的在線通信。因此，SSL 證書私鑰泄露可能會危及端到端加密連接為最終用戶提供的安全通信和保證。

2021年1月，Mimecast披露其客戶用于建立與Microsoft 365 Exchange服務連接的證書遭到了破壞，可能影響約10%的Mimecast用戶。雖然Mimecast沒有明確證實這是不是SSL證書，但正如一些研究人員所懷疑的那樣，情況似乎基本屬實。

雖然受攻擊的SSL證書問題嚴重，但被盜的代碼簽名證書（即受攻擊的私鑰）會對軟件安全產生更廣泛的影響。獲得代碼簽名私鑰的攻擊者可能會簽名其惡意軟件，冒充由信譽良好的公司交付的真實的軟件程序或更新。

雖然Stuxnet仍然是一例典型的復雜攻擊——攻擊者使用了從兩家知名公司竊取的私鑰將其惡意代碼簽名為“受信任代碼”，但這類攻擊早在Stuxnet之前就已盛行，甚至在Stuxnet之后多年仍在盛行。這也解釋了前面提到的HashiCorp的GPG私鑰在Codecov供應鏈攻擊中泄露這個例子為什么事關重大。雖然目前還沒有跡象表明HashiCorp的泄露密鑰被攻擊者濫用以簽名惡意軟件，但除非泄露的密鑰被吊銷，否則這類事件確實有可能發生。

5. 攻擊開發人員的CI/CD基礎設施

Sonatype最近觀察到一起多管齊下的軟件供應鏈攻擊：不僅依賴向用戶的GitHub項目引入惡意合并請求，還濫用了GitHub的CI/CD自動化基礎設施GitHub Actions來挖掘加密貨幣。GitHub Actions為開發人員提供了一種為GitHub上托管的代碼存儲庫安排處理自動化CI/CD任務的方法。

攻擊包括攻擊者克隆了使用GitHub Actions的合法GitHub代碼存儲庫，對代碼存儲庫中的GitHub Actions 腳本稍加改動，并向項目所有者提交合并請求，以便將此變更合并回到原始代碼存儲庫中。

圖8. 攻擊者（edgarfox1982）為合法項目的所有者提交合并請求，以合并更改后的代碼。

如果項目所有者隨意批準更改的合并請求，供應鏈攻擊就會得逞，而這甚至不是這里的前提。惡意合并請求含有對ci.yml的修改，一旦攻擊者提交合并請求，GitHub Actions 就會自動運行這些修改。修改后的代碼實際上濫用GitHub的服務器來挖掘加密貨幣。

這種攻擊可謂是一舉兩得：它誘使開發人員接受惡意合并請求，如果開發人員未接受，它就濫用現有的自動化CI/CD基礎設施從事惡意活動。

同樣，研究人員之所以成功地闖入聯合國域名，并訪問了10多萬條聯合國環境規劃署員工記錄，主要是由于他們在這些域名上發現了暴露的Git文件夾和“git憑據”文件夾。獲得Git憑據訪問權限的攻擊者不僅可以克隆私有Git代碼存儲庫，還可能在上游引入惡意代碼以觸發供應鏈攻擊，從而釀成極嚴重的后果。

對于想要阻止供應鏈攻擊的那些人來說，注意力主要放在向開發人員推薦安全編碼實踐或在開發環境中使用DevSecOps 自動化工具。然而，為CI/CD 管道（比如Jenkins服務器）、云原生容器以及補充性的開發者工具和基礎設施確保安全現在也變得同樣重要。

6. 使用社會工程學投放惡意代碼

任何安全專業人員都知道，安全取決于最薄弱的環節。由于人為因素仍然是最薄弱的環節，因此威脅可能來自最意想不到的地方。最近，Linux基金會封殺了明尼蘇達大學的研究人員，起因是他們提議故意有缺陷的“補丁”，而這些“補丁”進而在Linux內核源代碼中引入了漏洞。

雖然該事件被發現，現已得到了處理，但它表明了幾個簡單的事實：開發人員分散在各處，沒有足夠的能力來審核提交的每個代碼或提議的代碼變更，它們可能存在缺陷或完全是惡意的。更重要的是，社會工程學可能來自最不受懷疑的來源——這里來自電子郵件地址使用“.edu”后綴的看似可靠的大學研究人員。

另一個近期的例子包括任何為GitHub項目貢獻代碼的合作者在即便發布后都可以更改版本。項目所有者以為，大多數貢獻者真誠地為其項目提交代碼。但只要一個合作者不守規矩，就會損害許多人的供應鏈安全。

在過去一年中，攻擊者創建了誤植域名和品牌劫持軟件包，一再針對開源開發人員，在其上游構建中引入惡意代碼，然后傳播給眾多使用者。

所有這些實際的例子都表明了威脅分子在成功的供應鏈攻擊中采用了不同的漏洞、攻擊途徑和技術。隨著這些攻擊不斷變化并帶來挑戰，在對待軟件安全時，需要更多的創新解決方案和策略。

本文翻譯自：https://www.csoonline.com/article/570743/6-most-common-types-of-software-supply-chain-attacks-explained.html如若轉載，請注明原文地址