Persistent Data-only Malware:

Persistent Data-only Malware: Function Hooks without Code Presented by Ben Summers for CSCI 780

Outline • Introduction • Resident Malware • Persistent Malware • Data-only Malware • Background • Protection Mechanisms • ROP (Return-Oriented Programming) • Data-only Malware • Hardware Mechanisms of ROP • Software Mechanisms of ROP • POC and Discussion • Summary

Resident Malware https://c1.staticflickr.com/3/2245/2077361447_2d2ee0e834.jpg • “Any malware that has the ability to continue to achieve its objective without any human interaction despite a reboot or power cycle” • It “lives in” the target’s system autonomously. It actively subverts detection by executing and exploiting code on the system. • It distinguishes itself from Persistent Malware because resident malware operates using at least some code. • It’s the “mouse in the house.” While it may take some digging to get into the system, it can use inside or outside resources to achieve its goals and ensure its survivability.

Persistent and Non-persistent Malware • “Makes permanent changes in memory and permanently changes the control flow within a system such that it continue to achieve its objective.” • Persistent Malware is a hijacker. It replaces function pointers with a pointer to a malicious function, plugging in the data that was meant for the original function. • Once a persistent malware grabs ahold of a system, it is worried about keeping control. • Non-Persistent Malware is malware that makes permanent changes to the system but leaves the control flow intact. Does not permanently affect the control flow. http://www.nyrock.com/images/contop.jpg

Data-only Malware • “Introduces specially crafted data into the system with the intent on manipulating the control flow without changing or introducing new code.” • It is also a hijacker but the instruction pointer (IP) never points to any code introduced by the malware, unlike persistent malware. • Data-only Malware makes the computer work against itself. It uses the pre-existing software and libraries such as libc to achieve its goals. • It makes the computer “hit itself” with its own power and resources. http://blog.zennioptical.com/wp-content/uploads/2014/05/Zenni-71.jpg

Protection Mechanisms • Canary values stop overwrites as any buffer attach that overwrites the return values must overwrite the canary value, which is initialized with a random number – useless against Data-only malware • The Linux kernel loads external libraries to addresses beginning with ‘\0’ which is handled as a string terminator – can be useful against Data-only montage • Marks pages as writable or executable but never as both, which prevents an attacker from introducing new code – useless against Data-only malware • Loads specific code section in random offsets – hard counter to Data-only malware • Processor will not allow execution in code in user space while operating in kernel mode – useful against data-only malware • Checks digitally signed binaries before loading code – used for kernel protection and not that useful against Data-only malware.

Return-Oriented Programming (ROP) Diagram http://cs.ucla.edu/classes/fall10/cs111/scribe/15b/index_html_4c4ae2c6.png

ROP Sequences and Advantages • ROP can get around many protection mechanisms but needs a control structure that determines the execution order and the sequence must end with a ret (return) instruction. • The ROP redirects the pointer to execute sequences of instructions (gadgets) as each gadget ends with a ret instruction. • The stack pointer (SP) must initial point to a control structure which can be achieved by either copying the gadget chain into the stack or copy the ROP chain somewhere else and point the SP to that address. • Large code libraries such as libc can give the attacker many gadgets to build arbitrary functions.

Stack Pivot • Copy the ROP chain somewhere else in memory and point the SP the SP to the location. • This is usually very difficult as it is often only possible if the attacker has control of the register or can place a ROP chain near the SP so that it can be pointed to be modifying the offset. Thankfully, the predictable state of most machines make it so that it is easier to point to the ROP chain. • The eax command and commands to control the offset are often used to manipulate the SP. • The instruction sequence to modify the SP are not standard and must be adapted to the machine state.

Data-only Malware • Prerequisites: • Instructions – System must contain the instruction sequences that are required for the malware • Vulnerability – Requires a vulnerability within the victim’s system • Memory – The software contains the vulnerability must provide a mechanism to load the required control structure into memory • Control – The vulnerability must provide the attacker with control of the instructor pointer (IP) and enable them to activate the necessary control structure; Not every vulnerability will work. • Non-persistent Data-only Malware is the same except it DOES NOT permanently change the control flow of a system. Non-persistent malware cannot place hooks and thus cannot intercept events that occur within the host. It relies on an external entity to run.

Persistent Data-Only Malware • Two Stages to permanently altering control flow: • Initialization • Vulnerability is exploited and initialization control structure performs bootstrapping of malware. • Persistent stage • Implements the persistent functionality of the malware • Steps to persistent stage: find a memory location, protect against overwrite, resume control flow, and activating the control structure. • The stack is usually not best suited for the ROP chain but if it is small, it can fit.

Challenges to Persistent Malware • Most ROP stacks need to be located in a place outside the stack and must be stored in a memory location. This area must never be deallocated. • The data structure has to be protected against overwrites and have a predictable structure so that the malware executes correctly. Self-induced overwrites (Ex: address is pushed and some of the gadget used by call) and interrupt-induced overwrites, which are triggered by uncontrollable external events, are the main challenges of ROP success. Most interrupt-induced overwrites take place in the kernel space. • Have to guarantee that execution continues normally after the malware has run. Register or memory values must not be overwritten. • Switching sequence must fire to point to the ROP sequence.

Description of the ROP chain • Since the chain is stored in memory and not the stack, the first instruction sequence must modify the SP to point to the memory location where the ROP chain is stored. This is called “switching the stack.” • This is a requirement for persistent (which stay active) data-only malware. • Because the attack set the return address of a function to the ROP chain, the attacker controlled code will be executed. Since we know the return address of our changed function, we can determine what functions are executed before the overwritten return address is used. • Persistent data-only malware needs to find a way using a gadget to stack switch without corrupting register or memory values used later on. • The attack must hand back the hook to the previous function.

ROP Hardware Mechanisms - Sysenter • Sysenter instruction – an interrupt-based system call mechanism that relies on model-specific registers • IA32_SYSENTER_CS – defines the target code segment that will be used after the context switch • IA32_SYSENTER_EIP – holds the IP that will be used after the context switch occurred • IA32_SYSENTER_ESP – holds the SP that will be used after the context switch • Manipulation of EIP and ESP allows the attack to control SP and IP. The malware also monitors which hooks is the result of a real system call or the result of a function hook.

ROP Hardware Mechanisms - TSS • Task State Segment (TSS) are not used by most OSs but TSS perform context switches between processes. • A malware may control the IP and SP during invocation of a hook but must first set up a TSS descriptor which is pointed to by the function hook. The TSS descriptor are saved so that the malware can easily restore old execution context. • This technique is restricted to 32-bit systems. In 64 and 86 bit systems, the TSS can control the SP through the Interrupt Stack Table (IST), which contains the memory region that can be used as a stack region. • To do this, the first gadget must increase the SP by the size of the interrupt-stack-frame and then the hook has to be set to a gadget to invoke the interrupt which includes the TSS descriptor to trigger the hook.

Architecture of Persistent Data-only malware

Software Mechanisms For Switching the Stack • Attack doesn’t control a register nor a buffer on the stack. • If the persistent control structure is put above the stack, which means that the control structure must be loaded at an address that is smaller than the original stack minus the maximum stack size of the process. • This allows the control structure to not be destroyed during program execution. • The stack offset does not have to point directly to control structure as it can use a NOP sled to enter the control structure. • May overwrite the stored address (per_cpu) so that when it switches the user space to kernel space, it will load the overwritten address. • May overwrite multiple function points to make a function pointer chain • Library pointers are called as function pointers that are offsets within a global table (GOT)

Architecture of Persistent Data-only malware - Initialization • Initialization Chain • Must be loaded using a vulnerability • Only executed once – more like traditional ROP exploit • Does not require an exclusive memory area or affected by overwrites • (1) places a hook, (2) setups a switching mechanism, (3) copy the copy chain into memory exclusively owned by the malware. The malware may have to create a global state to be stored across multiple invocations. • The memory region which is used to contain the state must be own exclusively by the malware (so as to not get overwritten) RESULTS: Hook is placed on a now infected system https://3.bp.blogspot.com/-MtueiTTzaQQ/UlN8aUdArOI/AAAAAAAACGk/S_qVr8_HOkc/s320/ROP.png

Architecture of Persistent Data-only Malware – Copy Chain • Copy Chain – • Invoked every time the hook placed by the initialization chain is triggered • Saves the values of all general purpose registers in order to be able to restore the original register values. • Initially extremely limited gadgets but every register adds functionality. • Still, the copy chain must execute with interrupts disabled and cannot invoke external functions. • Creates a separate dynamic component upon each invocation to create dynamic control structure. • Disabling interrupts avoids dynamic components being overwritten but my constrain the malware’s control structure. • RESULTS: Values are saved to be restored after the payload has been delivered

Architecture of Persistent Data-Only Malware – Dispatcher Chain • Dispatcher Chain – • Required whenever concurrent threads can invoke a hook. • A dispatcher chain creates an individual process for each process • Allocates a memory area for each process and copies payload chain • Creates an individual state for each process • Guarantees that a specific payload chain will always have access to the same state area. • Interrupts must remain disabled while dispatcher is executing. • RESULT: Each process has a individual persistent state and unique payload

Architecture of Persistent Data-only Malware – Payload Chain • Payload chain – • Contains the functionality of the malware. • Not affected by rewrites (self-induced or interrupt-induced). • The malware may, at the payload, invoke any external function and make use of any register that has been saved by the copy chain. • The payload chain is a traditional ROP chain and is only limited by the gadgets provided by the victim’s system. • RESULTS: The payload must restore the original register values saved by the copy chain which have been placed into the process state by the dispatcher state. It must restore the original Stack Pointer.

ATTACK and Implementation - Initialization • POC assumes that the attacker has root privileges but since the attack requires a vulnerability, it can be loaded without requiring root privileges. • The three ROP chains execute and payload is deployed. • FP is pointed to the initial ROP-chain, which will be loaded into the SP by the leave instruction. • The attacker triggers the exploit by executing an int <interrupt>; command. Trigger of the hook is NOT normally controlled by an attacker but in POC, attacker controls the FP. • Memory is allocated for the copy chain and copy chain is copied into memory

Initialization Stage

Attack and Implementation – Persistent Stage • Hooks are set and any call to read or getdents call sysenter, which switches the stack and is independent of hooks for system calls. • Copy chain is activated after the stack is switched. Copy chain saves the state of the CPU and stores the values of critical registers for future restoration. • Dispatcher chain is copied into memory area and execution is transferred to the dispatcher chain. • Dispatcher chain obtains the data structure by grabbing the per_cpu data structure. The dispatcher copies the values of the registers that have been saved by the copy chain. Then it copies the payload chain into the newly allocated region. • Payload executes the desired functionality (which is a keylogger in the POC). The rootkit will execute the command and delete data within the buffer or write the data entered by the user to the kernel log. • Restore registers and return stored values back to the corresponding registers. The original value of the FP is also restored.

Persistent Stage

Protection Mechanisms Revisited • Data-only malware is not affected by many protection measures such as code-signing, code integrity approaches, or many overwrite mechanisms. • Stack canaries and ASLR must be circumvented but can be bypassed depending on the vulnerability used for the initialization. • Stack canaries can be beat by controlling a pointer variable to change data without having to modify the canary • Can override a pointer to an interrupt handler to defeat ASLR • The persistent data-only malware does not require the circumvention of additional security measures. • Non-persistent and persistentmalware are equally likely of a threat.

Countermeasures • Function pointer is overwritten to permanently change control flow. ASLR is a constraint on malware but has its own weaknesses. • ROP is achieved by looking for inconsistencies on the stack when ret instruction is executed. It takes a snapshot of the stack and checks whether the changes are consistent with normal operations. • Attempt to remove usable ret instructions or encrypt addresses used for returns or jumps. • The only protection mechanisms that must be circumvented are exploit prevention mechanisms such as stack canaries and ASLR. • Stack Canaries can be defeated by controlling a pointer without modifying the canary. • ASLR is defeated by overwriting a pointer to an interrupt handler.

Residence of Malware • In order to survive a reboot, the malware must automatically execute the initialization stage of the malware, which also re-exploits the malware’s vulnerability. • The vulnerability must be contained in a program that runs at boot and must be self-triggering. It must fulfill all requirements for the initialization step. • To fulfill all requirements, a multi-stage initialization step may be used. It is possible that the residence may be achieved by introducing code and the malware’s persistence is achieved by data-only means.

Conclusion • ROP detection is key to defending against persistent data-only malware. • Persistent data-only malware permanently changes the control flow of the host without introducing instructions. It leverages OS and hardware features to place hooks in software. • The paper demonstrates that the ROP attack proposed by the paper can execute a persistent data-only malware that also circumvents current security mechanisms. Future Work: new methods for detecting or hindering persistent data-only malware.

Sources • ”Persistent Data-only Malware: Function Hooks without Code", H.SebastianVogl, Jonas Pfoh, Thomas Kittel, and Claudia Eckert, Technische University Munchen, 2014.

Persistent Data-only Malware: