eBPF 雙子座：天使 or 惡魔？| 龍蜥技術

文/許慶偉：龍蜥社群 eBPF 技術探索 SIG 組 Maintainer 高階核心技術專家，對 Linux 核心、系統穩定性領域有深入研究。

01 啟示錄

新約聖經啟示錄認為：惡魔其實本身是天使，但熾天使長路西法背叛了天堂，翅膀變成了黑色，墜落地獄，墮落成為惡魔。這些惡魔主宰著黑暗勢力，阻礙人類與上帝溝通，無所不用其極。所以可以說天使和惡魔本來是一體的，只是命運不同。

隨著 eBPF 技術在各種行業領域上的使用和普及，人們在享受著技術變革紅利的同時，也遭受著無孔不入的惡意攻擊，就像任何事物都有兩面性一樣。沒有任何一項技術只有高高在上的優勢，而沒有弊端，只有更加清晰的刨析清楚 eBPF 的核心，才能推動它不斷的進步，趨利避害，儘可能發揮正向的作用。

那麼，eBPF 是天使，亦或惡魔？

越來越嚴峻的 Linux 安全形勢

根據安全分析機構 ESG 雲原生安全研究（連結見文末），88% 的網路安全專業人士表示，在過去 12 個月中，他們的雲原生應用程式和基礎設施遭受過攻擊 。然而，許多旨在保護 Linux 的雲安全解決方案可能很麻煩且具有破壞性，因為它們是從 Mac 或 Windows 作業系統上移植而來，這些方案有時會影響到 Linux 系統的處理能力，甚至進行更改。

在 Linux 領域，很多安全公司都發布了自研的 MDR、XDR、EDR 產品，大多數方案是基於輕量級代理在靜默收集遙測資料，同時最大限度地減少任何可能的效能影響，並將託管檢測和響應擴充套件到系統的本地和雲上，通常構建有基於規則的自動響應和分析功能，比如 SanerNow、Automox、Cybereason、Syxsense Secure、Sangfor Endpoint Secure 等等，大致有以下特點：

1. 從端點監視和收集可能暗示 威脅的活動資料

2. 評估收集的資料以確定威脅模式

3. 自動響應已識別的威脅以消除或遏制它們，並通知安全人員

4. 使用取證和分析工具研究已識別的威脅並尋找可疑活動

目前在 Linux 環境下，對於 EDR、XDR 產品也提出更加嚴格的要求：

1. Linux 威脅和攻擊媒介與 Windows/Mac OS 對應物不同，需要單獨構建策略。

2. Linux 通常是生產系統的基礎，不能因為產品的中斷或干擾會對業務產生負面影響。

3. 構建輕型 Linux EDR 感測器專為 Linux 構建和最佳化，對系統的影響降到最小。

基於 Linux 系統的雲原生基礎架構設施

雲原生應用程式的組合是 CI/CD 持續整合和交付的 API、容器、VM 和無伺服器功能的組合。保護這些應用程式、底層基礎設施和協調其部署的自動化平臺，需要重新審視威脅模型、獲得組織一致性並利用有目的的控制。此外，隨著安全性和 DevOps 不斷融合，雲安全控制正在得到整合。將孤立的方法發展為統一的策略，以保護雲原生應用程式和平臺是目前很多安全廠商發力的目標，也是甲方實實在在的需求。與此同時，更多的安全廠商正在嘗試將雲安全態勢管理 (CSPM)、雲工作負載保護 (CWP)、容器安全等方案，整合到整合的雲安全套件中，從而增大自身安全產品在市場上的競爭力和話語權，也避免安全產品的碎片化。

雲原生的基礎設施包含 CPU 硬體、指令集，作業系統等，增強作業系統的高效能和安全性，也是目前 eBPF 技術正在深入的領域，所以 eBPF 自身的安全能力，也是檢驗該項技術是否有可持續發展的重要指標。

02 eBPF：惡魔面孔

eBPF （擴充套件的 Berkeley 資料包過濾器）席捲了 Linux 世界。它於 2013 年首次推出以支援可程式設計網路，現在用於可觀察性、安全性、網路等。許多大公司——包括 Meta、谷歌、微軟和 Netflix——都致力於幫助開發和支援它，尤其是在雲原生領域的重要性越來越高。注意：“eBPF”和“BPF”實際上是同義詞，社群經常互換使用這些術語，部分原因是 eBPF 幾乎完全取代了經典的 BPF 技術。

在過去的幾年裡，黑產組織一直在研究利用 eBPF 來開發並擴大 Linux 惡意軟體方面的作用，安全研究人員則不停的修復漏洞，並試圖提前感知預測 0-day 漏洞。最近，有一些 eBPF 相關的 CVE 報告示例頻繁的出現在 DEFCON 和 BlackHat 等頂級安全會議上，也讓人們更加的重視和擔心 eBPF 的安全性，如下 topic，後續我會逐步翻譯驗證，並同步分享出來：

• Evil eBPF In-Depth: Practical Abuses of an In-Kernel Bytecode Runtime

• Warping Reality - creating and countering the next generation of Linux rootkits using eBPF

• eBPF, I thought we were friends !

• With Friends Like eBPF, Who Needs Enemies?

• Fixing a Memory Forensics Blind Spot: Linux Kernel Tracing

現在讓我們深入瞭解 eBPF 機制，看看駭客是如何利用這些強大功能來達到攻擊的目的。

• bpf_probe_write_user

利用：eBPF 程式可以訪問一組有限的輔助函式，這些函式內建於核心中。基於 eBPF 惡意利用的一個助手就是 bpf_probe_write_user。此函式允許 eBPF 程式寫入當前正在執行的程式的使用者空間記憶體。惡意利用可以使用這種能力在系統呼叫期間修改程式的記憶體，例如 bad-bpfsudo 在讀取時寫入使用者空間記憶體 /etc/sudoers。它注入了一個額外 code，允許特定使用者使用該 sudo 命令。

限制：

（1）如果記憶體被換出或未標記為可寫，該函式將失敗。

（2）一條警告訊息會列印到核心日誌中，說明正在使用該函式。這是為了警告使用者程式正在使用具有潛在危險的 eBPF 輔助函式。

• bpf_override_return

利用：另一個 eBPF 輔助函式 bpf_override_return 允許程式覆蓋返回值。駭客可以利用它來阻止惡意利用行為。例如，如果你想執行 kill -9 ，駭客可以將 kprobe 附加到適當的核心函式以處理 kill 訊號，返回錯誤，並有效地阻止系統呼叫的發生。開源專案 ebpfkit 使用它來阻止可能導致發現控制 eBPF 程式的使用者空間程式的操作。

限制：

（1）核心構建時開啟選項：CONFIG_BPF_KPROBE_OVERRIDE

（2）目前僅支援 x86

（3）只能與 kprobes 一起使用

• XDP 和 TC

利用：ebpfkit 利用 XDP 和 TC 進行隱式通訊。下圖來自 Blackhat 會議演講 PPT，其中 ebpfkit 的建立者（Guillaume Fournier、Sylvain Afchain 和 Sylvain Baubeau），在演講中，他們概述瞭如何使用 XDP 和 TC 隱藏傳送到 ebpfkit 的命令，主機上執行的 XDP 程式接收並處理請求。該程式將其識別為對主機上執行的惡意利用的請求，並將資料包修改為對主機上執行的 Web 應用程式的普通 HTTP 請求。在出口處，ebpfkit 使用 TC 程式捕獲來自 web app 的響應，並使用來自 ebpfkit 的響應資料修改其輸出。

限制：

XDP 程式執行得太早，資料與程式或套接字無關，因此資料包周圍幾乎沒有上下文。

03 eBPF：天使面孔

eBPF 的核心是可以在 Linux 核心中類似虛擬機器結構中執行的一種指令集架構(ISA)，擁有暫存器、指令和堆疊等。為了使用 eBPF，使用者可以建立 eBPF 程式並將它們附加到系統的適當位置，通常是在核心中。當與附加點相關的事件發生時，程式執行並有機會從系統讀取數，將該資料返回給使用者空間中的控制應用程式。總而言之，eBPF 允許使用者動態安裝在核心上下文中執行，但可從使用者空間編排的程式碼。它有點像使用者空間應用程式和 Linux 核心模組之間的混合體。

關於 eBPF 的基礎知識無需贅述，網路上已經有太多豐富的教程和分析文章，個人建議初學者可以先從官方網站 上開始瞭解 eBPF 的前生今世，也可以直接在 kernel 原始碼具體例項中學習和驗證。eBPF 在為諸多 Linux 核心開發者提供便利的同時，也為惡意軟體的開發者提供了新的利用領域，這也就是“天使惡魔”的混合體來源。

下圖總結了 eBPF 程式的整個生命週期：

安全優勢：

1. Socket filters 套接字過濾器是經典 BPF 的原始用例。套接字過濾器是一個可以附加到套接字的 eBPF 程式。然後該程式可以過濾該套接字的傳入流量。Berkley Packet Filter 的名稱暗示它是一種旨在過濾資料包資料的技術。這個功能甚至一直保留到現代 eBPF 中。

2. ByteCode eBPF 程式通常以“受限”C 程式開始。受限意味著堆疊大小、程式大小、迴圈、可用函式等與普通 C 程式相比受到限制。C 程式碼被編譯成 eBPF 位元組碼。

3. Verifier 在 eBPF 程式碼完全載入到核心之前，它會透過驗證器執行。驗證者的工作是確定 eBPF 程式是否可以安全執行。“安全”是指它不會陷入無限迴圈，沒有不安全的記憶體操作，並且低於最大複雜度/程式碼大小。

安全策略：

1. 確保非特權 eBPF 被禁用。 如今，要安裝 eBPF 程式，您通常需要 root——或至少需要 CAP_SYS_ADMIN 和/或 CAP_BPF。情況並非總是如此。圍繞核心 4.4 引入了非特權 eBPF。請務必透過執行以下命令檢查此配置選項：

sysctl kernel.unprivileged_bpf_disabled

1. 禁用不需要的功能。管理員可以透過程式設計方式禁用諸如 kprobes 之類的東西：

echo 0 > /sys/kernel/debug/kprobes/enabled

1. 在不支援 kprobes、基於 eBPF 的 TC 過濾器或完全支援 eBPF 的情況下構建核心（儘管這可能不是許多人的選擇）。

2. ONFIG_BPF_KPROBE_OVERRIDE 除非絕對必要，否則不設定 Ensure。

安全檢測：

從安全週期的角度來看，一場檢測分為三個大階段：事前（執行前）、事中（執行時）、事後（攻擊後）。安全人員都希望可以在執行前透過一系列的靜態分析方法來檢測出異常，從而將問題扼殺在搖籃裡。但現實往往事與願違，更多的異常檢測場景發生在執行時，這個時候就需要安全人員設計的產品模型具有很強的鑑白和鑑黑能力，這也是絕對了最終方案是否成功的基石。

從 eBPF 以及 Linux Tracing 的維度來看看具體方案：

1. 尋找載入的意外 kprobes。

#cat /sys/kernel/debug/kprobes/列表
ffffffff8ad687e0 r ip_local_out+0x0 [FTRACE]
ffffffff8ad687e0 k ip_local_out+0x0 [FTRACE]

1. 用 bpftool 列出系統中正在使用 eBPF 的程式。

# bpftool prog
176: cgroup_skb tag 6deef7357e7b4530 gpl
loaded_at 2022-10-31T04:38:09-0700 uid 0
xlated 64B jited 54B memlock 4096B
185: kprobe tag a7ce508aab49e47f gpl
loaded_at 2022-10-31T10:03:16-0700 uid 0
xlated 112B jited 69B memlock 4096B map_ids 40
# bpftool perf
pid 543805 fd 22: prog_id 3610 kprobe func tcp_v4_connect offset 0
pid 543805 fd 23: prog_id 3610 kprobe func tcp_v6_connect offset 0
pid 543805 fd 25: prog_id 3611 kretprobe func tcp_v4_connect offset 0
pid 543805 fd 26: prog_id 3611 kretprobe func tcp_v6_connect offset 0
pid 543805 fd 28: prog_id 3612 kretprobe func inet_csk_accept offset 0

1. 查詢載入的 XDP 程式。

$ ip link show dev <interface>
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 xdpgeneric qdisc noqueue state UNKNOWN mode DEFAULT group default qlen 1000
link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
prog/xdp id 220 tag 3b185187f1855c4c jited

1. 檢查 bpffs（BPF 檔案系統）中是否有任何 pinned objects。

$ mount | grep bpf
…
bpf on /sys/fs/bpf type bpf (rw,nosuid,nodev,noexec,relatime,mode=700)
…
#ls -la /sys/fs/bpf/

1. 檢查是否載入了任何 TC 程式。

#tc filter show dev <device-name>

1. 監視系統日誌中是否提及 BPF 幫助程式生成的警告訊息。

#dmesg -k | grep ‘bpf_probe_write_user’

04 尾聲

總之，eBPF 目前已經成了安全研究人員和駭客手中強大的工具，亦正亦邪，取決於使用者的選擇。由於這種正規化將過去實施惡意利用的方式和流程進行了轉變，對於安全人員也提升了要求，需要研究和理解新興威脅的前沿技術及利用。

隨著不斷地地分析並認識到了如何識別和檢測 eBPF 的惡意濫用，我們未來將更深入地瞭解此類利用的原理、行為方式以及檢測它的最佳方式，後續研究分析將持續分享。

eBPF 雙子座：天使 or 惡魔？由你決定！

eBPF 技術探索 SIG 主頁：

安全分析機構 ESG 雲原生安全研究：

https://www.esg-global.com/research/esg-research-report-the-maturation-of-cloud-native-security

—— 完 ——