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 - Very old (Kernel 2.2) knark (*) 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 - Modern rookit (Kernel v3.x) ARM Suterusu (*) - Can hide network ports x86 X X X X - Can disable LKM x86 64 - One of the latest wild rootkits ARM XOR.DDoS - Binary only x86 X X X X 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 o f f s e t , ∗ v e c t o r s w i a d d r ; o 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 ) { o 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 open, 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: � ret2usr - Return to user 1 � PXN Privilileged Execute 2 Never (or SMEP - Supervisor Mode Execution Prevention on Intel) � ret2dir - Return to direct 3 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 kernel: When exec. guest user: User space WX , kernel neither User space and kernel data W , kernel .text X but not W W nor X 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 on , 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 oses. In ACM SIGOPS Operating Systems Review , volume 41, pages 335–350. ACM, 2007. julian (sect) Software Security SoSe 2016 21 / 21
Recommend
More recommend
