Colson Wilhoit•Samir Bousseaden•Jake King•Andrew Pease

使用 Elastic 检测和响应脏管道漏洞

Elastic Security 正在发布用于检测脏管道漏洞的检测逻辑。

阅读 11 分钟安全研究
Detecting and responding to Dirty Pipe with Elastic

导言

脏管道是一种本地提权漏洞，很容易被利用，并且已经有大量可用的漏洞利用 POC。其广泛的范围（任何用户可读文件和受影响的 Linux 版本）及其不断发展的性质（SUID shell 后门漏洞利用）使得 CVE-2022-0847 对于可能存在漏洞的系统管理员来说尤其危险。

什么是脏管道 (CVE-2022-0847)？

CVE-2022-0847 是一个 Linux 本地提权漏洞，由安全研究员 Max Kellermann 发现，它利用 Linux 内核管理页面文件和命名管道的方式，允许覆盖只读文件中的数据。此漏洞影响 Linux 内核 5.8 及更高版本，直到 5.16.11、5.15.25 和 5.10.102 之前的任何版本。

有什么影响？

由于已经发布了许多 POC，因此可以很容易地利用此漏洞来获得 root 级权限，例如，通过重写敏感文件（如“/etc/passwd”）或通过注入恶意代码劫持 SUID root 二进制文件（如 sudo）。

Elastic 如何应对？

Elastic 正在发布可用于检测此漏洞利用的检测逻辑和 Auditd 规则。

脏管道详情

此漏洞的利用是因为新的管道缓冲区结构中存在缺陷，其中标志成员缺少正确的初始化，并且可能包含过时的值。然后，这可用于写入只读文件后面的页面缓存中的页面，从而实现权限提升。鉴于此漏洞的特殊性质，检测可能非常困难。

Linux 管道和 CVE-2022-0847

管道是一种进程间通信机制，在 Linux 中表示为一个文件，可以接收输入数据并为该数据提供输出。一个进程的输出可以使用“管道”在两者之间转发数据，从而成为另一个进程的输入。

管道由 CPU 在内存中管理，它们的数据被称为“页面”。

此漏洞的利用使用一种名为“页面拼接”的过程。页面拼接用于合并内存中不同管道页面之间的数据，而无需重写数据。

我们在摘要中引用的标志是 PIPE_BUF_FLAG_CAN_MERGE 标志。必须设置此标志才能合并页面缓存，并且仅当管道页面已满时才设置。但是，如果页面缓存完全为空，此标志仍然存在（缺乏初始化），这就是问题所在。

此漏洞利用通常通过以下方式发挥作用

  1. 打开一个新管道
  2. 用任意数据填充管道的页面缓存，以便设置 PIPE_BUF_FLAG_CAN_MERGE 标志
  3. 清空数据页面缓存，但保留 PIPE_BUF_FLAG_CAN_MERGE 标志，并将数据替换为他们想要覆盖只读文件的新数据
  4. 然后使用 splice（“页面拼接”）系统调用来合并页面（管道页面和目标文件页面），从而将新数据添加到目标文件，绕过只读权限

到目前为止，观察到的许多漏洞利用 POC 都以 /etc/passwd 文件为目标进行覆盖，并为用户提供提升的 root 权限。发布的漏洞利用的其他变体允许通过覆盖具有 SUID 权限（超级用户功能）的二进制文件来创建 SUID shell 后门，从而为用户提供 root shell 和完全控制权。

我们预计攻击者和研究人员将使用此特定漏洞开发多种其他漏洞利用链。

概念验证代码

安全社区已经开发了许多不同的测试，攻击者可能会在未来针对系统的攻击中利用这些测试。下面列出的 POC 旨在帮助安全研究人员识别系统是否受到该漏洞的影响，此外 - 测试检测策略。

查找易受脏管道攻击的系统

除了使用传统的漏洞扫描程序外，还有几种方法可以检测易受脏管道攻击的系统。

使用 Elastic Security 集成

如果您有 Auditbeat、Filebeat（启用 Auditd 模块）或 Elastic Agent（部署了 Security 或 Auditd 集成），您可以使用 Lens 可视化工具（位于 Kibana 中）来快速编译并保存易受攻击的系统列表，如下面的屏幕截图所示

使用 Osquery Manager 集成

此外，您可以使用 Osquery Manager 集成从所有端点收集内核信息。为此，您需要将 Osquery Manager 集成添加到 Elastic Agent 策略（集成 → Osquery Manager → 添加 Osquery Manager）。添加集成后，您可以执行一个简单的查询：SELECT version FROM kernel_info; 这将返回具有策略的所有端点的主机名和 Linux 内核版本。

使用 Auditd 检测 CVE-2022-0847 漏洞利用

Auditd 是 Linux 审核系统的用户空间组件。Auditd 代表 Audit Daemon，是一个在后台运行的服务，负责收集日志文件并将其写入磁盘。Linux 审核系统包括一个内核组件，该组件会挂钩系统调用并将这些调用通信到 Auditd。Auditd 能够记录系统调用、文件访问和某些预配置的审核事件。您可以使用您选择的 Linux 发行版上的软件包管理器免费安装和启用 Auditd。

Auditd 规则

Auditd 规则定义要捕获和记录的内容。这些规则通常在 audit.rules 文件中定义，并放置在 /etc/audit/audit.rules 或 /etc/audit/rules.d/audit.rules 中。事件会写入本地系统上的 /var/log/audit/audit.log。

一旦您安装并启用了 Auditd，您可以将以下行添加到您的 audit.rules 文件中，以检测 Dirty Pipe 漏洞的利用尝试。

Dirty Pipe Auditd rules

-a always,exit -F arch=b64 -S splice -F a0=0x3 -F a2=0x5 -F a3=0x0 -F key=dirtypipe
-a always,exit -F arch=b64 -S splice -F a0=0x6 -F a2=0x8 -F a3=0x0 -F key=dirtypipe
-a always,exit -F arch=b64 -S splice -F a0=0x7 -F a2=0x9 -F a3=0x0 -F key=dirtypipe

上述规则由 Elastic Security 根据 Jonas LeJon 的初步发现进行改编。

使用 Elastic 收集 Linux 审计系统事件

使用 Elastic 收集 Linux 审计系统事件有几种不同的方法。 您可以使用带有 Auditd 集成的 Elastic Agent、Auditbeat 或 Filebeat 的 Auditd 模块。

请记住，如果您正在使用 Elastic Agent 或 Filebeat 的 Auditd 集成，则需要创建上述的 Auditd 规则。

带有 Auditd 集成的 Elastic Agent

带有Auditd 集成的 Elastic Agent 允许收集 Auditd 规则。 要收集这些事件，您需要将 Auditd 集成添加到 Elastic Agent 策略中（集成 → Auditd → 添加 Auditd）。

一旦将此集成安装到 Elastic Agent 策略并部署到端点，您将在 Kibana 中看到填充的 Auditd 事件。

您可以通过使用 Kibana 查询 event.dataset : "auditd.log" 来验证您是否正在 Kibana 中接收 Auditd 事件。

Auditbeat

您可以使用Auditbeat Auditd 模块来收集 Linux 审计框架日志。 为此，请安装 Auditbeat。 如果除了 Auditbeat 之外的另一个进程（例如 Auditd）注册为从 Linux 审计框架接收数据，您可能会遇到错误。 为了防止此冲突，您可以停止并禁用 Auditd 运行。

Stopping and disabling Auditd

sudo service auditd.service stop
sudo chkconfig auditd.service off

编辑 /etc/auditbeat/auditbeat.yml 文件以指向您的本地、远程或云集群，并在 Auditd 规则部分中添加上面提供的 Dirty Pipe 规则。

Adding Dirty Pipe detection rules to the Auditbeat configuration file

# ===== Modules configuration =====

auditbeat.modules:

* module: auditd

# Load audit rules from separate files. Same format as audit.rules(7)

  audit_rule_files: [ '${path.config}/audit.rules.d/*.conf' ]
  audit_rules: |

## Define audit rules here

## Create file watches (-w) or syscall audits (-a or -A). Uncomment these

## examples or add your own rules

    -a always,exit -F arch=b64 -S splice -F a0=0x3 -F a2=0x5 -F a3=0x0 -F key=dirtypipe
    -a always,exit -F arch=b64 -S splice -F a0=0x6 -F a2=0x8 -F a3=0x0 -F key=dirtypipe
    -a always,exit -F arch=b64 -S splice -F a0=0x7 -F a2=0x9 -F a3=0x0 -F key=dirtypipe

…truncated…

使用测试命令检查 Auditbeat 的配置和连接性。

Testing the Auditbeat configuration and output settings

sudo auditbeat test config
sudo auditbeat test output

使用 sudo auditbeat setup 运行 Auditbeat 设置命令。

使用 sudo systemctl start auditbeat.service 启动 Auditbeat。

现在您应该能够验证事件是否已填充到 Kibana 中的 auditbeat-* 数据视图中。

Filebeat

您也可以使用 Filebeat 的 Auditd 模块来收集 Auditd 日志。 为此，请安装 Filebeat，然后启用 Auditd 模块

sudo filebeat modules enable auditd

接下来，进入 Auditd 配置文件并启用日志收集、测试、设置，然后启动 Filebeat。

Enabling Auditd log in the Filebeat configuration file

sudo vi /etc/filebeat/modules.d/auditd.yml

# Module: auditd

# Docs: <https://elastic.ac.cn/guide/en/beats/filebeat/master/filebeat-module-auditd.html>

* module: auditd
  log:
    enabled: true

# Set custom paths for the log files. If left empty

# Filebeat will choose the paths depending on your OS

    #var.paths:
Testing the Filebeat configuration and output settings

sudo filebeat test config
sudo filebeat test output

使用 sudo filebeat setup 运行 Filebeat 设置命令。

使用 sudo systemctl start filebeat.service 启动 Filebeat。

使用 Elastic 检测 Dirty Pipe

现在 Linux 审计框架事件正在由 Elastic Agent、Auditbeat 或 Filebeat 填充，您可以在 Discover 中使用 Kibana 查询语言 (KQL) 或在 Kibana 的 Security → Timelines → New Timeline → Correlation query editor 中使用端点查询语言 (EQL) 来运行查询以检测利用尝试。

Kibana 中的搜索查询

与使用 Elastic Agent、Auditbeat 或 Filebeat 兼容的 KQL 查询

KQL query to detect Dirty Pipe exploitation attempts

auditd.log.key : dirtypipe and process.name : *

与使用 Auditbeat 兼容的 EQL 查询

EQL query to detect Dirty Pipe exploitation attempts

process where tags : "dirtypipe" and not process.name : ""

检测引擎警报

您还可以创建一个检测引擎警报来监控利用尝试。

利用尝试将记录在 Kibana 安全解决方案的“警报”部分中。

对观察到的威胁做出响应

Elastic 使您可以轻松地通过隔离主机来快速响应威胁，同时仍然允许其与您的堆栈通信，以便继续监视采取的操作和/或修复威胁。

深度防御建议

可以利用以下步骤来改善网络的防护姿态

  1. 审查并确保您已为您的操作系统部署了最新的稳定和供应商提供的内核
  2. 使用帖子中描述的技术在您的环境中审查并实施上述检测逻辑
  3. 维护关键系统的备份以帮助快速恢复

参考

本文档中引用了以下研究

分享这篇文章

TwitterFacebookLinkedInReddit