Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

Hello rootKitty: A lightweight invariance-enforcing framework

762 views

Published on

A lightweight invariance-enforcing framework to mitigate rootkits in virtualized operating systems

Published in: Technology
  • Be the first to comment

Hello rootKitty: A lightweight invariance-enforcing framework

  1. 1. hello rootKitty a lightweight invariance-enforcing framework Francesco Gadaleta - Nick NikiforakisDISTRINET Research Group Katholieke Universiteit Leuven - Belgium
  2. 2. hello rootKitty a lightweight invariance-enforcing framework Francesco Gadaleta - Nick NikiforakisDISTRINET Research Group Katholieke Universiteit Leuven - Belgium
  3. 3. OVERVIEWrootkit Operating System frameworkcritical kernel objects malware detection code virus Analysisintegrity invariance attackmodule virtualization maliciousrepairing memory corruption approachprofiling hardware-based countermeasureevaluation
  4. 4. ๏ process hiding๏ botnet ๏ stealing private data ROOTKIT ๏ subverting kernels ๏ spamming ๏ bank fraud
  5. 5. ROOTKITUser-mode ls, ps, PATH, etc... limited to user’s privilegesKernel-mode device drivers, access to kern. memory, etc... limited to kernel’s privileges (=unlimited)
  6. 6. FACTof rootkits will never be solvedthe problem
  7. 7. FACT
  8. 8. FACT“I’d rather tackle world peace than the rootkitproblem, it is that hard to solve”
  9. 9. ATTACKER MODELLoading rootkit as LKMLoading by overwriting memorydirectly (eg. /dev/mem, /dev/kmem)Executing arbitrary code via kernel vulnerabilityGOAL: Compromission of hardcoded, static,dynamic kernel objects
  10. 10. VIRTUALIZATION Events trapped by the hypervisor case EXIT_REASON_MOV_CR case EXIT_REASON_CPUID case EXIT_REASON_IO_INSTRUCTION case EXIT_REASON_RDMSR case EXIT_REASON_WRMSR Guest kernel case EXIT_REASON_EXCEPTION_OR_NMI case EXIT_REASON_EXTERNAL_INT case EXIT_REASON_INTERRUPT_WINDOW case EXIT_REASON_INVLPG case EXIT_REASON_VMCALL: /* for debugging */ case EXIT_REASON_INIT_SIGNAL case EXIT_REASON_STARTUP_IPI case EXIT_REASON_HLT VMExit VMEntry case EXIT_REASON_TASK_SWITCH case EXIT_REASON_XSETBV guest memory space hypervisor memory space Hypervisor
  11. 11. ASSUMPTIONRootkits modify kernel data structuresObserving critical kernel objects is a gooddetection strategyVirtualization still not massively exploited indesktop environments (QubesOS)
  12. 12. APPROACH Phase 1: collecting addresses of data structures to protect phy s ad 0xC dr 1 234 0xC 567 size 3214 0xC 567 128 flag 421 s 456 128 111 0xC A 111 521 11 456 111 C 64 111 11 111 4 111 11 guest kernel 111 111 11 trusted moduleguest memory spacehypervisor memory space hypervisor
  13. 13. APPROACH Phase 2: check integrity within the hypervisor mem. space guest kernelguest memory spacehypervisor memory space hypervisor phys addr size hash 0xC1234567 128 abcd 0xC3214567 128 abde 0xC421456A 64 1234 0xC521456C 4 4321
  14. 14. APPROACH Phase 3: repair compromised objects (if original content provided) guest kernelguest memory spacehypervisor memory space hypervisor phys addr size hash 0xC1234567 128 abcd 0xC3214567 128 abde 0xC421456A 64 1234 0xC521456C 4 4321
  15. 15. IMPLEMENTATIONExploit the MOV_CR event :-| App 1 App 2 App 3 (1)When the guest kernel changes a <mov CR3, cr3_app2> schedulercontrol register it is doing Guestsomething “interesting” such as kerneltask switching :-) (2) guest memory space hypervisor memory spaceRoom for improvement: we can hypervisor (3)map all the objects to a common host_virt_spacearea in the hypervisor’s space and phys addr size hash 0xC1234567 128 abcdcompute the checksum once 0xC3214567 0xC421456A 128 64 abde 1234 0xC521456C 4 4321
  16. 16. IMPLEMENTATIONLists of objects to protect might beHUGE=> let’s relax the problem phys addr size hash <mov CR3, cr3_app1> <mov CR3, cr3_app2> <mov CR3, cr3_app3>SOLUTION: <mov CR3, cr3_app4>on MOV_CR event the hypervisorchecks a subset of objects $$
  17. 17. EVALUATIONBitVisor 1.1 and Linux Kernel 2.6Total: 15000 kernel objects 128-bit sizedRate: 100 objects/MOV_CR*Corruption of pointers in the guest system call table
  18. 18. PERFORMANCELMBENCH (microbenchmarks)Processes open/close sign. handl. fork exec +0.6% +2.5% +41% +35%Local comm. TCP File reread Mmap reread Bcopy Mem.read Mem. writebandwidths +2.2% 0% -0.9% -0.32% -0.12% 0.12%
  19. 19. PERFORMANCEAPACHEBENCH 100K requests, 50 concurrently on local lighttpd server(macrobenchmarks)Time +1.50%Req. per second +1.52%Time per request +1.54%Time per conc. req +1.4%Transfer rate +1.52%DETECTION TIME(time the hypervisor needs to check a compromised object in the worst case)Depends on the guest load, about 6 sec wall-clock time
  20. 20. LIMITATIONSProtects invariantsAttacks to variant data structures are still possible
  21. 21. DISCUSSIONKernel developers support systemFine-grained protectionLightweight contermeasureGuarantees target-monitor isolation
  22. 22. DEMO.
  23. 23. CONCLUSIONhelloRootkitty mitigates the problem of kernel malwareNegligible overheadAttack surface might be considerably reducedEasy integration with other protection mechanisms(Daikon, Gibraltar)
  24. 24. THANKS.

×