Encrypted Linux x86-64 Loadable Kernel Modules

(ELKM)
cenobyte
[email protected]
https://github.com/cenobyte-vincit/encrypted-linux-kernel-modules

Abstract—In this paper, we present ELKM, a Linux tool that • Auto-decrypt: the password is derived from the main-
provides a mechanism to securely transport and load encrypted board product UUID or the EC2 instance ID. In auto-
Loadable Kernel Modules (LKM). The aim is to protect kernel- decryption deployments a dropper could send the kernel
based rootkits and implants against observation by Endpoint
Detection and Response (EDR) software and to neutralize the version and product UUID or instance ID via a C2 chan-
effects of recovery by disk forensics tooling. nel to a staging environment. The staging environment
builds the rootkit for the target kernel version, and then
I. I NTRODUCTION encrypts and fuses the payload to the loader. The dropper
would then be able to fetch the staged loader and install
For attackers, the proliferation of Linux EDR software that it in an appropriate place on the host for persistence.
record execv*() calls make the risk of getting detected more • Manual decryption: the password is provided via an
substantial. Observable post-exploitation activity such as the environment variable or stdin.
execution of insmod to load a rootkit on a Linux host will This approach makes the deployment of ELKM-
undoubtedly catch the interest of security operations analysts protected LKMs reasonably resilient against detection
hunting for threats. by EDR software and disk forensics tooling.
In addition, there is a considerable risk of keeping LKM
rootkits on the disks of compromised hosts. Rootkits need Note: Memory dumps and forensics is evidently a concern
to be persistent across reboots and, on virtual machines and on virtual machines and cloud instances (such as Amazon
cloud instances it is not possible to achieve persistence through EC2 [1]), but this is not necessarily the case for physical
backdooring UEFI or the BIOS. Disk snapshot facilities machines. The memory dump threat for attackers is outside
provided by hypervisors and IaaS cloud service providers of the scope of this paper and ELKM.
makes it trivial for adversaries to quickly and inconspicuously
make a copy of a disk and recover LKMs that reside on the III. L OADER
disk its filesystems. This risk is not only limited to virtual
machines and cloud instances, as disks of physical machines The ELKM loader is a 64-bit shared object. By inserting the
can be easily imaged on the fly with dd, or offline using law loader using the dynamic linker and LD_PRELOAD on trusted
enforcement-specific disk imaging tooling. executables such as systemd, crond etc. the loader can be
Threat intelligence firms receive a continuous stream of trivially hidden from EDR software. For instance, the Carbon
recovered artifacts from cyberattacks and while those firms Black Cloud Enterprise EDR Linux sensor [3] appears to
are typically not that well versed in attribution, they are quite only record execution arguments, and threat hunters inspecting
capable of analyzing these artifacts correctly. The challenge for telemetry will not be able to see environment variables of
attackers is to keep rootkits on the systems they were deployed executed programs. To overtake the execution of a target
on and to make forensics and reverse engineering as difficult program the loader utilizes __libc_start_main() [4]
as possible. which is a C library function that is called prior to the main()
function.
II. ELKM During execution, the loader scans the value of
LD_PRELOAD to obtain its path and then calculates the
The core of ELKM is the fusing of an encrypted LKM size of its ELF image to find the offset of the fused payload.
payload to an Executable and Linking Format [2] (ELF) shared Utilizing memfd_create() it then creates a memory
object, the ‘loader’. The loader decrypts the payload during file descriptor, starts decrypting the payload, and writes
runtime, and subsequently inserts the decrypted LKM into the decrypted bytes to the memory file descriptor. After
the kernel without invoking insmod. As a shared object, the successfully decrypting the payload in memory the next
loader is able to hide from execution monitoring by inserting step is to load the LKM image into the kernel by using the
itself in dynamically linked operating system executables that finit_module() syscall. The finit_module() syscall
are considered trusted. reads the LKM image from the memory file descriptor and
ELKM supports two decryption modes: loads it accordingly.
A. Size and offset of the payload in the loader binary
The loader obtains the size and offset of the payload by
reading its ELF64 [5] header. The ELF64 header structure
(Fig. 1) is located at the beginning of the loader binary and is
obtained using pread64() [6].

Fig. 2. Fused loader binary overview

D. Decryption password
Fig. 1. Elf64 Ehdr
Four methods to obtain a valid decryption password are
There are 3 elements of interest in the ELF header related executed in sequence:
to the ELF section header: • Product UUID: x86-64 Mainboards should have a
• e_shentsize: Holds the size of the section header’s manufacturer-assigned product Universally Unique Iden-
entry in bytes, all section header entries are the same size. tifier (UUID) [12]. The product UUID is a unique 128-
• e_shnum: Holds the number of section header entries in bit integer and its format is described in RFC4122
the section header table. [13]. On Linux the product UUID can be obtained
• e_shoff: Holds the byte offset from the beginning of from /sys/class/dmi/id/product_uuid. The
the binary to the section header table. encrypted LKM can be tied to a specific host using
The product of e_shentsize and e_shnum gives the the product UUID, and the loader will be able to auto-
section header table’s size. The sum of the section header table decrypt itself when executed on the right host. In case
size and e_shoff gives the exact size of the loader ELF /sys/class/dmi/id/product_uuid doesn’t ex-
image. The payload size is calculated by subtracting the ELF ist, or the product UUID isn’t the password, the loader
image size from the size of the loader binary. will continue to check if the host is an EC2 instance.
• EC2 instance ID: If the host runs on Amazon EC2
B. Cryptography then the Instance Metadata Service [15] is queried
to obtain the instance ID [16]. This is consid-
The cryptographic component of ELKM is provided by ered one of the lesser secure options since the in-
OpenSSL, and it uses the Advanced Encryption Standard stance ID consists of a 2-character i- header, and a
(AES) [7] cipher algorithm in Cipher Block Chaining (CBC) 17-character lowercase alphanumeric combination, e.g.
[8] mode. A 256-bit key is set, and an 8-byte crypto- i-1234567890abcdef0. If the host is not an EC2
graphically strong pseudo-random salt is generated with the instance, or if the instance ID is not the password, the
RAND_bytes() [9] function. The EVP_BytesToKey() loader will try scanning the environment next.
[10] function is used to derive the key and initialization vector • Environment variable: The loader will use the first
(IV), and 10,000 iterations of the SHA-512 [11] hashing environment variable that has been set by leveraging
algorithm are applied to help protect against brute force glibc’s non-POSIX envp [14] which is a list of all the
attacks. environment variables that are passed as the environment
of the target program. If the password is set in an
C. ELKM Payload fuser
environment variable other than the first environment
ELKM comes with payloadfuser that encrypts an variable, the loader will not be able to decrypt and will
LKM, generates the payload, and fuses it to the ELKM loader. fall back to the last decryption option.
The resulting payload consists of two parts: the 8-byte salt and • Standard input: Interactive, which may be used post-
the ciphertext. The fused loader binary can be seen in Fig. 2. exploitation.
 IV. P ROTECTIONS
The ELKM loader comes with two basic protection mech-
anisms:
• It sets the core dump size to 0 to prevent the password
from ending up in a core dump if the loader happens to
terminate unexpectedly.
• It ptraces itself to prevent debuggers from attaching after
a successful environment or interactive decrypt.
F UTURE WORK AND IMPROVEMENTS
• Separate the loader ELF logic from the decryption logic
to make it possible for a dropper to load encrypted LKMs
over the network.
• The ability to tie a LKM to a single system and ask for an
additional password, utilizing Cascading Multiple Block
Algorithms.
• Introduce ARM and x86 support.
• Support for RHEL/CentOS 8 and Amazon Linux.
ACKNOWLEDGMENT
Thank you Fionn F for your review and the inspiration for
writing ELKM.
R EFERENCES
[1] https://docs.aws.amazon.com/AWSEC2/latest/APIReference/API
SendDiagnosticInterrupt.html
[2] https://man7.org/linux/man-pages/man5/elf.5.html
[3] https://www.carbonblack.com/blog/carbon-black-cloud-adds-linux-support-for-enterprise-edr/
[4] https://refspecs.linuxfoundation.org/LSB 3.1.0/LSB-Core-generic/
LSB-Core-generic/baselib---libc-start-main-.html
[5] https://refspecs.linuxfoundation.org/elf/gabi4+/ch4.eheader.html
[6] https://refspecs.linuxfoundation.org/LSB 5.0.0/LSB-Core-generic/
LSB-Core-generic/baselib-pread64.html
[7] https://nvlpubs.nist.gov/nistpubs/FIPS/NIST.FIPS.197.pdf
[8] https://nvlpubs.nist.gov/nistpubs/Legacy/SP/
nistspecialpublication800-38a.pdf
[9] https://www.openssl.org/docs/man1.0.2/man3/RAND bytes.html
[10] https://www.openssl.org/docs/man1.0.2/man3/EVP BytesToKey.html
[11] https://nvlpubs.nist.gov/nistpubs/FIPS/NIST.FIPS.180-4.pdf
[12] https://www.dmtf.org/sites/default/files/standards/documents/DSP0134
3.0.0.pdf
[13] https://tools.ietf.org/html/rfc4122
[14] https://www.gnu.org/software/libc/manual/html node/
Program-Arguments.html
[15] https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/
ec2-instance-metadata.html
[16] https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/resource-ids.
html