Subverting the Linux Kernel Linux Kernel Rootkits 101

Transcription

1 Subverting the Linux Kernel Linux Kernel Rootkits 101

2 Kernel Rootkits? A collection of program(s) that hide an attacker's presence and activities on a compromised system Typically allows an attacker to keep privileged access and stay unnoticed Common rootkit activities: Hide files, processes, network connections Filter logfiles Main idea: manipulate the administrator's view of the system Most often distributed in the form of a Loadable Kernel Module (LKM) There are other methods that avoid using LKMs (code injection via and )

3 Common Attack Vectors 2 Syscalls via 3 Includes modern are deprecated, although still supported for ancient 32-bit programs instruction on x86_64, SYSENTER used for 32-bit programs Diagram from Rootkits - Detection and Prevention, de Almeida, Andre Jorge Marques

4 Common Attack Vectors We'll take a closer look at in the context of modern 4.x kernels Diagram from Rootkits - Detection and Prevention, de Almeida, Andre Jorge Marques

5 Common Approaches infection Example: Knark, 1999 Function hooking/trampolines Example: Suterusu (concept rootkit), 2013 Syscall handler infection Example: SucKIT, 2001

6 More Approaches VFS layer interception (Example: Adore-ng) avoids tampering with and other central structures Code injection via: (Example: SucKIT, 2001) (Example: Phalanx and Phalanx2, ~2005)

7 Implementation Many of these approaches documented in literature dating back to early-mid 2000s... How do these approaches stack up against a modern Linux kernel today? (We'll be looking at x86_64 specifically)

8 Method #1: sys_call_table infection

9 Method #1: sys_call_table infection Most traditional and commonly cited method But easily detected, by checking the integrity of the syscall table of the running kernel The main obstacle is locating Pre-2.6 Linux kernel: was exported and not write-protected! This fact was exploited by the Knark rootkit (1999) based on Linux 2.2/2.4 Very trivial to modify the system call table back then on x86 wasn't marked read-only until , in 2006 commits

10 Method #1: sys_call_table infection Methods of locating spotted in the wild: Looking up in System.map file commonly located in [1] Mitigation: Some arches support kernel address space randomization (KASLR), introduced on x86 with 3.14 (2014) System.map addresses won't match up with the running kernel Mitigation: Alternatively, just remove the file

11 Method #1: sys_call_table infection Methods of locating spotted in the wild: Looking up in [2] Mitigation: CONFIG_KALLSYMS_ALL=n, which excludes data/non-text symbols Also prevents malicious kernel modules from abusing the using kallsyms API to lookup sys_call_table and other structures (e.g. in the VFS layer) in data sections

12 Method #1: sys_call_table infection Methods of locating spotted in the wild: Brute force search of kernel memory Find using addresses of exported syscalls (notably, sys_close) [3] (Example: Intoxonia [4]) Source: "Modern Linux Rootkits 101" by Tyler Borland Mitigation: reduce or eliminate exported syscalls Looks like some drivers still depend on sys_close

13 Method #1: sys_call_table infection Other methods of locating spotted in the wild: Scanning the arch-specific syscall handler for the address Main idea: We know that the syscall handler issues calls through, so a rootkit can scan the handler for the syscall table address

14 Method #1: sys_call_table infection Scanning the arch-specific syscall handler for the address First, we need the address of the syscall handler Older rootkits used INT 0x80 way: scan Interrupt Descriptor Table Modern x86 systems use Model-Specific Registers (MSRs) to store handlers for instructions: LSTAR - the kernel's syscall entry for 64-bit programs CSTAR - the kernel's syscall entry in 32-bit compatibility mode On x86_64, the syscall handler is called formerly named ( )

15 Method #1: sys_call_table infection Scanning the arch-specific syscall handler for the address First, we need the address of the syscall handler Model Specific Register LSTAR contains the syscall handler on x86_64 Its address can be read out with instruction (wrapped as a macro in the kernel): Must be executed with privilege level 0 (kernel mode) Thus, kernel modules can execute these instructions

16 Method #1: sys_call_table infection Scanning the arch-specific syscall handler for the address Once we have the address of the syscall handler... Scan byte-by-byte for call instr beginning with ", which is a byte sequence unique in the handler and locatable within the first 256 bytes This gives us a 32-bit absolute offset, use this to calculate the address of

17 Method #1: sys_call_table infection Scanning the arch-specific syscall handler for the address Once we have the address of... Need to modify the table, but it is in read-only memory We can write to control registers in kernel mode Specifically, we want to write to CR0 Contains control flags that modify the basic operation of the CPU Bit 16 of CR0 is the write-protect bit When CR0.WP = 1, CPU can't write to RO pages when privilege level is 0 Reads and writes to CR0 can only be done in kernel mode Thus, an LKM can clear the write-protect bit in CR0 Then sys_call_table can be modified and its pointers replaced with pointers to malicious functions

18 Method #1: sys_call_table infection Demo

19 Method #2: syscall handler infection

20 Method #2: syscall handler infection Alternative: instead of modifying sys_call_table directly, a rootkit can make a copy of the syscall table and modify that instead Patch the syscall handler to issue syscalls through the rootkit's copy of the syscall table Similar to function trampoline method (or any text patching method) (Example: Suterusu) These methods are not SMP safe commonly used to copy instructions to perform function redirection (e.g., with a )

21 Detecting sys_call_table and handler modifications Use crash or gdb coupled with /proc/kcore to inspect memory of running kernel Requires access to unstripped vmlinux file Inspect contents of Check if addresses in the table match up to real syscall Check if addresses in the table point to module region >= MODULE_VADDR On x86_64: See Documentation/x86/x86_64/mm.txt Disassemble syscall handlers and inspect sys_call_table callsite Check that the table used corresponds to the real sys_call_table

22 Detecting sys_call_table and handler modifications Demo

23 Method #3: VFS layer interception

24 Method #3: VFS layer interception VFS is an abstraction layer that serves as the entry point for many filesystem operations and fs-related syscalls VFS-based rootkits target this layer instead of a central structure like the syscall table Example: Adore-ng (2004) manipulated procfs-related filesystem operations replaces /proc's readdir (now called iterate_shared) handler to hide certain PIDs since programs like ps and top read from /proc, these pids would not show up in output VFS is very object-oriented - contains many structs with function pointers These point to functions that implement file system operations such as open, read, write, etc. A rootkit can replace these pointers to point to malicious versions of these handlers

25 Method #3: VFS layer interception Demo

26 Detecting VFS layer infections Use crash or gdb coupled with to inspect memory of running kernel gdb doesn't handle KASLR well - but crash can! Infections are more cumbersome to detect, since this method does not manipulate central resources like the syscall table Would require checking the integrity of numerous structs General idea is to validate function pointer addresses Check if addresses in the table match up to real handlers

27 Detecting VFS layer infections Demo

28 Other Methods: /dev/mem & /dev/kmem - device file that provides access to kernel virtual memory Many distributions have turned off this device file - device file that provides access to physical memory Distributions still provide access to (as root, and up to 1MB with CONFIG_STRICT_DEVMEM)

29 Other Methods: /dev/mem & /dev/kmem Typical Approach Obtain address of syscall handler via the IDT (deprecated int 0x80 way) or reading (as root) from (new syscall/sysenter way) Scan syscall handler for the sys_call_table address Overwrite entries in to via For /dev/mem, rootkit author must do virt-to-phys addr calculations How to insert rootkit code into kernel memory? One method used by SucKIT place address of kmalloc into syscall table (either overwriting existing or finding an unused entry) kmalloc() is then executed as a syscall and kernel memory is allocated rootkit code is then written to this region address of the rootkit is then written to the syscall table, replacing kmalloc

30 Other Methods: /dev/mem & /dev/kmem Real-life example: kernel.org breach in 2011 Phalanx rootkit (plus a trojan) installed on Linux Foundation servers Phalanx/Phalanx2 both utilize to inject malicious code Phalanx2 was able to bypass restrictions (introduced in 2008) Used helper kernel modules to overwrite (which checks if access is below 1MB) to always return 1, thus granting full RW access to After performing this task, helper module's init function would return an error, so the module is never actually loaded With full access to, Phalanx is able to overwrite, perform function hooking, etc

31 Other Methods: /dev/mem A new config option CONFIG_DEVMEM introduced in 2015 makes an optional device One could disable this option to close off this attack vector Is still used today? Originally cited reason for keeping X window system uses it to access video memory But with the advent of rootless X and kernel mode setting, access may not be as relevant anymore DOSEMU is another application that uses

32 Detection and Prevention Detection: "Fingerprinting" important areas of the kernel first bytes of syscalls (detect function trampolines) system call handler (e.g. entry_syscall_64) addresses in MSRs (e.g., LSTAR for x86_64, IA32_SYSENTER_EIP for x86_32 or IA32 emulation) important function pointers in the fs layer (e.g., file_operations structs in procfs) Prevention: Disabling kernel modules (at cost of flexibility) Enforcing cryptographically signed modules (CONFIG_MODULE_SIG && CONFIG_MODULE_SIG_FORCE) (available since 3.7 (2012)) Disable CONFIG_DEVKMEM (made configurable in ) Disable CONFIG_DEVMEM (made configurable in commit 73f0718e74e (2015))

33 Questions, corrections, comments?