VED（Vault Exploit Defense）： Linux內核威脅檢測與防護系統 September 6, 2021 | 5 min Read

VED（Vault Exploit Defense）： Linux內核威脅檢測與防護系統

背景

自從1996年Aleph One在Phrack Issue 49上發表了Smashing The Stack For Fun And Profit的論文后，開啟了長期的爭奪記憶體核心控制權的戰爭，攻擊者在之後的10年裡大多把目標放在用戶空間，但隨著用戶空間mitigation的普及更多的攻擊者開始把核心轉移到了內核，2015年，PaX/GRsecurity作者接受華盛頓郵報採訪並揭露了Linux內核安全問題後由Google，RedHat, ARM, Intel豪華陣容組成Linux內核自防護計劃。

可惜此計劃進行了6年後的今天已經接近流產，但Linux則進入了更多重要基礎設施的領域，比如電力，能源，車聯網，工業控制等，遺憾的是，Linux內核安全的問題依舊沒有解決。

alter-text

  • 一個Linux內核漏洞的修復從upstream到發行版內核（生產環境）的鏈條過長，因為實際情況是沒有人會真正意義上使用“upstream”的內核

  • 內核穩定分支以及發行版社區難以跟進每一個安全修復的分析，回歸測試以及防禦手段，甚至會出現漏掉的情況

  • Linux內核社區堅持“security through obscurity「哲學，這意味著內核社區從來不主動申請CVE漏洞編號，即使如此，2021年1月到8月，有CVE編號的內核漏洞超過110個

  • 漏洞軍火商有自己的生態，他們並不關心是否有CVE的存在而只關注漏洞的成因以及漏洞利用的方法

Linux內核常見的漏洞類型：

  • 緩衝區溢出（堆/棧/靜態資料）

  • 堆物件錯誤行為（double-free， use-after-free， etc）

  • 整數溢出（向下越界分配，緩衝區溢出，引用計數，etc）

  • 競爭條件

  • 資訊洩漏

Linux內核常見的漏洞利用方法：

  • 執行注入的shellcode，比如ret2usr

  • 執行現有的代碼構建ROP/JOP鏈條

  • 任意讀，利用資訊洩漏

  • 任意寫，污染關鍵數據結構

我們的方案：VED

為了幫助行業客戶解決以上問題，HardenedVault開發的Linux內核0day漏洞防護方案VED的威脅模型基本如下：

  • 作為一個以LKM載入的方案，基本實現框架基於hook，相容現有Linux內核安全防護的hook方案（比如AKO或者LKRG

  • 盡量在更早階段針對漏洞利用平面進行阻斷，失敗后再進行後期的檢測類阻斷

  • 誰去守護守護者是一個安全哲學問題，VED是一款重要安全產品，因為它是防護企業生產環境的重要防線（突破內核后就是虛擬化，固件和硬體層了，所以可以說是最後一道有意義的防線），所以VED必須具備自防護特性

VED重要特性包括如下：

  • wcfi，掃描內核代碼段並針對漏洞利用常見路徑進行防護，支援兩種可疊加的防禦模式：

** 檢察返回位址之前一個指令是否是一個call指令（無論是調地址還是調寄存器或指標），這裡只判斷範圍。 此feature可以抵禦ROP鏈隨機的使用任何block，只有以call開始ret結束的block才可能繞過wcfi，加大ROP的難度

** 重要且只可能被直接調用（調用位址，而非寄存器或指標）的函數，VED計算返回位址前的call 指令的位址（一個立即數）指向這個重點防護清單中的函數，滿足其條件判斷為合法，否則直接阻斷。 可以阻斷結構體的函數指標被修改以後嘗試調用提權相關的函數。

  • 針對重要數據結構的防護

  • VSPP（VED自防護體系），這個的重要性在多攻擊方的場景更為重要：

alter-text
  • 後漏洞利用階段中的檢測手段，包括針對SMEP/SMAP ， creds， MODHELPER等。

車聯網場景

根據upstream auto 2020報告，車聯網場景中來自雲端， 車載娛樂系統和ECU/TCU/GW的攻擊佔比為27.22%，7.69%和5.03%：

alter-text

而這些系統中運行Linux系統的比例是很高的，雖然在國際協作標準組織AUTOSAR針對車聯網AP平臺安全管理中有對Linux安全防護有一定要求(AUTOSAR APR20-11），但這些要求一方面過於簡單， 並未將當前車聯網系統安全的漏洞利用情況以及場景化加入威脅模型：

alter-text

另外一方面技術層面並未與時俱進，賽博堡壘和AUTOSAR的溝通中提出了一些修訂提議。

雲原生安全架構

相比傳統的物理機和虛擬機為主要業務支撐基礎設施，Kubernetes架構對於業務來說大大的降低開發和運維的標準化難度，這對安全是一個利好，基本上基於雲原生的架構可以簡化為三大元件：

alter-text

  • 基於Falco定製開發的監控和審計系統，數據採集Falco的driver有兩種主要模式（這裡不探討基於使用者空間的實現），預設是基於tracepoint實現的內核模組去對大約88個syscall監控，第二種是用eBPF對大約81個syscall進行監控，底層實現也是基於tracepoints。 企業使用者可以基於Falco框架編寫和定製代碼和規則以滿足需求。

  • 針對內核元件的防護，由於Falco增量部署越來越多使用eBPF，所以也需要防護eBPF這個重要的內核元件，另外，針對越級提權和容器逃逸的防護是必要的，這種業務環境哪怕一個容器逃逸成功也可能波及到整個集群的數據安全。

  • SIEM/ELK日誌分析平臺

在雲原生安全架構中，VED可以和Falco監控和審計規則更好的配合，也可以把阻斷攻擊的日誌發送給SIEM/ELK平台進行分析。 近期收到了一些漏洞風險的詢問，這裡演示一個VED如何防禦CVE-2021-22555的過程，這個漏洞是在kCTF（基於Kubernetes用於CTF安全競賽的平臺）上發現的：

alter-text