Software Security VMI (Virtual Machine Introspection) / VMM-based - - PowerPoint PPT Presentation

Software Security

VMI (Virtual Machine Introspection) / VMM-based Intrusion Prevention Julian Vetter

• Prof. Jean-Pierre Seifert

Security in Telecommunications TU Berlin

SoSe 2016

julian (sect) Software Security SoSe 2016 1 / 21

Virtualization (Recap)

Assume basic virtualization support (Intel VT-x, AMD SVM, ARM VE) ⇒ All sensitive instructions either handled internally (i. e. modify virtual state instead of physical state) or cause a trap into HV MMU with nested page table support

First translations GV → GP Nested translation GP → P

IOMMU/SYSMMU to keep devices in check What now? Virtualization? So what?

julian (sect) Software Security SoSe 2016 2 / 21

Virtual Machine Introspection

First idea defined in 2001 “When virtual is better than real” [1] Host Intrusion Detection System Check the integrity of guest kernel

julian (sect) Software Security SoSe 2016 3 / 21

VMI: Semantic Gap

VM might be infected with malware... HV provides an interface for trustworthy (detector) VMs to read memory of an other (supervised) VM Detector VM tries to figure out if supervised VM was infected The detector VM can only read raw main memory... So what to do? Problem: Semantic Gap!

julian (sect) Software Security SoSe 2016 4 / 21

Linux kernel rootkits

To bridge the semantic gap we need to know what rootkits change/manipulate in a system

Name Comment Arch. Module Module

• Arch. State.

Use raw Process Syscall table Loading hiding manipulation socket hiding manipulation Cloaker (POC)

• Academic rootkit

ARM X knark (*)

• Very old (Kernel 2.2)

x86 X X X X

• Already provided many modern features

Phrack rootkit I (*)

• Described in Phrack magazine issue 58

x86 X Phrack rootkit II (*)

• Described in Phrack magazine issue 68

ARM X X Suterusu (*)

• Modern rookit (Kernel v3.x)

ARM X X X X

• Can hide network ports

x86

• Can disable LKM

x86 64 XOR.DDoS

• One of the latest wild rootkits

ARM X X X X

• Binary only

x86 x86 64

Table: List of exisiting rootkits and the features they use (* Sourcecode available)

julian (sect) Software Security SoSe 2016 5 / 21

Rootkit example I: VBAR/SCTLR manipulation

Privilege transition from usr (ring-3) to svc (ring-0) involve control flow transfer to vectors page Address of the vectors page is controlled through SCTLR and VBAR Syscalls use that mechanism Changing the vectors page allows attacker to get into control for each syscall [2]

julian (sect) Software Security SoSe 2016 6 / 21

Rootkit example II: Syscall table hooking

Syscall recap: Linux user process requests service from kernel via syscall:

Load value into a designated register Call svc (int 80) instruction

Value is used as an index into a table (syscall table) Syscall table holds function pointers to kernel functions implementing the requested syscall

julian (sect) Software Security SoSe 2016 7 / 21

Rootkit example II: Syscall table hooking (cont.)

Attacker can obtain the syscall table address, even if it’s not exposed (through /proc/kallsyms),

Inspecting the zImage (kernel image) Address can be calculated from the vector table (swi vector) [3]

The syscall table is a convenient target Once the vector is overwritten → attacker always gets control when the syscall with this number is called

julian (sect) Software Security SoSe 2016 8 / 21

Rootkit example II: Syscall table hooking (cont.)

Here is how the Suterusu rootkit [4] finds the syscall table

unsigned long ∗ f i n d s y s c a l l t a b l e ( void ) { void ∗ s w i a d d r = ( long ∗)0 x f f f f 0 0 0 8 ; unsigned long

• f f s e t ,

∗ v e c t o r s w i a d d r ;

• f f s e t = ((∗( long

∗) s w i a d d r ) & 0 x f f f ) + 8; v e c t o r s w i a d d r = ∗( unsigned long ∗∗)( s w i a d d r + o f f s e t ) ; w h i l e ( v e c t o r s w i a d d r++) { i f ( ((∗( unsigned long ∗) v e c t o r s w i a d d r ) & 0 x f f f f f 0 0 0 ) == 0 xe28f8000 ) {

• f f s e t = ((∗( unsigned

long ∗) v e c t o r s w i a d d r ) & 0 x f f f ) + 8 ; r e t u r n v e c t o r s w i a d d r + o f f s e t ; } } r e t u r n NULL ; } julian (sect) Software Security SoSe 2016 9 / 21

Rookit activities

Once rootkit has kernel privileges you can request services

Hide processes, sockets, modules Start SSH server

How do we hide these things? Tools such as ps read /proc/ to find running processes ProcFS is a virtual filesystem not backed by “memory” Each filesystem has a kernel structure called file operations file operations struct contains pointers to functions that handle

• pen, read, write etc.

Rootkits can overwrite read pointer in the struct of procFS Read function only returns subset of processes Effectively hide processes

julian (sect) Software Security SoSe 2016 10 / 21

Back to the semantic gap!

Defender has to do the same things as the attacker Somehow find valuable datastructures and check if they where manipulated Rootkit example I: VBAR/SCTLR manipulation

Easy to check for defender VBAR is set on system start and never changed HV can read the register and check the address If address is different from default case → Rootkit detected!

julian (sect) Software Security SoSe 2016 11 / 21

Back to the semantic gap! (cont.)

Processor state is easy to check because it is contained in registers What about structures in memory? This is were the fun begins...

julian (sect) Software Security SoSe 2016 12 / 21

Bridging the semantic gap: An easy one

Finding processes in raw memory Stack is 8k aligned thread info struct is located on the stack thread info struct has a pointer to its task struct task struct contains pointer back to the stack

julian (sect) Software Security SoSe 2016 13 / 21

Bridging the semantic gap: An easy one

As we have seen before, attacker only overwrites procFS file operations struct The kernel structure for the process is still there (it has to be!) Now we can compare both lists, the one from the procFS (ps) and the one we reconstructed (on the slide before) If one is missing in the procFS list → Rootkit detected!

julian (sect) Software Security SoSe 2016 14 / 21

VMM-based Intrusion Prevention

No common name exists First proposed in 2007 “SecVisor: A tiny hypervisor to provide lifetime kernel code integrity for commodity OSes” [5] Attacker should be prevented to take over the kernel in the first place Rules are enforced from within the HV Rationale:

User-level attacks can be prevented from inside the kernel But what if the attacker managed to exploit the kernel Finding kernel-level rootkits from within the kernel is a bad idea

julian (sect) Software Security SoSe 2016 15 / 21

Attacking the kernel

What does an attack want to do?

Attacker wants to execute malicious code Attacker want to stay persistent in the kernel (Attacker might want to exfiltrate user data)

julian (sect) Software Security SoSe 2016 16 / 21

Attacking the kernel (cont.)

Depending on the vulnerability, attacker needs to store shellcode Two common ways to do this: 1 ret2usr - Return to user 2 PXN Privilileged Execute Never (or SMEP - Supervisor Mode Execution Prevention on Intel) 3 ret2dir - Return to direct mapped memory

julian (sect) Software Security SoSe 2016 17 / 21

Privilege enforcement from HV

What if we can prevent the attacker from executing code in the first place? But, HV has no knowledge about guest memory layout, therefore nested page table looks like this (everything is WX):

julian (sect) Software Security SoSe 2016 18 / 21

Privilege enforcement from HV (cont.)

What if we can have two nested page tables? Both tables with same mappings but with different permissions Load each page table depending if guestes executes kernel or user When exec. guest user: User space WX, kernel neither W nor X When exec. guest kernel: User space and kernel data W, kernel .text X but not W

julian (sect) Software Security SoSe 2016 19 / 21

Privilege enforcement from HV (cont.)

Problems with the approach are,

For every guest context siwtch the system has to trap into the HV to switch the nested page table The TLB has to be synchronized

julian (sect) Software Security SoSe 2016 20 / 21

• P. M. Chen and B. D. Noble.

When virtual is better than real [operating system relocation to virtual machines]. In Hot Topics in Operating Systems, 2001. Proceedings of the Eighth Workshop

• n, pages 133–138. IEEE, 2001.
• F. M. David, E. M. Chan, J. C. Carlyle, and R. H. Campbell.

Cloaker: Hardware supported rootkit concealment. In Security and Privacy, 2008. SP 2008. IEEE Symposium on, pages 296–310. IEEE, 2008. dong-hoon you. Android platform based linux kernel rootkit. Phrack, 68, April 2011. mncoppola. An lkm rootkit targeting linux 2.6/3.x on x86( 64), and arm. https://github.com/mncoppola/suterusu, September 2014. Accessed: 2015-04-13.

• A. Seshadri, M. Luk, N. Qu, and A. Perrig.

Secvisor: A tiny hypervisor to provide lifetime kernel code integrity for commodity

• ses.

In ACM SIGOPS Operating Systems Review, volume 41, pages 335–350. ACM, 2007.

julian (sect) Software Security SoSe 2016 21 / 21