From abcc84f6bb2072874255d9a0c897f89c09ee2a91 Mon Sep 17 00:00:00 2001 From: h3xduck Date: Sat, 2 Jul 2022 19:06:05 -0400 Subject: [PATCH] Minor changes to library injection explanation --- README.md | 28 ++++++++++++++++++---------- 1 file changed, 18 insertions(+), 10 deletions(-) diff --git a/README.md b/README.md index 09ecd54..e9fdfb0 100644 --- a/README.md +++ b/README.md @@ -104,7 +104,7 @@ These scripts must first be configurated with the following parameters for the p | src/helpers/deployer.sh | SUDO_PERSIST | Sudo entry to grant password-less privileges | ## Library injection module -The rootkit can hijack the execution of processes that call the *sys_timerfd_settime* or *sys_openat* system calls. This is done by overwriting the Global Offset Table (GOT) section of the process making the call. This leads to a malicious library (*src/helpers/injection_lib.c*) being executed. The library will spawn a simple reverse shell to which the attacker machine can be listening, and then returns the flow of execution to the original function without crashing the process. +The rootkit can hijack the execution of processes that call the *sys_timerfd_settime* or *sys_openat* system calls. This is achieved by overwriting the Global Offset Table (GOT) section at the virtual memory of the process making the call. This leads to a malicious library (*src/helpers/injection_lib.c*) being executed. The library will spawn a reverse shell to which the attacker machine can be listening, and then returns the flow of execution to the original function without crashing the process. TripleCross is prepared to bypass common ELF hardening techniques, including: * ASLR @@ -134,20 +134,27 @@ nc -nlvp The technique incorporated in TripleCross consists of 5 stages: #### Locating GOT and the return address -Two techniques for achieving this have been incorporated: -* With sys_timerfd_settime, the eBPF program scans forward in the scan using the syscall arguments. -* With sys_openat, the eBPF program scans uses the data at tracepoints' *pt_regs* struct for scanning the return address. - +The rootkit hooks the system call using a tracepoint program. From there, it locates the address at the GOT section which the PLT stub used to make the call to the glibc function responsible of the syscall. -Note that: -* The .text makes a *call* to the .plt, so *rip* is saved as *ret*. +In order to reach the GOT section, the eBPF program uses the return address stored at the stack. Note that: +* The .text makes a *call* to the .plt, so *rip* is saved as *ret* in the stack. * The .plt makes a *jump* to glibc using .got, so no other *rip* is saved. It also does not modify or save the value of *rbp*. * Glibc makes a *syscall*, which does not save *rip* in the stack, but rather saves it in *rcx*. -Therefore in order to check from eBPF that an address in the stack is the return address we are looking for, we must check that it is the return address of the .plt stub that uses the .got address that jumps to the glibc function making the system call we hooked from eBPF. + + +Therefore in order to check from eBPF that an address in the stack is the return address that will lead us to the correct GOT, we must check that it is the return address of the PLT stub that uses the GOT address that jumps to the glibc function making the system call we hooked from eBPF. + +Two techniques for finding the return address have been incorporated: +* With sys_timerfd_settime, the eBPF program scans forward in the scan using the syscall arguments. +* With sys_openat, the eBPF program scans uses the data at tracepoints' *pt_regs* struct for scanning the return address. + + + #### Locating key functions for shellcode The shellcode must be generated dynamically to bypass ASLR and PIE, which change the address of functions such as dlopen() on each program execution. + @@ -158,6 +165,7 @@ A code cave can be found by reverse engineering an ELF if ASLR and PIE are off, #### Overwriting the GOT section Depending on whether Partial or Full RELRO are active on the executable, the eBPF program overwrites the GOT section directly or with the /proc filesystem. + #### Waiting for the next system call @@ -224,6 +232,7 @@ This shell is generated after a successful run of the execution hijacking module An encrypted pseudo-shell can be requested by the rootkit client at any time, consisting of a TLS connection between the rootkit and the rootkit client. Inside the encrypted connection, a transmission protocol is followed to communicate commands and information, similar to that in plaintext pseudo-shells. Spawning an encrypted pseudo-shell requires the backdoor to listen for triggers, which accepts either pattern-based triggers or both types of multi-packet trigger: + @@ -248,8 +257,7 @@ Although in principle an eBPF program cannot start the execution of a program by * Be transparent to the user space, that is, if we hijack the execution of a program so that another is run, the original program should be executed too with the least delay- -This module hijacks the sys_execve syscall, modifying its arguments so that a malicious -program (*src/helpers/execve_hijack.c*) is run instead. This modification is made in such a way that the malicious program can then execute the original program with the original arguments to avoid raising concerns in the user space. The following diagram summarizes the overall functionality: +This module hijacks the sys_execve syscall, modifying its arguments so that a malicious program (*src/helpers/execve_hijack.c*) is run instead. This modification is made in such a way that the malicious program can then execute the original program with the original arguments to avoid raising concerns in the user space. The following diagram summarizes the overall functionality: