BPF Memory Forensics with Volatility 3
BPF Memory Forensics with Volatility 3
Introduction and Motivation
Have you ever wondered how an eBPF rootkit looks like? Well, here’s one, have a good look:
Upon receiving a command and control (C2) request, this specimen can execute arbitrary commands on the infected machine, exfiltrate sensitive files, perform passive and active network discovery scans (like nmap
), or provide a privilege escalation backdoor to a local shell. Of course, it’s also trying its best to hide itself from system administrators hunting it with different command line tools such as ps
, lsof
, tcpdump
an others or even try tools like rkhunter
or chkrootkit
.
Exploration of the Dirty Pipe Vulnerability (CVE-2022-0847)
Intro
This blog post reflects our exploration of the Dirty Pipe Vulnerability in the Linux kernel. The bug was discovered by Max Kellermann and described here . If you haven’t read the original publication yet, we’d suggest that you read it first (maybe also twice ;)). While Kellermann’s post is a great resource that contains all the relevant information to understand the bug, it assumes some familiarity with the Linux kernel. To fully understand what’s going on we’d like to shed some light on specific kernel internals. The aim of this post is to share our knowledge and to provide a resource for other interested individuals. The idea of this post is as follows: We take a small proof-of-concept (PoC) program and divide it into several stages. Each stage issues a system call (or syscall for short), and we will look inside the kernel to understand which actions and state changes occur in response to those calls. For this we use both, the kernel source code (elixir.bootlin.com , version 5.17.9) and a kernel debugging setup (derived from linux-kernel-debugging ). The Dirty Pipe-specific debugging setup and the PoC code is provided in a GitHub repository.
Exploiting CVE-2021-43247
In this blog post I will go in depth into the inner workings of CVE-2021-43247
, which was fixed on the 14th of December 2021.
This bug was classified as “Windows TCP/IP Driver Elevation of Privilege Vulnerability”.
The vulnerability itself was probably dormant for a long time, but became exploitable when the AF_UNIX
address family
was first introduced in 2019.
I will also take this as an excuse to explain in detail, what drivers are, how user space communicates with drivers, what a Local Privilege Escalation (LPE) is and what how we can achieve it in this case.