How does eBPF Malware perform against Star Lab’s Kevlar Embedded Security?
Those crafty hackers. Not surprisingly, every time the design of an operating system is improved someone demonstrates how the design can also be abused. The inclusion of the Berkley Packet Filter (BPF) technology is an example of one such improvement. In this blog, not only will we highlight some of the malware used to abuse the BPF facility, we will describe our experiment to employ it against systems that are protected by Kevlar Embedded Security to answer the question – how will an eBPF malware attack fair against a system protected by Kevlar Embedded Security?
BPF was added to the Linux kernel in 2012 and enables a variety of dynamic execution techniques. It is powerful, and useful, yet also has a dangerous side. There are many resources available that describe BPF, its benefits, and its dangers, in more detail than this blog. Although for context, this blog will introduce BPF and describe what it can be used for, at least maliciously. BPF is a facility that runs within kernel context and as such, any malware introduced through BPF runs within that kernel context.
BPF is a type of programming language [1]. There are two dialects: cBPF for “classic” (restricted to observing network packets) and extended-BPF (eBPF), which has access to most kernel facilities. The Linux kernel supports eBPF as a kernel probe hook that can be invoked through any kernel tracepoint. This implies that eBPF programs can be attached to nearly all kernel function entries/exits, system calls, network events, and kernel probes.
Much like traditional rootkits and malware, it has been shown that eBPF can be used by malicious programs to hijack a system and perform unintended tasks. Malicious eBPF programs have been able to elevate privileges [2], create unintended writes to system files (e.g., sudoers) [3], block actions designed to detect and mitigate intrusion attempts [4], and create and maintain stealth communication sessions [5]. Taking these techniques a step further, APT groups such as Red Menshen have used these BPF-techniques to extend their stealth, persistence, and access in the Middle East.
How does Kevlar Embedded Security protect against eBPF malware?
Star Lab’s Kevlar Embedded Security is a Yocto-based solution that counters IP theft through advanced security to mitigate a wide variety of threats against embedded Linux systems. Kevlar Embedded Security provides a collection of security layers that contribute to a defense-in-depth approach. For the purposes of identifying which Kevlar Embedded Security components protect against various eBPF malware, a single Kevlar Embedded Security feature was enabled at a time. The Kevlar Embedded Security Features that work to prevent the introduction of eBPF malware are:
Kernel Hardening: Linux kernel build-time and run-time configuration parameters that effect the security of a deployed system.
Allowlisting: Application and Library executable enforcement.
As a control in this experiment of eBPF malware vs. Kevlar Embedded Security, the malware was installed on default installations of Ubuntu 5.4, Yocto - Poky, and WRLinux LTS22.
Experiment Methodology
Described below are the results of testing the eBPF malware against the control installations as well as the two instances built with Kevlar Embedded Security. In each case, the malware was able to run without issue on each of the control installations. For that reason, the description below highlights only the impact of Kevlar Embedded Security on the malware.
Pidhide
eBPF malware that hides the pid from tools such as ps.
Attempting to load pidhide with Kevlar Embedded Security Kernel Hardening causes it to fail with:
call bpf_probe_write_user#36
unknown func bpf_probe_write_user#36 Digging into these failures, we can see some of the kernel configurations enabled by Kevlar Embedded Security Kernel Hardening include:
CONFIG_SECURITY_LOCKDOWN_LSM=y
CONFIG_LOCK_DOWN_KERNEL_FORCE_INTEGRITY=y CONFIG_SECURITY_LOCKDOWN_LSM_EARLY=y CONFIG_LOCK_DOWN_KERNEL_FORCE_INTEGRITY in turn forces the configuration option: LOCKDOWN_INTEGRITY_MAX.
When the kernel is configured with LOCKDOWN_INTEGRITY_MAX, LOCKDOWN_BPF_WRITE_USER is disabled, and lastly, when LOCKDOWN_BPF_WRITE_USER is disabled, the bpf_probe_write_user call is hidden. This causes the verifier to fail with unknown func and for the malware load to be blocked.
Textreplace
This eBPF program makes it appear that all instances of some text string in a file are different (i.e. it can replace stream text). One such use case for the text replace would be to dynamically replace the MAC address.
Attempting to load textreplace with Kevlar Embedded Security Kernel Hardening causes it to fail in the same way as pidhide.
Writeblocker
This eBPF program intercepts write syscalls for a given PID and will fake those write calls. For instance, if there were a need to hide the login process through ssh, this could be accomplished by blocking writes from the rsyslog daemon.
Kevlar Embedded Security Kernel Hardening also prevents writeblocker from executing, although for slightly different reasons.
__x64_sys_write() is not modifiable The write Syscall is only enabled if the kernel is configured with:
CONFIG_HAVE_FUNCTION_ERROR_INJECTION CONFIG_KPROBES BPFDoor
This is a passive Linux backdoor which hides persistent remote access to compromised environments. It is difficult to detect when running on a target system. Upon launch, it is configured to ignore various signals to prevent it from being terminated. It then hooks in a packet sniffer that monitors for incoming traffic looking for a magic pattern that will identify it as a message from the malware operator. The magic message is then used to fork off a child that will open an encrypted reverse shell Command & Control channel to the malware’s home.
BPFDoor is essentially a client server malware. It installs and executes programs from /dev/shm.
Unlike the previous malware samples, to prevent BPFDoor, Kevlar Embedded Security’s Allowlisting functionality is required.
Allowlisting disallows executable files in /dev/shm (and any other temporary filesystem). Adding executables to /dev/shm is a standard approach of malware - rarely is there a legitimate reason to execute out of /dev/shm.
Was the eBPF malware successful?
Kevlar Embedded Security prevents the introduction and execution of various eBPF-based malware samples. A summary of the ability to execute this collection of malware under various platforms is summarized below:
As can be seen from the results table, all four of our malware programs run on Ubuntu, Yocto Poky, and WRLinux. The Yocto Poky and WRLinux environments had BPF specifically enabled in their kernel configurations. Kevlar Embedded Security’s Kernel Hardening blocked three of the malware programs while Allowlisting blocked one of the malware programs. In combination, Kevlar Embedded Security protected the system from all the malware samples.
Learn more about how Kevlar Embedded Security can harden your specialized embedded system to prevent attacks. Let’s start a conversation!
Want to read more? Check out some of our latest blogs!
