并非所有的軟件供應鏈攻擊都是一樣的。以下是攻擊者目前通過第三方破壞合法軟件的慣用方法。

軟件供應鏈事件最近登上了新聞頭條，引發了各界廣泛關注。盡管這些安全事件有著諸多相似之處，但事實上，并非所有的供應鏈攻擊都是相同的。

“供應鏈攻擊”這一總稱涵蓋了攻擊者干擾或劫持軟件制造過程(軟件開發生命周期)，從而對成品或服務的諸多消費者造成不利影響的任何情況。當軟件構建中使用的代碼庫或單個組件受到感染、軟件更新二進制文件被木馬化、代碼簽名證書被盜，甚至托管軟件即服務(SaaS)的服務器遭到破壞時，都可能會發生供應鏈攻擊。

對于任何軟件供應鏈攻擊，攻擊者都會在上游或中游介入，將其惡意活動及其后果向下游傳播給眾多用戶。因此，與孤立的安全漏洞相比，成功的供應鏈攻擊往往規模更大，影響更深遠。

下面為大家介紹現實世界中成功的軟件供應鏈攻擊活動慣用的6種關鍵技術：

供應鏈攻擊示例

1. 上游服務器妥協——Codecov攻擊

對于大多數軟件供應鏈攻擊，攻擊者會破壞上游服務器或代碼存儲庫并注入惡意負載(例如，惡意代碼行或木馬更新)。然后將該有效載荷向下游分發給眾多用戶。然而，從技術角度來看，情況并非總是如此。

Codecov 供應鏈攻擊就是這樣一個例子。盡管該事件與SolarWinds攻擊存在相似之處，但兩次攻擊之間卻存在明顯差異。SolarWinds 供應鏈漏洞是技能卓越的威脅行為者的“杰作”，他們更改了合法的更新二進制文件 SolarWinds.Orion.Core.BusinessLayer.dll，其是SolarWinds IT性能監控產品Orion的一部分。

FireEye之前分析過，假冒DLL的RefreshInternal()方法中包含的惡意代碼如下所示。當 Orion 加載庫存管理器插件時，此方法會調用基于 HTTP 的后門：

帶有惡意RefreshInternal方法的后門DLL版本2019.4.5200.9083

然而，只有當修改后的二進制文件向下游傳播至包括美國政府機構在內的 18,000 多個 SolarWinds Orion 客戶時，SolarWinds 上游攻擊才算發揮了全部作用。

而在Codecov攻擊案例中，沒有惡意代碼分發到下游，但卻切切實實地產生了攻擊后果。根據官方安全公告指出，黑客利用Codecov的Docker映像創建過程中出現的錯誤，非法獲得了其Bash Uploader腳本的訪問權限并且進行了修改，以收集從客戶的持續集成/持續交付 (CI/CD) 環境上傳的環境變量：

盡管Codecov Bash Uploader 腳本在Codecov[.]io/bash 的 Codecov 服務器本身上存在(并繼續存在)，但數千個存儲庫已經指向該鏈接，以將信息從其 CI/CD 環境上游發送到此BashUploader。因此，惡意代碼僅存在于(受損的)上游服務器上，而沒有發生任何下游代碼分發，因為所謂的下游存儲庫已經指向托管 Bash Uploader 腳本的 Codecov 服務器。然而，這些下游存儲庫也受到了此次攻擊的影響，因為它們被配置為將數據上傳到 Codecov 的 Bash Uploader：

事實上，據報道，Codecov 攻擊者使用從受損Bash Uploader處收集的憑據破壞了數百個客戶網絡。最近開源程序工具和保險柜制造商HashiCorp也披露稱，Codecov供應鏈攻擊已經致使其GPG簽名密鑰被泄漏。

2. 中游妥協以傳播惡意更新

術語“中游”在這里主要指攻擊者破壞中間軟件升級功能或 CI/CD工具而非原始上游源代碼庫的實例。今年4月，許多《財富》500 強公司使用的Passwordstate企業密碼管理器的制造商Click Studios通知客戶稱，攻擊者破壞了Passwordstate的升級機制，并利用它在用戶的計算機上安裝了一個惡意文件。其文件名為“moserware.secretsplitter.dll”，其中一小部分如下所示：

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

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

除了具備技術要素(例如升級過程被篡改)之外，這種供應鏈攻擊還具備社會工程學因素。在一份大小超過300 MB的偽造更新zip文件中，安全研究人員發現，攻擊者已設法更改用戶手冊、幫助文件和PowerShell構建腳本，以指向其惡意內容分發網絡(CDN)服務器：

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

包含惡意CDN服務器鏈接的PowerShell安裝腳本

針對此次攻擊的社會工程學手段還說明了另一項弱點：人類(尤其是新手開發人員或軟件消費者)可能并不總是對內容分發網絡(CDN)鏈接保持懷疑態度，無論這些鏈接是否真的可疑。這是因為通常情況下，CDN是被軟件應用程序和網站合法同于提供更新、腳本和其他內容的。

Magecart等在線信用卡竊取攻擊就是此類供應鏈攻擊的另一個例子。在某些攻擊中，Amazon CloudFront CDN存儲桶已被攻破，以將惡意JavaScript代碼分發到更多依賴此類CDN的網站之中。

3. 依賴項混淆(dependency confusion)攻擊

2021年，提及供應鏈攻擊就少不了要提“依賴項混淆”，特別是因為這種攻擊的簡單化和自動化特質，使其日漸受到攻擊者的青睞。得益于在多個開源生態系統中發現的固有設計缺陷，依賴項混淆能夠在攻擊者端通過最小的努力甚至是自動化的方式發揮作用。

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

依賴項混淆攻擊示意圖

今年2月，通過利用 PyPI、npm 和 RubyGems 等常用生態系統中的這個簡單缺陷，道德黑客 Alex Birsan 成功地入侵了35家大型科技公司，并為此獲得了超過130,000美元的漏洞賞金獎勵。

在Birsan的研究成果披露幾天后，數以千計的依賴項混淆模仿包開始涌入 PyPI、npm 和其他生態系統。雖然大多數模仿包都是由其他有抱負的漏洞賞金獵人所創建，但是仍然不乏一些惡意行為者的身影。

解決依賴項混淆的方法有很多，包括在攻擊者之前搶先在公共存儲庫上注冊所有(你的)私有依賴項的名稱;以及使用自動化解決方案，例如軟件開發生命周期(SDLC)防火墻，以防止沖突的依賴項名稱進入您的供應鏈。

此外，開源存儲庫的所有者可以采用更嚴格的驗證過程并實施命名空間/范圍界定。例如，如果想要在“CSO”命名空間、范圍下注冊依賴項，那么開源存儲庫可以先驗證注冊的開發人員是否有權以“CSO”的名義這樣做。

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

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

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

2021年1月，Mimecast披露其客戶用于建立與Microsoft 365 Exchange服務連接的證書遭到破壞，可能影響約10%的Mimecast用戶的通信。雖然Mimecast沒有明確確認其是否為SSL證書，但正如一些研究人員所懷疑的那樣，在很大程度上情況似乎確實如此。

雖然受損的SSL證書存在影響，但被盜的代碼簽名證書(即受損的私鑰)會對軟件安全產生更廣泛的影響。獲得私有代碼簽名密鑰的攻擊者可能會將他們的惡意軟件簽名為由信譽良好的公司提供的真實軟件程序或更新。

盡管“震網”(Stuxnet)事件時至今日仍然是復雜攻擊的一個重要案例——在此次攻擊中，攻擊者使用了從兩家著名公司竊取的私鑰將其惡意代碼簽名為“受信任”——但此類攻擊其實早在Stuxnet事件前就已經盛行，甚至在Stuxnet事件發生后數年的今天仍在盛行。這也解釋了前面提到的Codecov供應鏈攻擊中HashiCorp的GPG私鑰泄露事件之所以備受關注的原因。雖然目前還沒有跡象表明HashiCorp的泄露密鑰被攻擊者濫用來簽署惡意軟件，但在泄露的密鑰被撤銷之前，這種事件確實有可能發生。

5. 針對開發者的CI/CD基礎設施

如今，軟件供應鏈攻擊盛行，這些攻擊不僅依賴于向用戶的GitHub項目引入惡意拉取請求，還會濫用GitHub的CI/CD自動化基礎設施GitHub Actions來挖掘加密貨幣。GitHub Actions為開發人員提供了一種為GitHub上托管的存儲庫安排自動化CI/CD任務的方法。

攻擊方式主要包括攻擊者克隆使用GitHub Actions的合法GitHub存儲庫，稍微更改存儲庫中的GitHub Action 腳本，并向項目所有者提交拉取請求以將此更改合并回原始存儲庫。

攻擊者 (edgarfox1982) 為合法項目所有者提交拉取請求以合并更改的代碼

如果項目所有者隨意批準更改的拉取請求，那么供應鏈攻擊就會成功，而且后果遠不止于此。惡意拉取請求包含對 ci.yml 的修改，一旦攻擊者提交拉取請求，GitHub Actions 就會自動運行這些修改。修改后的代碼實質上是濫用 GitHub 的服務器來挖掘加密貨幣。

這種攻擊可謂是一舉兩得：它誘使開發人員接受惡意拉取請求，如果失敗，它就會濫用現有的自動化CI/CD基礎設施進行惡意活動。

2021年1月，Sakura Samurai安全人員在研究聯合國漏洞披露計劃范圍內的資產安全漏洞時，發現了一個ilo.org子域，該子域暴露了大量Git賬戶信息，使得他們能夠成功入侵聯合國(UN)域并訪問超過 100,000 份 聯合國環境規劃署(UNEP)工作人員記錄。這些記錄包括姓名、員工ID號、員工組、旅行理由、旅行的開始和結束日期、批準狀態、停留時間和目的地。

更糟糕的是，獲得Git憑證訪問權限的威脅行為者不僅可以克隆私有Git存儲庫，還可能在上游引入惡意代碼以觸發供應鏈攻擊，從而產生更嚴重的后果。

想要阻止此類攻擊，開發人員需要踐行安全編碼或在開發環境中使用DevSecOps 自動化工具。同時，保護 CI/CD 管道(例如 Jenkins 服務器)、云原生容器以及附加開發人員工具和基礎設施現在也變得同樣重要。

6. 使用社會工程學來引入惡意代碼

任何安全專業人員都知道，安全性取決于其最薄弱的環節。由于人為因素仍然是最薄弱的環節，因此泄露往往來自最意想不到的地方。最近，明尼蘇達大學的研究人員被踢出了 Linux 貢獻群體，Linux 內核社區也撤銷了他們之前提交的所有Linux內核代碼，原因在于他們故意提出有缺陷的“補丁”，而這些“補丁”又會在 Linux 內核源代碼中引入漏洞。

盡管該事件被積極制止，但還是證實了一個結論：開發人員分布廣泛，并且沒有足夠的寬帶來審核他們提交的每一個代碼，這些代碼可能是存在缺陷的或完全是惡意的。

更重要的是，社會工程學可能來自最不受懷疑的來源——在上述案例中，具有“.edu”后綴的電子郵件地址就看似來自可信的大學研究人員。

另外一個突出案例是，任何為GitHub項目做出貢獻的合作者都可以在發布后更改版本。在此需要強調，GitHub項目所有者的期望是大多數貢獻者都能真誠地提交代碼到他們的項目之中。但正可謂“一個老鼠壞一鍋湯”，只要一個合作者不規矩就會損害許多人的供應鏈安全。

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

所有這些真實世界的例子都展示了威脅行為者在成功的供應鏈攻擊中所采用的不同漏洞、攻擊媒介和技術。隨著這些攻擊不斷發展演進并帶來挑戰，在考慮軟件安全性時，必須納入更多創新的解決方案和策略。

本文翻譯自：https://www.csoonline.com/article/3619065/6-most-common-types-of-software-supply-chain-attacks-explained.html?nsdr=true&page=2如若轉載，請注明原文地址。