1 / 27

l ess is more

l ess is more. Exploring code/process-less techniques and other weird-machine methods to hide code (and how to detect them). Slide URL: http:// 1drv.ms/1dJX2HI. 09.09.99. Major References. Win32 Buffer Overflows (p55, 09.09.99) dark spyrit / Barnaby Jack One of the greatest ever

adah
Download Presentation

l ess is more

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. less is more Exploring code/process-less techniques and other weird-machine methods to hide code (and how to detect them). Slide URL: http://1drv.ms/1dJX2HI

  2. 09.09.99 Major References Win32 Buffer Overflows (p55, 09.09.99) dark spyrit / Barnaby Jack One of the greatest ever RIP

  3. Major References • Exploitation and state machines • Thomas Dullien / Halvar Flake • Sergey Bratus, TAOSSA (http://www.azimuthsecurity.com/) • Windows Kernel-mode Payload Fundamentals & A Catalog of Windows Local Kernel-mode Backdoor Techniques • Skape (mmiller@hick.org) (both) & Bugcheck (chris@bugcheck.org) & Skywing (Skywing@valhallalegends.com) • The page-fault weird machine: lessons in instruction-less computation • Julian Bangert, Sergey Bratus, Rebecca Shapiro, Sean W. Smith from WOOT'13 Proceedings of the 7th USENIX conference on Offensive Technologies • Volatility Framework • AAron Walters and open source contributors.

  4. Windows hardening • Windows XP does not memset(0) driver .text sections • Random slack can be executed • Updated 2k3+ • KINTERRUPT no longer has huge code templates/glue included as part of it’s structure • KINTERRUPT.DispatchCode is now 4 bytes (and always just points to a registered handler in the module) instead of up too 106 bytes of arbitrary code • Updated Vista+ • Page table entries secured • Win8 no longer has executable page table entries • Kernel 9200+ (8/2012) Kernel Pool (heap) is no longer default executable • This is a MAJOR win!!!!!! • No more huge degree’s of unknown executable memory to inspect

  5. Our target • Rootkit can shadow/move itself during dump’s • Issues from dumping memory from a live/physical system is problematic and has lead to an interesting arms race; • Using cold-boot attacks • Purpose built dumping hardware or commodity FireWire type inputs • Cause kernel panic to induce a dump • Windows Kernel 9600 (Windows 8.1/2012R2) • A snapshot from VMWare or Hyper-V • We will ignore dump acquisition issues for now and focus on VM snapshots

  6. X64 Kernel Virtual Address Space http://www.codemachine.com/article_x64kvas.html

  7. Page Table Shellcode weird-machine • Win7 and earlier • Can we emit intended shellcode into PTE area? • Perform some VirtualAlloc from user space => executable memory in kernel • Just reserving memory writes PTE • Page Table shell-code is non-trivial • Lots of gadgets!

  8. Win8 PT Shellcode attempting to run • Seemingly cleanly return • No double fault or bug check • We keep entering KiPageFaultafter returning from KiPageFault…

  9. Defense: Rootkit revealing • Default non-execute poolspace helps tremendously • Detect the presence of a rootkit by comparing results from multiple sources/abstraction layers • Physical (page tables) • Logical • Driver LIST_ENTRY • VAD • SECTION’s, …

  10. Tool evaluation • Implemented in .NET • Operates on direct physical memory dumps from VM snapshots • Demo script that identifies KVAS physical/logical sections • Transforms/Dumps memory / Generates hashes • Future • More well known blocks (local optimization)? • There’s some weird looking fill patterns often sitting around as exec; More page table checks, CR0.WP etc…

  11. Example VMWare ~8GB

  12. ffffd000201a0000 appears across Hyper-V & VMWare, reboots Provides RoP gadgets Fixed writeable executable memory location Writable/Executable at a fixed address …moving on; Attack! To the Unknown!

  13. Can you guess what it is? • ?? • Segoe_slboot.ttf • Starts at offset 0x1d0 • Initial bytes some sort of heap tag ? BG* • System boot/load time artifact

  14. Seems to have some basic heap structure pointer’s/allocation sizes Unfortunately it’s all default executable/writable at a fixed address across systems/rebooting This leaves a lot of room for RoP gadgets (MZ is only .rsrc, why +x?) A little more (past end of font)

  15. BIOS Ranges • Platform specific (vmware in this case) • 2012R2 0xffffd00020500000, 8.1 0xffffd00020600000 • Fixed address across reboots (size is 241,664 - 0x3B000) • Physical system dumps

  16. Other/More dynamic/Misc Areas • Slack • Audit MDL structures • Session Space • ACPI FACS -- exec • Firmware ACPIControl Structure • Verify ACPI with wite list • Shim Engine (i.e. handling for drvmain.sdb) • Bootloader artifacts • Volume manager heap

  17. Related topics • White list extracted bootmgr.exe • Well-known pages • NULL, all set, GUARD • Interesting/weird fill patterns • 2007, ###### • Iiiiii (0x69;) • Make sure their not gadget’able…

  18. Other Gadget Areas • There are other +X areas, in the region, but have small variability in their allocation • Windows Boot manager, network boot support code, more font areas

  19. Defense: RoP Detection • Spurious Saved Return Addresses • Sometimes RoP Gadget isjust random data present in an executable section!!! • All existing RoP Databases or techniques target arbitrary saved return addresses • https://www.corelan.be/index.php/security/corelan-ropdb/#advapi32dll_8211_5126005755 • 0x77e25c1f, # POP EAX # RETN • Saved Return should be • Simple/Effective/Very reliable reducing gadget surface area

  20. Spurious Saved Return Addresses Validation • Conceptually similar to heap back-checking logical links except we walk the stack • Think Heap/Pool verification • Verify op-code preceding saved return address • Adding into BlockWatch • Our operation is static so performance is no big deal and we like to be current!  • Some performance impact if implemented at run time • May not reduce the gadget surface area sufficiently

  21. Attack:RoP Compiler • Gadget surface area is reduced by SSRAV • Use a gadget compiler from verifiable gadgets only • Work done from Codeless Pagefaulting; • … a “A one Instruction Computer” with A move-branch-if-zero-or-decrement instruction, short movdbz. ... It has been proven that … is Turing-complete…

  22. Defense: Finally • RoP compiler’s are neat, but with adequate surface area reduction of dependable RoP gadgets • Remove EXECUTE from unneeded areas • Decommit/wipe unused • RoP chain will be really huge and will have fairly obvious looking characteristics • Even on AMD64 max stack is 4GB; “the maximum size of a segment (ss).” • Detecting codeless-pagefaulting • Specifically; Scan/Verify GDT and TSS • Generally; Performance drain, counters, clock skew, context switches, accounting, …

  23. So What? • Page table verifier identifies hidden areas • White list as much as possible • High 99% • DefendRoP attacks with SSRA checking

  24. Comprehensive verification • Forensics • Reduction / Analysis aid • APT Detection • Diffing • White list

  25. Dependencies? • Require NX • SMEP Reccomended

  26. What about script hosts? • Instrument / Profile scripts to generate white lists • Doable for .NET • More difficult for PHP and company?

  27. Demo

More Related