3. Curing Rootkit：設計與實作

3.1 架構概覽

Curing 採用客戶端-伺服器模型運作：

1. Client ：受感染主機利用 io_uring 執行指令。
2. Server ：指揮與控制 (C2) 基礎設施發送指令。

關鍵組件 ：

• 指令執行 ：客戶端透過 io_uring 網路操作獲取指令（例如 read /etc/shadow 、 execute payload ）。
• 系統呼叫規避 ：僅使用 io_uring_setup 和 io_uring_enter 系統呼叫進行初始化，後續操作繞過系統呼叫。

// 簡化的 I/O 請求提交程式碼片段
struct io_uring ring;
io_uring_queue_init(32, ˚, 0);
struct io_uring_sqe *sqe = io_uring_get_sqe(˚);
io_uring_prep_readv(sqe, fd, &iov, 1, 0);
io_uring_submit(˚);

3.2 攻擊流程

1. 初始化 ：客戶端使用基於 io_uring 的 socket 操作連接到 C2 伺服器。
2. 指令獲取 ：伺服器透過完成佇列(Queue)傳送加密指令。
3. 執行 ：客戶端使用 io_uring I/O 原語(Primitives)處理指令（例如檔案外洩）。
4. 結果回報 ：資料傳回伺服器，且不觸發基於系統呼叫的偵測。

4. 安全工具限制分析

4.1 Falco 與 Tetragon

• Falco ：依賴透過 eBPF 或核心模組的系統呼叫 Hook。ARMO 確認 Falco 的預設規則無法偵測基於 io_uring 的檔案存取或網路活動。使用 Linux Security Module (LSM) Hooks的插件(Plugin)仍在開發中。
• Tetragon ：雖然能監控 Kprobes 和 LSM Hooks，但 Tetragon 需手動設定才能追蹤 io_uring 操作，使大多數部署容易受到攻擊。

4.2 Microsoft Defender for Linux

Microsoft 的解決方案僅透過檔案完整性監控 (FIM) 偵測到檔案變更，而無法偵測基於 io_uring 的操作。網路層級的偵測完全被規避，凸顯其對系統呼叫追蹤的依賴。

4.3 eBPF 限制

eBPF 的驗證器限制了複雜的邏輯，迫使供應商優先考慮系統呼叫 Hooks 而不是更深層的核心偵測。這種權衡犧牲了 io_uring 和類似機制的可見性。

5. 偵測與緩解策略

5.1 異常偵測

• io_uring 使用分析 ：標記使用 io_uring 進行異常操作的程序（例如非資料庫應用程式）。
• 行為分析 ：監控透過 IORING_OP_SEND 啟動的加密 C2 流量等模式。

5.2 Kernel Runtime Security Instrumentation (KRSI)

KRSI 與 Linux Security Modules (LSM) 整合，將 eBPF 程式附加到安全關鍵 Hook （例如 file_open 、 socket_connect ）。這提供了不依賴系統呼叫的 io_uring 操作可見性。

5.3 供應商特定修正

• CrowdStrike ：更新 Falcon 以監控 io_uring 操作。
• Google ：在 Android、ChromeOS 和生產伺服器中關閉 io_uring。