并非所有的軟件供應鏈攻擊都是一樣的。以下是攻擊者目前通過第三方破壞合法軟件的慣用方法。
軟件供應鏈事件最近登上了新聞頭條，引發(fā)了各界廣泛關(guān)注。盡管這些安全事件有著諸多相似之處，但事實上，并非所有的供應鏈攻擊都是相同的。
“供應鏈攻擊”這一總稱涵蓋了攻擊者干擾或劫持軟件制造過程（軟件開發(fā)生命周期），從而對成品或服務(wù)的諸多消費者造成不利影響的任何情況。當軟件構(gòu)建中使用的代碼庫或單個組件受到感染、軟件更新二進制文件被木馬化、代碼簽名證書被盜，甚至托管軟件即服務(wù)（SaaS）的服務(wù)器遭到破壞時，都可能會發(fā)生供應鏈攻擊。
對于任何軟件供應鏈攻擊，攻擊者都會在上游或中游介入，將其惡意活動及其后果向下游傳播給眾多用戶。因此，與孤立的安全漏洞相比，成功的供應鏈攻擊往往規(guī)模更大，影響更深遠。
下面為大家介紹現(xiàn)實世界中成功的軟件供應鏈攻擊活動慣用的6種關(guān)鍵技術(shù)：
供應鏈攻擊示例
1.上游服務(wù)器妥協(xié)——Codecov攻擊
對于大多數(shù)軟件供應鏈攻擊，攻擊者會破壞上游服務(wù)器或代碼存儲庫并注入惡意負載（例如，惡意代碼行或木馬更新）。然后將該有效載荷向下游分發(fā)給眾多用戶。然而，從技術(shù)角度來看，情況并非總是如此。
Codecov供應鏈攻擊就是這樣一個例子。盡管該事件與SolarWinds攻擊存在相似之處，但兩次攻擊之間卻存在明顯差異。SolarWinds供應鏈漏洞是技能卓越的威脅行為者的“杰作”，他們更改了合法的更新二進制文件SolarWinds.Orion.Core.BusinessLayer.dll，其是SolarWinds IT性能監(jiān)控產(chǎn)品Orion的一部分。
FireEye之前分析過，假冒DLL的RefreshInternal()方法中包含的惡意代碼如下所示。當Orion加載庫存管理器插件時，此方法會調(diào)用基于HTTP的后門：
帶有惡意RefreshInternal方法的后門DLL版本2019.4.5200.9083
然而，只有當修改后的二進制文件向下游傳播至包括美國政府機構(gòu)在內(nèi)的18,000多個SolarWinds Orion客戶時，SolarWinds上游攻擊才算發(fā)揮了全部作用。
而在Codecov攻擊案例中，沒有惡意代碼分發(fā)到下游，但卻切切實實地產(chǎn)生了攻擊后果。根據(jù)官方安全公告指出，黑客利用Codecov的Docker映像創(chuàng)建過程中出現(xiàn)的錯誤，非法獲得了其Bash Uploader腳本的訪問權(quán)限并且進行了修改，以收集從客戶的持續(xù)集成/持續(xù)交付(CI/CD)環(huán)境上傳的環(huán)境變量：
盡管Codecov Bash Uploader腳本在Codecov[.]io/bash的Codecov服務(wù)器本身上存在（并繼續(xù)存在），但數(shù)千個存儲庫已經(jīng)指向該鏈接，以將信息從其CI/CD環(huán)境上游發(fā)送到此BashUploader。因此，惡意代碼僅存在于（受損的）上游服務(wù)器上，而沒有發(fā)生任何下游代碼分發(fā)，因為所謂的下游存儲庫已經(jīng)指向托管Bash Uploader腳本的Codecov服務(wù)器。然而，這些下游存儲庫也受到了此次攻擊的影響，因為它們被配置為將數(shù)據(jù)上傳到Codecov的Bash Uploader：
事實上，據(jù)報道，Codecov攻擊者使用從受損Bash Uploader處收集的憑據(jù)破壞了數(shù)百個客戶網(wǎng)絡(luò)。最近開源程序工具和保險柜制造商HashiCorp也披露稱，Codecov供應鏈攻擊已經(jīng)致使其GPG簽名密鑰被泄漏。
2.中游妥協(xié)以傳播惡意更新
術(shù)語“中游”在這里主要指攻擊者破壞中間軟件升級功能或CI/CD工具而非原始上游源代碼庫的實例。今年4月，許多《財富》500強公司使用的Passwordstate企業(yè)密碼管理器的制造商Click Studios通知客戶稱，攻擊者破壞了Passwordstate的升級機制，并利用它在用戶的計算機上安裝了一個惡意文件。其文件名為“moserware.secretsplitter.dll”，其中一小部分如下所示：
在安全公告中，Click Studios表示，攻擊持續(xù)了大約28小時才被關(guān)閉。只有在此時間段內(nèi)執(zhí)行一鍵升級的客戶才會受到影響。而Passwordstate的手動升級不會受到損害。受影響的客戶密碼記錄可能已被收集。
不出所料地是，Passwordstate攻擊事件后就發(fā)生了針對Click Studios用戶的網(wǎng)絡(luò)釣魚攻擊，攻擊者在這些釣魚電子郵件中放置了指向更新的惡意軟件版本的非法鏈接。
除了具備技術(shù)要素（例如升級過程被篡改）之外，這種供應鏈攻擊還具備社會工程學因素。在一份大小超過300 MB的偽造更新zip文件中，安全研究人員發(fā)現(xiàn)，攻擊者已設(shè)法更改用戶手冊、幫助文件和PowerShell構(gòu)建腳本，以指向其惡意內(nèi)容分發(fā)網(wǎng)絡(luò)（CDN）服務(wù)器：
闡明惡意CDN服務(wù)器為官方的幫助手冊文檔之一
包含惡意CDN服務(wù)器鏈接的PowerShell安裝腳本
針對此次攻擊的社會工程學手段還說明了另一項弱點：人類（尤其是新手開發(fā)人員或軟件消費者）可能并不總是對內(nèi)容分發(fā)網(wǎng)絡(luò)（CDN）鏈接保持懷疑態(tài)度，無論這些鏈接是否真的可疑。這是因為通常情況下，CDN是被軟件應用程序和網(wǎng)站合法同于提供更新、腳本和其他內(nèi)容的。
Magecart等在線信用卡竊取攻擊就是此類供應鏈攻擊的另一個例子。在某些攻擊中，Amazon CloudFront CDN存儲桶已被攻破，以將惡意JavaScript代碼分發(fā)到更多依賴此類CDN的網(wǎng)站之中。
3.依賴項混淆（dependency confusion）攻擊
2021年，提及供應鏈攻擊就少不了要提“依賴項混淆”，特別是因為這種攻擊的簡單化和自動化特質(zhì)，使其日漸受到攻擊者的青睞。得益于在多個開源生態(tài)系統(tǒng)中發(fā)現(xiàn)的固有設(shè)計缺陷，依賴項混淆能夠在攻擊者端通過最小的努力甚至是自動化的方式發(fā)揮作用。
簡而言之，如果您的軟件構(gòu)建使用私有的、內(nèi)部創(chuàng)建的依賴項，而該依賴項在公共開源存儲庫中不存在，那么依賴項混淆（或命名空間混淆）就會起作用。攻擊者能夠在公共存儲庫上以相同的名稱注冊具有更高版本號的依賴項。然后，很大的可能是，攻擊者創(chuàng)建的具有更高版本號的（公共）依賴項——而非您的內(nèi)部依賴項——將被拉入您的軟件構(gòu)建中。
依賴項混淆攻擊示意圖
今年2月，通過利用PyPI、npm和RubyGems等常用生態(tài)系統(tǒng)中的這個簡單缺陷，道德黑客Alex Birsan成功地入侵了35家大型科技公司，并為此獲得了超過130,000美元的漏洞賞金獎勵。
在Birsan的研究成果披露幾天后，數(shù)以千計的依賴項混淆模仿包開始涌入PyPI、npm和其他生態(tài)系統(tǒng)。雖然大多數(shù)模仿包都是由其他有抱負的漏洞賞金獵人所創(chuàng)建，但是仍然不乏一些惡意行為者的身影。
解決依賴項混淆的方法有很多，包括在攻擊者之前搶先在公共存儲庫上注冊所有（你的）私有依賴項的名稱；以及使用自動化解決方案，例如軟件開發(fā)生命周期（SDLC）防火墻，以防止沖突的依賴項名稱進入您的供應鏈。
此外，開源存儲庫的所有者可以采用更嚴格的驗證過程并實施命名空間/范圍界定。例如，如果想要在“CSO”命名空間、范圍下注冊依賴項，那么開源存儲庫可以先驗證注冊的開發(fā)人員是否有權(quán)以“CSO”的名義這樣做。
Java組件存儲庫Maven Central采用簡單的基于域的驗證方式來驗證命名空間所有權(quán)——這種做法可以很容易地被其他生態(tài)系統(tǒng)建模。
4.被盜的SSL和代碼簽名證書
隨著HTTPS網(wǎng)站的增加，SSL/TLS證書已經(jīng)無處不在，它可以保護您的在線通信。因此，SSL證書私鑰的泄露可能會威脅到端到端加密連接為最終用戶提供的安全通信和保證。
2021年1月，Mimecast披露其客戶用于建立與Microsoft 365 Exchange服務(wù)連接的證書遭到破壞，可能影響約10%的Mimecast用戶的通信。雖然Mimecast沒有明確確認其是否為SSL證書，但正如一些研究人員所懷疑的那樣，在很大程度上情況似乎確實如此。
雖然受損的SSL證書存在影響，但被盜的代碼簽名證書（即受損的私鑰）會對軟件安全產(chǎn)生更廣泛的影響。獲得私有代碼簽名密鑰的攻擊者可能會將他們的惡意軟件簽名為由信譽良好的公司提供的真實軟件程序或更新。
盡管“震網(wǎng)”（Stuxnet）事件時至今日仍然是復雜攻擊的一個重要案例——在此次攻擊中，攻擊者使用了從兩家著名公司竊取的私鑰將其惡意代碼簽名為“受信任”——但此類攻擊其實早在Stuxnet事件前就已經(jīng)盛行，甚至在Stuxnet事件發(fā)生后數(shù)年的今天仍在盛行。這也解釋了前面提到的Codecov供應鏈攻擊中HashiCorp的GPG私鑰泄露事件之所以備受關(guān)注的原因。雖然目前還沒有跡象表明HashiCorp的泄露密鑰被攻擊者濫用來簽署惡意軟件，但在泄露的密鑰被撤銷之前，這種事件確實有可能發(fā)生。
5.針對開發(fā)者的CI/CD基礎(chǔ)設(shè)施
如今，軟件供應鏈攻擊盛行，這些攻擊不僅依賴于向用戶的GitHub項目引入惡意拉取請求，還會濫用GitHub的CI/CD自動化基礎(chǔ)設(shè)施GitHub Actions來挖掘加密貨幣。GitHub Actions為開發(fā)人員提供了一種為GitHub上托管的存儲庫安排自動化CI/CD任務(wù)的方法。
攻擊方式主要包括攻擊者克隆使用GitHub Actions的合法GitHub存儲庫，稍微更改存儲庫中的GitHub Action腳本，并向項目所有者提交拉取請求以將此更改合并回原始存儲庫。
攻擊者(edgarfox1982)為合法項目所有者提交拉取請求以合并更改的代碼
如果項目所有者隨意批準更改的拉取請求，那么供應鏈攻擊就會成功，而且后果遠不止于此。惡意拉取請求包含對ci.yml的修改，一旦攻擊者提交拉取請求，GitHub Actions就會自動運行這些修改。修改后的代碼實質(zhì)上是濫用GitHub的服務(wù)器來挖掘加密貨幣。
這種攻擊可謂是一舉兩得：它誘使開發(fā)人員接受惡意拉取請求，如果失敗，它就會濫用現(xiàn)有的自動化CI/CD基礎(chǔ)設(shè)施進行惡意活動。
2021年1月，Sakura Samurai安全人員在研究聯(lián)合國漏洞披露計劃范圍內(nèi)的資產(chǎn)安全漏洞時，發(fā)現(xiàn)了一個ilo.org子域，該子域暴露了大量Git賬戶信息，使得他們能夠成功入侵聯(lián)合國（UN）域并訪問超過100,000份聯(lián)合國環(huán)境規(guī)劃署（UNEP）工作人員記錄。這些記錄包括姓名、員工ID號、員工組、旅行理由、旅行的開始和結(jié)束日期、批準狀態(tài)、停留時間和目的地。
更糟糕的是，獲得Git憑證訪問權(quán)限的威脅行為者不僅可以克隆私有Git存儲庫，還可能在上游引入惡意代碼以觸發(fā)供應鏈攻擊，從而產(chǎn)生更嚴重的后果。
想要阻止此類攻擊，開發(fā)人員需要踐行安全編碼或在開發(fā)環(huán)境中使用DevSecOps自動化工具。同時，保護CI/CD管道（例如Jenkins服務(wù)器）、云原生容器以及附加開發(fā)人員工具和基礎(chǔ)設(shè)施現(xiàn)在也變得同樣重要。
6.使用社會工程學來引入惡意代碼
任何安全專業(yè)人員都知道，安全性取決于其最薄弱的環(huán)節(jié)。由于人為因素仍然是最薄弱的環(huán)節(jié)，因此泄露往往來自最意想不到的地方。最近，明尼蘇達大學的研究人員被踢出了Linux貢獻群體，Linux內(nèi)核社區(qū)也撤銷了他們之前提交的所有Linux內(nèi)核代碼，原因在于他們故意提出有缺陷的“補丁”，而這些“補丁”又會在Linux內(nèi)核源代碼中引入漏洞。
盡管該事件被積極制止，但還是證實了一個結(jié)論：開發(fā)人員分布廣泛，并且沒有足夠的寬帶來審核他們提交的每一個代碼，這些代碼可能是存在缺陷的或完全是惡意的。
更重要的是，社會工程學可能來自最不受懷疑的來源——在上述案例中，具有“.edu”后綴的電子郵件地址就看似來自可信的大學研究人員。
另外一個突出案例是，任何為GitHub項目做出貢獻的合作者都可以在發(fā)布后更改版本。在此需要強調(diào)，GitHub項目所有者的期望是大多數(shù)貢獻者都能真誠地提交代碼到他們的項目之中。但正可謂“一個老鼠壞一鍋湯”，只要一個合作者不規(guī)矩就會損害許多人的供應鏈安全。
在過去一年中，攻擊者創(chuàng)建了域名搶注和品牌劫持包，一再針對開源開發(fā)人員在其上游構(gòu)建中引入惡意代碼，然后傳播給眾多消費者。
所有這些真實世界的例子都展示了威脅行為者在成功的供應鏈攻擊中所采用的不同漏洞、攻擊媒介和技術(shù)。隨著這些攻擊不斷發(fā)展演進并帶來挑戰(zhàn)，在考慮軟件安全性時，必須納入更多創(chuàng)新的解決方案和策略。
