GSS資安電子報0189期【針對軟體供應鏈的攻擊該如何進行防護? 深入淺出探討五種供應鏈手法】

相信大家都對2014年發生的劣質油案印象深刻吧！這起案例是發生在製造商上游，直接或間接造成下游廠商、零售業者以及消費者的食品安全供應鏈問題，同樣的事情其實近期也發生在軟體供應鏈上。2020年底，美國國土安全局發出緊急命令，要求所有聯邦組織停止使用有問題的SolarWinds Orion系統，進而掀起一波軟體供應鏈滔天大浪。本文章將帶您快速了解這個事件的前因後果。接著，將與您討論五種我們歸納出來的供應鏈攻擊手法。

SolarWinds Orion是什麼？

SolarWinds Orion簡而言之就是設備集中管理系統，從防火牆、路由器到伺服器，都可以在單一介面進行統一管理與監控。集中管理各種不同設備，將各種不同介面與通訊協定在一個統一的介面進行設定，簡直是IT管理的福音，因此在美國政府以及大型企業中廣泛的使用。

SolarWinds Orion發生了甚麼事？

最初，2020年底資安大廠FireEye公布被駭消息，紅隊演練工具遭受外洩。同時FireEye認為這個攻擊手法非比尋常，可能涉及國安問題，因此與聯邦調查局合作，幾天之內美國國土安全局便發出緊急命令，要求所有聯邦組織關閉被植入惡意程式的SolarWinds Orion系統。Imperva資安專家指出，這個攻擊手法精細且經過深思熟慮，針對現有軟體供應鏈的信任漏洞展開攻擊，攻擊手法同時包含技術面與非技術的人為操作，攻擊目標明確，令人難以堤防。

原來早在2019年9月，駭客首先入侵SolarWinds開發伺服器，並修改程式碼與上傳惡意程式，最後刪除掉作業紀錄。過一段時間後SolarWinds沒有發現這個入侵行為，駭客便清除掉惡意程式，構思如何進一步攻擊高價值單位，並完成火力更大的攻擊手段。駭客在2020年2月將這次事件主因的惡意程式碼以相同手法植入SolarWinds。這個惡意程式碼成功的通過安全檢驗後，被開發流程打包，便以Patch的方式部屬到客戶環境中。最後駭客在2020年6月將程式碼移除，以避免被原始碼掃描發現。一直到2020年12月由FireEye揭露這個攻擊，並將這個惡意程式命名為SUNBURST，這才讓這個攻擊手法暴露在日光之下。

SUNBURST攻擊機制

已受汙染的SolarWinds系統剛建置或更新完成時，SUNBURST將休眠12~14天，之後在一個隨機的時間啟動。啟動之後會先按兵不動，觀察所在的伺服器是否有無法應付的安全掃描，若環境允許便開始收集情資，包括自己所在的伺服器，橫向的伺服器資訊，所在的公司資訊等等，最後將收集到的資訊上傳到外部伺服器等待駭客指示後續動作，若該伺服器是駭客的攻擊目標，便可能下載更多惡意程式進入。運行過程中所有軌跡都會加密，而且運行途中任何一步驟發生問題，SUNBURST會自我刪除，降低被發現的可能。

SUNBURST是針對SolarWinds系統設計製作的惡意程式，與SolarWinds的系統高度相容，惡意攻擊的執行緒與運作模式與SolarWinds本身運作模式高度吻合，且能使用SolarWinds的通訊協定並讀取SolarWinds所得到的所有資訊，並混和多種混淆技術以躲避安全防護程式，有鑑於SolarWinds系統本身在公司內的服務定位，一些惡意掃描或者惡意設定的行為，也非常有可能會被辨識為正常的例行維護，外部惡意使用者有機會在被入侵的公司內所有系統暢行無阻，取得任何資料。

從以上SUNBURST運行方式，我們可以歸納出SUNBURST會執行的幾項行為：

• 試讀取自身伺服器資訊
• 試執行系統指令
• 試加密隱藏運行軌跡
• 試將檔案上傳至外部伺服器
• 接收外部伺服器傳來的後續指令
• 安裝後續的惡意程式

也就是，這個惡意程式會在受汙染的系統內進行四大步驟，包含：讀取檔案與路徑、執行指令、網路連線及加密。而這也是大多數後門程式主要的行為，因此若能阻擋應用伺服器（Application server）運行預期外的行為，便能有效阻擋後門程式的運行。而目前監控應用伺服器運行的最有效的安控手段，可以使用RASP（Runtime Application Self-Protection）來達到。

一、供應商危害

二、利用第三方應用程式漏洞

針對常用第三方應用程式中的「零時差漏洞」或「未修補的安全漏洞」的攻擊是供應鏈風險轉移我們用戶的另一個例子。

打造軟體系統是個具有挑戰性的過程。通常在這過程中會面臨各種挑戰，像是：需求不完整、錯誤假設和上市時間壓力，這些都會導致交付軟體是不完美的。一般來說，開發人員在消除導致災難性或明顯的失敗造成軟體錯誤方面做得很好。不幸的是，安全漏洞通常不會導致災難性的系統故障。他們只是讓惡意攻擊者有機會操控軟體做一些軟體設計目的之外的事情，比如竊取用戶憑證或竊取資料庫的全部內容。

最近在Microsoft Exchange Server 發生的攻擊事件就是此類軟體供應鏈攻擊的最新案例。在這個攻擊手法中，惡意攻擊者利用Exchange Server的漏洞閱讀任意電子郵件並安裝Web shell。Web Shell攻擊手法通常是攻擊者會在網站既有網頁內上傳一個附加功能。這個附加或修改的頁面允許攻擊者在網路服務器上執行任意系統指令、讀取檔案系統中的文件、安裝惡意軟體等。這個WebShell提供類似後門的功能，而且無需建立額外的網絡連結到網路伺服器。

使問題更加複雜的是，攻擊者狙擊漏洞的能力和我們合理謹慎的更新Patch流程之間的時間差距。不難預測的是幾乎沒有公司能在供應商在釋出patch後立即部署它。即使是最好的WAF也需要時間來調適，無論是新的簽章更新（必須經過開發、測試和部署階段）或是調整機器學習模型，甚至人工確認檢測到異常並手工進行調整都是如此。使用WAF來縮小時間差是一種常見的策略。此外，就算使用「virtual patch」來協助防護，也必須在部署之前在每個公司的環境中進行測試，以確保它們不會引起不必要的副作用。

三、利用開源函式庫漏洞

這一個攻擊法與第三方應用程式漏洞相似，針對常用開源函式庫或套件中的零時差漏洞，是攻擊者手中另一種常用的策略。

時下幾乎所有軟體程序都包含開源程式（Open Source）。現在常見的應用程式中的開源軟體數以百計，而且相依在一個多層次的軟體相依鏈中。回想一下，軟體程序不僅限於 Microsoft Exchange Server 等第三方發行軟體。SaaS產品、專用設備（如路由器、物聯網工具、醫療設備、關鍵基礎設施控制系統等）和客製開發的內部系統也包含大量開源軟體。

不幸的是，不論是開源軟體或是任何其他軟體都面臨著相同的挑戰（即可能存在的安全漏洞）。更慘的是，一旦這漏洞包含在應用程式中，這個軟體很快就會過期，意即他缺乏最新的弱點更新。最重要的是，每個人都可以免費使用開源程式碼，因此不法分子可以研究和測試它，而不必擔心他們下一波攻擊計畫遭到暴露。例如Apache Struts 2 框架（在數千個企業網站中使用）是用於安全研究的熱門標的（不論是好的或是不好的意義上）。單就在過去5年中，它被公布了13次關鍵嚴重性零時差漏洞。

有效的開源零時差漏洞利用也通常會為廣泛的研究和攻擊趨勢提供靈感。例如，在安全研究社群開始廣泛討論該技術後，從 2016年開始，在數十個開源組件中發現了500多個「反序列化漏洞」。「反序列化漏洞」可以讓攻擊者有機會將任意程式碼注入應用程式用以在受害者服務器上執行的一種技術。

最後，攻擊者非常有可能在巨大經濟誘因下，嘗試從廣泛部署的開源套裝中去發掘零時差漏洞。這個經濟誘因可能從幾百美元到數萬美元不等，甚至更多。因為Open Source是廣泛分佈的目標、而且源碼又容易取得，加上了金錢。使得尋找開源軟體中的零時差漏洞對攻擊者來說極具吸引力。

四、軟體相依混淆攻擊

2021 年初，安全研究員 Alex Birsan公佈了名為軟體相依混淆（Dependency Confusion）的供應鏈攻擊方式。這是一種巧妙且極其簡單的技術，它利用了現代軟體程式的快速開發流程最後進行軟體組裝的信任漏洞，再次展示如何輕鬆利用安全信任的假設（assumption）達成攻擊目的。

軟體程式是使用一系列專業的軟體工具創建的，而程式碼本身是用專業的文字編輯器編輯的，這使編寫程式碼的過程更有效率。軟體工程師編寫程式碼後，將其儲存在版本控制的儲存庫中（也被稱為Repository）。重複使用程式碼是軟體開發中一個核心概念，因此通用或實用程式碼經常被綁定到函式庫（library）或package中，使得許多應用程式將可共用相同的程式碼。

如果要創建應用程式，則需要使用「建構工具」（build tools），從各自的Repository中取得適當的程式碼和函式庫。然後編譯、組裝和打包程式碼以供交付。接著自動化測試工具將應用程式推送到指定的部署環境－ testing、Staging、production等。對於現代常見的快速開發應用程式，這種情況每天發生數十次。

開源函式庫是一組通用的實用程式碼，一般是從公開的Repository免費提供。由於絕大多數應用程式都包含Open Source，因此公司的建構工具必須從「私有Repository」（僅限開發應用程式的公司內部讀取）和公開Repository中取得程式碼。

軟體相依混淆攻擊技巧是利用建構工具執行軟體建構時，”從何處（Repository）找函式庫程式碼”，以及”多處重複情況下選擇最新版本”的兩個作業慣例。如果攻擊者在公開Repository中註冊一個與私有Repository中同名的package名稱，則建構工具有可能去拉取（pull）攻擊者的package而不是預期的內部package。例如攻擊者的package註記了更新更高的版本號碼，建構工具可能會拉取攻擊者的package，而不是具有較低版本號碼的內部package。有鑑於現代軟體應用程式的複雜性及其對開源的嚴重依賴，這種攻擊方式可能會非常有效。

這個攻擊手法簡單有效，且輕易地造成毀滅性後果。整個開發團隊的所有開發人員中僅需要一次錯誤的拉取—可能發生在開發人員的筆記型電腦、AWS…等等，接著推送進入內部伺服器便能成功感染公司內部。Alex Birsan證明他的攻擊概念驗證能夠從他所針對的幾乎所有公司的內部服務器（包括Apple、Microsoft、Netflix、PayPal、Shopify、Tesla 和 Uber）曾向他的模擬攻擊者服務器發送請求。在此攻擊技術發布之後的48 小時內，便發現有人嘗試使用相同的攻擊手法在數百個開源套件之上。

五、惡意接管

供應鏈攻擊的最後一個常見手法是技術門檻最低的「惡意接管（Hostile Take-Over）」。這是壞人惡意利用我們對供應鏈信賴的另一個案例。在許多方面來說，這手法類似於之前討論的軟體相依混淆攻擊，由於在幾乎所有應用程式都使用了開源軟體，因此可能會非常有效。

此類攻擊一個可查到的實際案例發生在2018年底，在Node.js開發人員使用的「event-stream」套件上。這個套件最初發佈於近10年前，每週下載200萬次，並由其原始開發者忠實維護多年。

開源軟體通常由原始開發人員維護，也可能由一小群貢獻者在空閒時間無私地維護。能為社群做出貢獻並獲得大家的認可是一種榮譽，但這也是一份吃力不討好的工作。

在處理功能需求、錯誤修復和版本更新多年後，社群的另一位成員找到了原始開發者，要求接管「event-stream」。原作者放心地將項目的控制權轉移給了新成員，並繼續做其他事情。然而在幾週內，惡意程式碼被附加到該套件中，經由自動建構工具下載，而部署在數量未知的軟體應用程式中。

這個惡意程式碼專門用於Copay比特幣錢包竊取憑證。如同其他後門或惡意軟體一樣，攻擊者的程式碼進行加密來混淆其實際的功能，並將竊取的憑證發送到遠端服務器。要不是一些小錯誤提醒了Node.js repository管理員注意到這個套件中可能存在一些錯誤，這個惡意程式碼很可能會在持續保留兩個月以上。

現代軟體開發過程完全基於整個軟體供應鏈是可信賴的假設，並使用開源軟體的情況，基本發展原則是任何人都可以創建項目或做出貢獻，而且目前沒有標準一致的審查程序。雖然有一些方法可以使用建構工具功能來降低這種風險，但這些功能不是太深奧，不然就不實用，而無法符合實際應用場景。

顯然，廣泛採用開源程式碼或軟體，建構自動化工具的開發環境，加上非法經濟刺激，使得發展軟體供應鏈攻擊手法具有相當程度的吸引力和有效性。但為什麼現有的控制措施不能減輕這種風險呢？

一般而言，我們在軟體開發生命週期和供應商管理中，現有的流程管理過於依賴耗時、容易出錯的手動流程和開發者提供的自我審查證明。而在安全管控技術上往往「僅注意特定面向」。例如WAF，檢查的重點是進入網站的流量。而端點防護系統（Endpoint Protection）亦可能未安裝在網路應用程式的部署環境中，或者可能預設為「允許」來自受信任應用程式的特權活動。而程式碼掃描技術可以找出開發過程無意製造的常見錯誤，但難以識別故意完成的惡意程式碼。

我們有可能改進供應商和Patch更新管理流程，也可能改善端點防護系統和程式碼掃描工具使用方式。甚至未來有可能在開源社區中的軟體項目、創建者和所有權限監管達成共識並建立一致的審查方式。但在此之前，我們該怎麼辦？

Imperva RASP

總而言之，我們歸納出目前供應鏈攻擊的五種手法。如果使用軟體應用程式的公司必須承擔與之相關的所有風險，那麼必須有一種簡單的方法來減輕這些風險，而無需特殊的專業知識或軟體供應商的參與。若有可以「一勞永逸」且適用於任何部署環境、任何網路應用程式的安全管控技術將大大降低與軟體供應鏈相關的風險。

Imperva RASP提供了一種使人驚艷的方法。RASP是一個輕量級外掛程式，可以附加到幾乎任何類型的網路應用程式，無論是第三方，開源還是訂製的。RASP能與網路應用程式緊密結合、不需要外部連接，無論將應用程式部署在何處，都能持續受到RASP的保護。RASP採積極安全保護設定，主動制止惡意軟體活動（如阻擋未經授權的網路連線、存取檔案系統與主機系統指令）來減輕來自供應鏈攻擊風險。

Imperva RASP解決方案所提供的防護能力，是對付後門程式的秘密武器，後門程式運行都在RASP的防護範圍之內。甚至RASP不需修改原始碼便能在應用伺服器中提供防護，持續「監控」應用系統運行中程式碼運作。例如惡意程式嘗試讀取非經許可的檔案路徑，如/etc或C:\Windows，便阻擋該程式運行。該指令非經許可的指令，如pwd、ls、dir、rm、del等等，便會進行阻擋。應用程式的所有非預期行為，都可以使用RASP進行防禦，而這些攻擊行為也會呈現在報表上，讓監控人員有更多機會發現系統異常運行。

因此，將RASP應用在伺服器上，尤其是運作方式無法掌握的系統，能有效避免損害擴大，成為控制災情的最後防線。關於第三方軟體供應鏈信任問題，使用RASP會是最好的解決方案。

SolarWinds事件重擊了整個軟體供應鏈，軟體界人人自危，微軟也公開承認伺服器曾因這個事件導致原始碼外洩，幸好駭客並未能進一步修改微軟的原始碼。可以直接想到的是現有的軟體開發提交流程並非牢不可破，此外，使用的外部套件是否安全，這些該如何改進以及防護呢？最重要的是，系統規劃應採取零信任，假設所有軟體都可能有某種程度未知的破綻。我們該如何對其進行防護，將會是2021年軟體安全的重點。也許這就是為什麼美國國家標準技術研究院（NIST）在資訊安全標準的SP 800-53的SI-7（17）節「資訊系統和公司的安全和隱私控制」中提出建議使用RASP！邀請您現在更進一步來了解RASP！

相關文章：

2020年10大Open Source弱點 Part I