【CSDN 編者按】eBPF 目前已經成了安全研究人員和黑客手中強大的工具，亦正亦邪，取決於使用者的選擇。

作者 | 許慶偉責編 | 王子彧

出品 | OpenAnolis（龍蜥）

啟示錄

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

隨著 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 自身的安全能力，也是檢驗該項技術是否有可持續發展的重要指標。

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 的響應數據修改其輸出。

限制：

（1）XDP 程序運行得太早，數據與進程或套接字無關，因此數據包周圍幾乎沒有上下文。

https://www.blackhat.com/us-21/briefings/schedule/index.html#with-friends-like-ebpf-who-needs-enemies-23619

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

2. 禁用不需要的功能。管理員可以通過編程方式禁用諸如 kprobes 之類的東西：

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

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

4. 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]

2. 用 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

3. 查找加載的 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

4. 檢查 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/

5. 檢查是否加載了任何 TC 程序。

#tc filter show dev <device-name>

6. 監視系統日誌中是否提及 BPF 幫助程序生成的警告消息。

#dmesg -k | grep 『bpf_probe_write_user』

尾聲

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

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

作者簡介：

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

參考連結：

eBPF 技術探索 SIG 主頁：https://openanolis.cn/sig/ebpfresearch

安全分析機構 ESG 雲原生安全研究：https://www.esg-global.com/research/esg-research-report-the-maturation-of-cloud-native-security

本文經授權轉自微信公眾號 OpenAnolis（龍蜥）

從 Linux 安全看，eBPF 的出現是「天使」還是「惡魔」？

越來越嚴峻的 Linux 安全形勢

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

安全優勢：

安全策略：

安全檢測：