網路資安威脅
從SolarWinds 資料外洩事件,看管理認證憑證的重要性
SolarWinds 資料外洩事件活生生地證明了機密有多麼脆弱,因為這起攻擊就是利用了強度不足的密碼,而這應該是重要的機密才對。雖然使用一套解決方案來集中保管機密可避免單靠密碼的缺點,但卻衍生出單一資料外洩事件可能導致所有登入憑證和密碼都同時外洩的風險。而這也突顯出機密資料的儲存必須當成金庫來看待。這類金庫的存取管制措施非常重要,最好加入生物特徵辨識或多重認證 (MFA) 機制。 機密管理是確保必要資訊安全、防止資訊落入駭客手中的重要關鍵。本文探討何謂機密,以及如何安全地儲存機密。

本文旨在協助企業認識並認真思考機密管理在今日環境的重要性,因為光是一個密碼遭到外洩就可能導致嚴重的資料外洩事件。隨著越來越多企業工作負載移轉至雲端上執行,像密碼這樣重要的存取資訊也變得日益重要。
機密管理是確保必要資訊安全、防止資訊落入駭客手中的重要關鍵。只要能妥善保管機密,例如密碼和其他認證憑證,理論上就能確保唯有適當人員才能存取重要資產,減少企業遭駭客入侵的機率。然而機密就如同一把雙面刃,尤其是當企業的保密工作做得不夠確實時。
我們曾經在先前的一篇文章探討過供應鏈的一些脆弱環節,而供應鏈上各環節所面臨的一項問題就是:如何建立適當的機密儲存機制。本文將探討有哪些機密需要妥善保護,以及這些機密在資安上所扮演的角色、影響及可能衍生的問題為何。
何謂機密?
首先,讓我們定義所謂的「機密」是指什麼。本文中的「機密」一詞,意指那些用來通過認證以便存取電腦系統的敏感資訊,包括各種登入憑證 (使用者名稱、電子郵件地址、密碼) 以及存取金鑰 (access token) 或私密金鑰 (private key)。SolarWinds 資料外洩事件活生生地證明了機密有多麼脆弱,因為這起攻擊就是利用了強度不足的密碼,而這應該是重要的機密才對。
延伸閱讀: 從 SolarWIND 事件思考供應鏈安全的脆弱環節
高強度密碼的重要性
我們就以這起事件為例來探討一下密碼強度的問題。密碼的強度取決於它的長度與所用的字母集有多大。因為這兩項因素將決定了駭客在暴力破解密碼時有多少組合要猜測。理論上,這些組合的數量可用 xy 來表示,其中 x 代表字母集中的字母數量,y 則代表密碼的長度有幾個字元。所以密碼的字母組合從數百種到數十億種都有可能。
但這並非絕對,因為如果密碼中使用了一些字典裡常見的字,就會讓密碼變得很容易猜測。一般來說,當密碼中的字元越隨機、字母集越大,那麼密碼的安全性就越高。除此之外,重複使用相同的密碼也會降低密碼的安全性。
字母集 | 字母集大小 | 6 個字元可構成多少種組合 | 10 個字元可構成多少種組合 |
A – Z | 26 | 308,915,776 | 141,167,095,653,376 |
「A – Z」 (大寫英文字母) +「a – z」(小寫英文字母) | 52 | 19,770,609,664 | |
「A – Z」 (大寫英文字母) +「a – z」(小寫英文字母) +「0 – 9」(阿拉伯數字) | 62 | 56,800,235,584 | |
所有可列印字元 | 126 | 4,001,504,141,376 |
表 1:密碼長度 (6 或 10 個字元) 與暴力破解所需猜測的組合數量。
雖然如此,但長度較長、強度較高的密碼,通常是一長串隨機的字碼,因此對使用者來說很難記住,尤其,每個人通常都有很多個帳號要記。

就算使用者牢牢記住了一組高強度的密碼,但這組密碼卻用在每個地方,那安全性就會大打折扣。密碼重複使用是另一個常見的資安風險,當資料外洩事件發生時,那些重複使用的密碼就會連帶使得其他帳號也被駭,進而造成更大損害。
高強度密碼固然重要,但我們仍不免質疑,難道營運關鍵資產與系統只能單靠一項機密來確保存取安全?難道只能靠密碼來驗證登入?
密碼以外的替代方案
所幸,除了密碼之外,我們還有其他選擇,例如,Secure Shell (SSH) 服務向來都採用非對稱式加密與私密金鑰來進行認證,如此大幅降低了機密被猜到的風險,並且強制要求企業要有適當的機密儲存機制。
雖然這還是需要使用一個金鑰來認證使用者,但已經降低對人類記憶能力的要求。例如,我們也可以使用一個金庫來儲存登入憑證,並利用一個工具來產生機密資訊。此外,這類工具還能防止使用者建立強度不足的密碼或重複使用相同密碼。
雖然使用一套解決方案來集中保管機密可避免單靠密碼的缺點,但卻衍生出單一資料外洩事件可能導致所有登入憑證和密碼都同時外洩的風險。而這也突顯出機密資料的儲存必須當成金庫來看待。這類金庫的存取管制措施非常重要,最好加入生物特徵辨識或多重認證 (MFA) 機制。
MFA 本身就能大幅降低被駭的機率,因為就算登入憑證遭到外洩,登入時還是需要經由另一個管道來取得認證 (這通常是經由行動應用程式)。而使用者同時發生登入憑證被盜「並且」手機又遭駭客入侵或失竊的機率,可說是相當低。

機密有效期限
相信您在使用電腦的經驗中,也曾被要求定期每隔一段時間就要變更密碼。有些人覺得這樣很麻煩,但機密的效期設定是有意義的,因為機密在一段時間之後有可能被破解,所以它們存在的時間越久,某天被駭客竊取或因為某家企業發生資料外洩而外流的機率就越大。
機密的儲存形式
接下來,我們來討論機密的儲存形式。正如前面所說,機密的儲存應被視為虛擬金庫來看待與保護,因為一旦遭駭,就會讓金庫中的所有帳號和密碼都外洩。
企業流程當中需要互相溝通的系統越來越多,這些溝通必須確保安全,使用者的每一個請求也都必須經過認證才能執行。所以,如果使用者不想一直重複輸入登入憑證,或者登入憑證很難記住,那麼就必須想辦法儲存登入憑證。
登入憑證有以下幾種儲存形式:
- 純文字:這是最不安全的形式,因為只要能夠讀取到這個純存字檔就能進入系統。
- 雜湊碼:這是伺服器使用最廣的儲存形式,這種形式所儲存的是機密的指紋,而不是機密本身,如此可防止駭客取得純文字密碼。針對這類儲存形式,我們建議應該在既有的加密演算法上再多增加一道雜湊碼,讓駭客更難破解。
- 編碼:這是另一種純文字儲存形式,最常見的就是經過 base64 編碼的登入憑證,將機密編碼成無法直接閱讀的格式。
- 加密:使用另一個密碼來將登入憑證加密,進一步降低資料外洩的機率和衝擊。任何人即使拿到了加密的檔案,也無法將它解密來取得裡面的登入憑證,除非知道用來加密的密碼。
從以上四種我們就能輕易看出哪種是最有利、也最安全的機密儲存形式。不過除了形式之外,企業在儲存登入憑證時,還有其他因素必須考量。
考慮採用其他應用程式
有一種儲存機密的方式是使用一個外部應用程式來當成金庫,這類機密金庫的主要優點是它們會以加密形式儲存機密,並且可從單一位置變更機密,變更後會自動套用至各個應用程式而不需逐一修改。
但是,金庫本身的存取金鑰必須儲存在電腦上或者經由動態方式取得。如果是後者,那麼經由多重認證途徑取得動態產生的金鑰是最好的。但多重認證並非永遠是最佳選擇,尤其是對於高度自動化的系統。
純文字的問題
並非每一種儲存機密的應用程式都預設採用加密形式來儲存登入憑證。請務必參閱應用程式說明文件來確認被儲存的機密是否加密,此外也應小心檢查組態設定以防止錯誤。很多時候,以純文字形式來儲存機密會被視為漏洞。通常,使用純文字形式不僅不安全,而且被視為是一種設計上的不良,所以應該盡量避免。後續有關DevOps 以及雲端問題的討論也大多圍繞在純文字的問題。

高信任度
最後,即使機密已採用加密形式儲存,企業人員之間仍應建立一定程度的信任並共同分擔責任,因為畢竟還是要有人知道或保管加密金鑰。企業應切記機密只能給少數限定人員存取。換句話說,唯有具備充分理由的使用者或應用程式才能存取機密儲存設備或系統。此外,如果能將機密加密,就可以再多一道保護,讓歹徒更難破解。
機密的傳輸
除了機密的保存之外,需要傳輸機密的服務也要妥善設定以提供安全防護。這一點很重要,因為機密經常必須移動,因此要預先規劃好,並經由安全 (如加密) 的通道來進行。
所謂安全的通道,是指預設使用安全通訊協定的通道,例如:SSH 或 HTTPS。如果使用純文字通訊協定 (如 HTTP、SMTP、FTP) 來傳輸機密,可能會被駭客從中攔截,導致機密外洩。
值得一提的是,將機密儲存在原始程式碼管理系統 (SCM) 也不是個好主意,因為這會讓更多不必要的人取得機密。如果這些 SCM 系統是公開的儲存庫,那就更加危險。企業若堅持要將機密放入 SCM 中,那應該使用某些工具來將機密加密 (如 git-secret) 以防止 SCM 變成資安破口,讓供應鏈攻擊有機可乘,正如我們之前的文章所說。
機密外洩的衝擊
接下來我們要探討在今日的應用程式開發環境下 (也就是 DevOps 及雲端) 如果使用不安全的機密儲存方式會有什麼後果。此外我們也概略描述了一個真實案例來說明駭客如何取得感染裝置上的登入憑證。
機密與 DevOps
今日,絕大多數人都認為應用程式開發環境或「本地端」環境基本上是安全的。比方說,人們會以未加密形式儲存機密,且設計軟體時只仰賴環境的安全性,而不去強化軟體本身的安全功能。這樣對使用者來說也較為輕鬆,因為使用者就不必去管理複雜的安全設定。但代價就是,這樣的作法會增加資安事件發生的風險。我們已看到供應鏈攻擊、VPN 安全性不足、VPN 漏洞等等所引發的不良後果。
還有,使用者很重要必須認清的一點是,所謂的「本地端」環境其實已經不復存在,越來越多企業都已邁向雲端。當機密以純文字方式將機密儲存在一個有硬體加密保護的裝置時,這些資料很可能也會同步傳送至裝置連線的雲端。簡而言之,不論是否儲存在雲端,採用純文字形式來儲存機密就是不安全的作法。
一個跟 DevOps 相關的真實案例就是,Visual Studio Code 直到 2021 年 1 月發表的 1.5353 版開始才支援機密儲存。在這新版本推出之前,該平台並無正式的 API 可用來安全地保存機密,因此開發人員得自己想辦法。

在一份追蹤研究當中,我們發現另有 338 種延伸功能也存在著用純文字形式來儲存機密的問題。而這些第三方延伸功能都會連結到雲端服務供應商 (CSP) 及 SCM 系統。更棘手的是,駭客正四處搜括登入憑證,而 Visual Studio Code 使用者也因而成為他們容易下手的目標。
機密與雲端威脅
隨著越來越多企業開始採用雲端技術,駭客也不斷開發新的惡意程式,並努力搜刮雲端服務登入憑證。此處一個重要的思考方向是,若我們能改變儲存的機制,就有機會大大提升安全性,因為這些機密太常被儲存成純文字形式,而這又導因於使用者總覺得自己所在的環境是安全的。然而,讓機密大剌剌地以純文字形式存在,無疑讓駭客更容易竊取機密。當企業將營運搬到雲端時,就必須共同承擔雲端的資安責任。即使上了雲端,其所使用的登入憑證還是自己要負責妥善保管。
前面提到,在保管機密的人員之間建立強大的互信,是確保機密安全的一項必要條件。雲端廠商經常引用責任共同分擔的架構,尤其是使用者自己所犯的組態設定錯誤。而且廠商與客戶之間共同分擔資安責任是絕對必要的,因為沒有任何軟體是 100% 安全的。例如,先前的部落格介紹了駭客如何在入侵某個雲端執行個體之後,隨即透過 AWS Metadata Service 取得登入憑證或機密。這顯示一旦駭客入侵了某個執行個體之後就能取得該雲端執行個體上的登入憑證。

此外,還有一種更普遍的手法是,CSP 的指令列工具會在首次進行組態設定時產生授權金鑰,然後將這些金鑰以純文字形式儲存在檔案或系統變數當中。掌握這項功能的運作之後,駭客就能開發惡意程式讓他們在駭入執行個體之後搜尋這些金鑰。視被偷的登入憑證金鑰存取權限而定, 駭客有可能因而駭入更多的系統並在內部散布惡意程式。

在我們研究時,有一種行為模式特別引起了我們的注意。駭客會在攻擊的不同階段中使用 CSP 的原生工具,而非開發自己的專屬工具,或者攻擊系統漏洞。在這類案例當中,駭客將獲得與該服務相同的權限,也就是使用者在組態設定中所設定的權限。這樣的行為,顯示駭客正在不斷嘗試各種可能選項以及雲端原生工具的各種參數,並善加利用。圖 7 顯示,駭客在腳本中插入了一些關於雲端原生工具的說明,這讓我們不由得想到駭客應該是在邊做邊嘗試。在Lambda 之類的內部環境中,原生工具的使用是預先授權的,因此只要駭客能成功上傳工具到裡面,就能取得與該服務相同的權限。

真實案例
以下介紹一個真實案例來說明妥善儲存機密的重要性。我們發現,駭客藉由搜刮被感染裝置上的登入憑證,就能經由惡意程式來感染其他裝置,只要第一個被感染裝置上儲存了其他裝置的登入憑證即可,這會發生在駭客取得修改雲端服務的能力之後。

此外,還有一項近期調查也顯示,駭客正努力適應最新的技術,並積極嘗試攻擊一些基礎設施即程式碼 (IaC) 軟體,例如 Ansible、Chef、SaltStack 等工具,好讓他們盡可能感染更多裝置。

容器
最後,企業機構也應對駭客如何攻擊日益普及的容器有所了解。容器說穿了就是一個處理程序,只不過在權限和能力上都受到限制,但特權容器 (Privileged Containers) 就沒有這樣的限制,請參考我們先前的文章所提出的警告。最近,我們看到駭客也發展出攻擊容器漏洞的能力。要在容器內執行一個服務,通常需要使用機密來存取另一個服務,前述有關妥善保管機密及其儲存形式的原則在這裡也同樣適用。
以下這段影片顯示駭客如何利用 TeamTNT 駭客集團的工具來跳脫一個 Docker 容器。
保護機密安全
企業現在應該已經了解,機密對確保企業資安扮演著多麼重要的守門員角色。這就是為何企業應假設駭客隨時都在覬覦這些機密,並隨時做好準備。保護機密安全也跟履行共同分擔的安全義務息息相關,企業不應假設資料一旦儲存在雲端就安全無虞,所以應採用一些額外的防護措施來保護雲端原生系統,例如專為雲端設計解決方案。
還是那句老話,沒有一種萬靈丹可以解決上述所有的問題。但企業可重新檢視自己所用的服務來著手,深入了解自己有哪些類型的機密需要儲存,以及目前所用的儲存及傳輸方式,如此就能更精確掌握自己的風險,做好更周全的準備來防範資料外洩。