軟體開發慎防供應鏈攻擊　補強弱點落實身分驗證

當前最駭人聽聞的SolarWinds Orion事件在資安界及一般大眾之間都掀起了不小的聲浪，全世界也因而更加關注所謂的供應鏈攻擊。事實上，這類攻擊本身並不算新穎，也早就橫行多年。但所有攻擊都會不斷演化出更高階的手法，而軟體開發供應鏈包含了許多階段，而每個階段都可能遭到襲擊，因此更加危險。

哪裡是脆弱的環節？

首先，先來為「供應鏈」下一個明確的定義，一般所謂的供應鏈是指「一套將產品提供給客戶的流程」。而本文所談是數位世界中產品，也就是軟體，所以先來探討軟體開發流程本身。

所有軟體開發人員，不論採用何種開發方法，都必須將一個複雜的專案拆成多個較簡單的工作項目，這樣才能將每個項目定義清楚，並且在問題追蹤系統內將工作項目指派給特定的開發者。接下來，開發者開始撰寫及測試程式碼，完成之後再將修改過的程式碼傳送至原始程式碼管理系統（Source Code Management System，SCM）。

接著，程式碼會經過一個「持續整合∕持續交付」（CI/CD）的流程，依序執行建構、測試以及最後的專案部署。

在定義的這個軟體開發供應鏈流程中，每一個步驟都有自己的資安風險和衝擊。例如，有些資料外洩事件是肇始於問題追蹤系統的不肖使用者。例如某個心生怨恨的內部人員掌握了重要的安全資訊，或是駭客經由漏洞攻擊手法滲透進來，這些都是可能發生的情況，整個供應鏈上包含了許多其他步驟，本文將焦點集中在「認證（Authentication）」步驟遭到惡意攻擊的問題探討上。 整個供應鏈的安全與否，取決於最脆弱的環節。如果不能落實一些資安最佳實務原則，例如重複使用相同的密碼，或略過一些認證機制，就會讓駭客有機會進入系統造成嚴重災情。

開發人員與SCM

軟體開發供應鏈上的一個重要環節是「開發人員」，也就是撰寫程式碼的人。人性的弱點與相關的資安風險，是這個環節的考量重點。這裡並非建議用機器來取代人員，而是要讓人員了解他們所面臨的風險。

最近看到一則歹徒攻擊漏洞研究人員的案例，就技術層面而言，這是一個暗藏在Visual Studio專案檔內的威脅，確切的位置是在某個建構前事件（Prebuild Event）當中，並經由PowerShell來啟動惡意檔案。像這樣的攻擊情境有兩點值得探討：第一是同儕之間的信賴，第二是援用外部原始程式碼與整合第三方專案的情況。開發人員對於自己所援用他人的程式碼以及所整合的專案應該要非常小心，在援用程式碼、軟體、外掛程式或容器之前應先仔細檢驗其來源。

此外，供應鏈上的另一個環節也跟開發人員有密切關係，那就是原始程式碼管理（SCM）系統。此處的防範重點在登入憑證。由於每次存取程式碼時如果都要重複輸入登入憑證，那SCM會變得非常難用，所以就必須儲存開發人員的登入憑證。既然儲存，就會有洩漏的風險，所以若採用未加密方式來儲存，那風險將更加嚴重。

在DevOps社群經常觀察到一個現象：開發人員經常使用「非加密」方式來儲存登入憑證（例如儲存在一個組態設定文字檔或環境變數內），這些資訊包括服務金鑰、使用者名稱、電子郵件地址等等。

這項資安問題或許看似言過其實，但「整個供應鏈的安全取決於其中最脆弱的環節」這句老生常談卻一點也不假。所以，一些能夠降低風險的預防措施（例如使用密碼保險箱來儲存密碼），至少是值得考慮的作法。

基本上，開發人員不應將含有任何登入憑證的程式碼寫入SCM當中。舉例來說，在使用基礎架構程式碼（IaC）時，就應預先想好整套登入憑證儲存機制。

CI/CD管道

接下來的另一個環節是CI/CD管道（CI/CD Pipelines），該領域的軟體廠商競爭非常激烈，一些熟悉的名稱如Jenkins、GitLab、TeamCity、Azure DevOps等等。

整體來說，CI/CD Pipelines大致可分為以下幾個部分：

系統存取（System Access）

就資安的角度，這類系統光暴露在網際網路上就足以帶來資安風險，因為該系統很可能存在著歹徒正積極尋找的漏洞，所以應該僅開放給特定對象使用，而非人人都能存取，並且應該架設在企業網路內部，讓某些特定角色的使用者才具備存取權限。

系統組態設定（System Configuration）

另一個可能的資安風險與相關的問題是組態設定錯誤。某些組態設定在特定環境下有其意義，例如某個企業需要讓多名使用者存取系統，但他們每一個人所扮演的角色都不盡相同。

這樣的情況下，就可以採用角色導向的組態設定，只是這類組態設定會存在著一些陷阱，如後端系統的預設組態設定，即使是在認證啟用的狀況下，還是會帶來相當大的資安風險。軟體開發團隊經常用到的開放原始碼自動化伺服器Jenkins，就被發現有這樣的風險。 隨著軟體日益複雜、組態設定選項越來越多，強烈建議企業應測試一下自己的環境是否存在著一些常見的軟體組態設定錯誤。

原始程式碼擷取方式

這裡可分成兩種狀況，一是SCM直接與CI/CD整合，Azure DevOps伺服器就是一個例子。二為SCM架設在另一個環境，這樣一來，系統內就要儲存金鑰或登入憑證。

系統儲存登入憑證的方式至關重要，因為若不小心外洩，就很可能導致原始程式碼遭到惡意篡改。值得一提的是，我們曾經在CI/CD系統內部看過一些處理不當的案例，也曾發現過一些第三方延伸功能如Jenkins外掛程式儲存了未加密的登入憑證。

建構環境組態設定

此處要防範的資安問題，無疑與登入憑證的傳遞方式有關，其中一項風險就是以未加密方式傳遞登入憑證，或是儲存在建構過程的暫存檔案當中。基本上，組態設定內容有時會含有一些機敏資訊，而這些資訊經常在應用程式建構完成之後被遺留在系統上。

建構

在軟體開發供應鏈中，所謂的「建構」是指將原始程式碼組譯成所需的二進位型態，針對此階段的攻擊案例包括之前的SolarWinds案例與CCleaner案例。駭客之所以會攻擊這個階段是有原因的。首先，由於這是軟體開發流程的最後一個階段，因此接下來就沒有太多的驗證程序。再者，此階段產生的執行檔現在大多會經過數位簽署。而簽署之後，任何的程式碼更動都會破壞其數位簽章，使得二進位檔案的雜湊碼不符。而且由於雜湊碼會經過私密金鑰加密，因此沒有這把金鑰無法重新產生合法的雜湊碼。這就是為何最後這道建構步驟會成為駭客攻擊的目標，不過也並非所有軟體在發布時都會包含數位簽章。

談到數位簽章，就不得不特別強調妥善保管憑證私密金鑰的重要。這把金鑰一旦外流，駭客就能用它來簽署任何惡意程式，此時金鑰就必須被撤銷。

部署（產品供應）

部署作業其實也可以包含在CI/CD Pipeline當中。首先，部署動作可以在CI/CD軟體中指定，然後在應用程式順利建構或測試完成之後觸發部署動作。

所以，這個流程有可能會儲存著一些架構資訊和登入憑證以及其他機敏資訊，突顯出適當管理的重要性。

對駭客來說，最簡單的攻擊方式就是將軟體整個換掉。當然，如果駭客技術高超且組譯後的二進位程式碼的狀態允許時，面對無數位簽章的應用程式，駭客也可以用惡意程式碼注入攻擊。然而，如果二進位程式碼已經過簽署，那就很容易被人發現，所以這樣的攻擊方式缺乏效率。簡單的偷天換日，直接將二進位檔案換掉，對駭客來說較為單純，不過要駭入應用程式供應伺服器（也就是提供軟體供人下載的伺服器）不是一件容易的事，而且需要相當大的資源，所以駭客很喜歡用像網路釣魚（Phishing）、詐騙、DNS假冒攻擊等等的技巧，再不然就是假冒知名軟體廠商（甚至資安廠商）來提供惡意軟體或灰色軟體。

結語

本文先列舉了軟體開發供應鏈的一些基本資安問題，這些攻擊所牽涉的問題其實相當複雜，不是一篇簡單的文章就能全部交代清楚。但這是當前一個相當迫切的問題，因為，正如我們在2021年資安預測報告中所言，到了2021年底，企業大部分的工作負載都將轉到雲端上執行。也就是說，為了因應這場全球公衛危機，許多企業很可能會急就章地採用一些新的軟體，卻沒有通盤了解所有的資安問題。

＜本文作者：陳佑寰，目前為執業律師。國立台灣大學法學碩士，美國賓夕法尼亞大學法學碩士。專攻領域為智慧財產權法、高科技產業議題及資訊法等。＞