Derek Soeder Ryan Permeh b l
eEye BootRoot a
This presentation will cover the eEye BootRoot project, an exploration of technology that boot sector code can use to subvert the Windows NT-family kernel and retain the potential for c execution, even after Windows startup—a topic made apropos by the recent emergence of Windows rootkits into mainstream k awareness. We will provide some brief but technical background on the Windows startup process, then discuss BootRoot and related technology, including a little-known stealth technique for h low-level disk access. Finally, we will demonstrate the proof-of- concept BootRootKit, loaded from a variety of bootable media. a t b r i e f
Derek Soeder is a Software Engineer and after-hours researcher at eEye Digital Security. In addition to i participating in the ongoing development of eEye's Retina Network Security Scanner product, Derek has also produced n a number of internal technologies and is responsible for the discovery of multiple serious security vulnerabilities. His main areas of interest include operating system internals and machine code-level manipulation. g
Ryan Permeh is a Senior Software Engineer at eEye Digital Security. He focuses mainly on the Retina and SecureIIS product lines. He has worked in the porting of nmap and s libnet to Windows, as well as helping with disassembly and reverse engineering, and exploitation efforts within the eEye research team.
b l a c k
eEye BootRoot: h CLICKA Basis TO for ADD Bootstrap-Based MASTER Windows TITLE Kernel ALL Code CAPS a
Derek Soeder, Software Engineer Click to edit Master subtitle style Ryan Permeh, Senior Software Engineer t b r
Introduction 2 i e
• Explores the capabilities of custom boot sector code on NT-family Windows f – What can it do? Anything – it’s privileged code on the CPU – The trick is keeping control while allowing the OS to function i
• Overview n – BIOS boot process and Windows startup – eEye BootRoot: how it works, capabilities and shortcomings
– Demo: eEye BootRootKit backdoor g
• Required Knowledge s – x86 real and protected modes, some Windows kernel
digital self defense 4 3 digital self defense digital BIOS Handoff to Bootstrap Code BIOS Handoff to – Disk drive (fixed or removable) – CD-ROM – boot Network – Master Boot Record Hard drive – bootstrap loader Windows – NTLDR – OSLOADER.EXE – NTDETECT.COM – HAL.DLL, boot drivers NTOSKRNL.EXE, BIOS transfers execution to code from some other medium BIOS transfers execution to code Windows startup from a hard drive installation • • Booting Up – Summary Booting Up Booting black hat briefings b l
5 Booting Up – Disk Drive a
• BIOS loads first sector of drive (200h bytes) at 0000h:7C00h c – Executes in real mode
– SS:SP < 0000h:0400h, DS = 0040h (BIOS data area) k
• For hard drives, the first sector is the Master Boot Record – Copies itself to 0000h:0600h h – Locates a bootable partition in the partition table – Executes the first sector of the boot partition at 0000h:7C00h a • Partition boot sector is always part of the operating system – Loads and executes the next boot stage of the OS t b r
Booting Up – MBR Partition Table 6 i
Master Boot Record Layout Partition Table Entry Format e
0000 xx xx xx xx xx xx xx xx-xx xx xx xx xx xx xx xx +00 BYTE Boot Indicator 0010 xx xx xx xx xx xx xx xx-xx xx xx xx xx xx xx xx -- bit 7: partition bootable ... +01 BYTE Starting Head 01B0 xx xx xx xx xx xx xx xx-xx xx xx xx xx xx BI SH f 01C0 SS SC ID EH ES EC L0 L1-L2 L3 S0 S1 S2 S3 BI SH +02 BYTE Starting Sector / Cylinder 01D0 SS SC ID EH ES EC L0 L1-L2 L3 S0 S1 S2 S3 BI SH -- bits 5..0: sector 01E0 SS SC ID EH ES EC L0 L1-L2 L3 S0 S1 S2 S3 BI SH 01F0 SS SC ID EH ES EC L0 L1-L2 L3 S0 S1 S2 S3 55 AA -- bits 7..6: cylinder (bits 9..8) i +03 BYTE Starting Cylinder (bits 7..0) Partition 1 (offset 01BEh) +04 BYTE System ID (volume type) n +05 BYTE Ending Head Partition 2 (offset 01CEh) +06 BYTE Ending Sector / Cylinder Partition 3 (offset 01DEh) -- bits 5..0: sector -- bits 7..6: cylinder (bits 9..8) g Partition 4 (offset 01EEh) +07 BYTE Ending Cylinder (bits 7..0) +08 DWORD Linear sector number of partition +0C DWORD Size in sectors of partition s
Source: NTFS.com Hard Drive Partition - Partition Table. http://www.ntfs.com/partition-table.htm
digital self defense 8 7 . . 80BA WORD Volume Sequence Number (big-endian) 80BB BYTE Length of File Identifier = 1 809C BYTE Length of Directory Record = 1 80BC [1] File Identifier = {0} 80B8 WORD Volume Sequence Number = 1 80B8 WORD 80B5 BYTE File Flags = 02h (Directory) 8000 BYTE Volume Descriptor Type = 1 8001 [5] Standard Identifier = "CD001" 8006 BYTE Volume Descriptor Version = 1 DWORD Volume Space Size (sectors) = 15h 8050 8054 DWORD Volume Space Size (big-endian) 8078 WORD Volume Set Size = 1 807A WORD Volume Set Size (big-endian) 807C WORD Volume Sequence Number = 1 807E WORD Volume Sequence Number (big-endian) Logical Block Size = 0800h WORD 8080 8082 WORD Logical Block Size (big-endian) [22h] Directory 809C Record for Root Directory digital self defense digital ECMA-119: Volume and File Structure of CDROM for Information Interchange Torito” “El Bootable CD-ROM Format Specification, Version 1.0 –(2KB) Sector size is 800h bytes – (ECMA-119 / ISO 9660) Data format is more complicated – by “El Bootable CD format dictated Torito” Specification – Executes in real mode – area) SS:SP = 0000h:0400h, DS = 0040h (BIOS data – Boot catalog entry indicates mode” “emulation (floppy or HD) Differences from disks and diskettes Differences from first 200h bytes) loads at 07C0h:0000h Boot sector (only via INT 13h Additional disc contents are accessed Boot Catalog Boot Code (unused) Primary Volume Boot Record Volume Set Terminator Volume Source: http://www.ecma-international.org/publications/files/ECMA-ST/Ecma-119.pdf Source: http://www.phoenix.com/NR/rdonlyres/98D3219C-9CC9-4DF5-B496-A286D893E36A/0/specscdrom.pdf • • • 9800 0000 8000 8800 9000 A000 A800 Booting Up Booting –(1) Bootable CD Layout Booting Up Booting – CD-ROM black hat briefings b l
9 Booting Up – Bootable CD Layout (2) a
0000 (unused)
8800 BYTE Volume Descriptor Type = 0 c 8801 [5] Standard Identifier = "CD001" 8806 BYTE Volume Descriptor Version = 1 8000 8807 [20h] Boot System Identifier = Primary Volume "EL TORITO SPECIFICATION", {0} k 8847 DWORD Pointer to First Sector of Boot Catalog 8800 Boot Record Volume
9000 Set Terminator Volume h 9800 9000 BYTE Volume Descriptor Type = 0FFh Boot Catalog 9001 [5] Standard Identifier = "CD001" 9006 BYTE Volume Descriptor Version = 1 A000 Boot Code a A800
Source: ECMA-119: Volume and File Structure of CDROM for Information Interchange. http://www.ecma-international.org/publications/files/ECMA-ST/Ecma-119.pdf t Source: “El Torito” Bootable CD-ROM Format Specification, Version 1.0. http://www.phoenix.com/NR/rdonlyres/98D3219C-9CC9-4DF5-B496-A286D893E36A/0/specscdrom.pdf b r
Booting Up – Bootable CD Layout (3) 10 i
0000 e (unused) f 8000 Primary Volume 9800 [20h] Validation Entry 8800 9800 BYTE Header ID = 1
Boot Record Volume 9801 BYTE Platform ID = 0 i 981C WORD Checksum = 55AAh 9000 981E WORD Key = AA55h Set Terminator Volume n 9820 [20h] Initial/Default Entry 9800 9820 BYTE Boot Indicator = 88h Boot Catalog 9821 BYTE Boot Media Type = 2 (1.44MB floppy) 9822 WORD Load Segment = 0 A000 Boot Code 9824 BYTE System Type = 0 g 9826 WORD Sector Count (virtual sectors) = 1 A800 9828 DWORD Load RBA (sector) = 14h
Source: ECMA-119: Volume and File Structure of CDROM for Information Interchange. http://www.ecma-international.org/publications/files/ECMA-ST/Ecma-119.pdf s
Source: “El Torito” Bootable CD-ROM Format Specification, Version 1.0. http://www.phoenix.com/NR/rdonlyres/98D3219C-9CC9-4DF5-B496-A286D893E36A/0/specscdrom.pdf
digital self defense 12 11 Port Server IP digital self defense digital Packet Port • Requires IP address, server’san boot file name address, and IP •client on UDP/68 on UDP/67, receives server BOOTP •UDP/69 server receives on TFTP – boot file from TFTP service on server Downloads – stored there Up to ~500KB of data will be downloaded and – Register values should be considered undefined – (basis for DHCP) and TFTP Network boot via BOOTP – configuration over BOOTP BIOS PXE boot agent requests Executes boot file in real mode at 0000h:7C00h Executes boot file in real mode at PXE: PrebootPXE: Environment eXecution [Server Identifier = (server IP); Boot File Name = "..."] [Server Identifier (server= IP); Boot File Name = [Server Identifier (server"..."] = IP); Boot File Name = [File: (boot file name); Mode: "octet"; "tsize" "blksize" 0; = size)] (block = [Block: 1; file data] ["tsize"= (size of boot file); "blksize" = (supported block size)] [Block: 0] [Block: 1] Client IP 0.0.0.0 68 DHCP Discovery -> 255.255.255.255 67 255.255.255.255 68 <- DHCP Offer (server IP) 67 0.0.0.0 68 DHCP Request -> 255.255.255.255 67 255.255.255.255 68 <- DHCP Ack(client IP) (var) TFTP Read Req -> (server IP) 69 (client IP) (var) <- TFTP Option ACK (server IP) IP) (server 67 69 (client IP) (var) TFTP ACK -> (server IP) 69 (client IP) (var) <- TFTP Data (server IP) 69 (client IP) (var) TFTP ACK -> (server IP) 69 ... • • Booting Up Booting –Example Network Boot Traffic Booting Up –Boot Network black hat briefings b l
13 Windows Startup a c k Windows Boot Sector to NTOSKRNL Execution h a t b r
Windows Startup – Boot Loader 14 i e
• Windows partition boot sector
– Loads first 16 sectors (itself is first) at 0D00h:0000h f – Uses IBM/MS INT 13h Extensions if available – Passes execution to next stage of Windows boot loader i
• Windows boot loader n – Loads and executes NTLDR at 2000h:0000h in real mode – Does not export any functionality to NTLDR – Only uses ~40% of its allotted 8KB (room for our code?) g s
digital self defense 16 15 KGDT_R0_CODE KGDT_R0_DATA KGDT_R3_CODE KGDT_R3_DATA KGDT_TSS KGDT_R0_PCR KGDT_R3_TEB KGDT_VDM_TILE KGDT_LDT KGDT_DF_TSS (NTLDR code) (NTLDR data) (text memory) (NTOSKRNL code) (NTOSKRNL data) Code32 Data32 Code32 Data32 Data32 Data32 Data16 Code16 Data16 Data16 Data16 Data16 Data16 Data16 A=0 A=0 A=0 A=0 A=0 A=1 A=0 A=0 A=0 A=0 A=0 A=0 A=0 A=0 P=1 P=1 P=1 P=1 P=1 P=1 P=1 P=1 P=1 P=1 P=1 P=1 P=1 P=1 0 0 3 3 0 Task Gate 0 3 3 0 Task Gate 0 0 0 0 0 0 0 DPL= DPL= DPL= DPL= DPL= DPL= DPL= DPL= DPL= DPL= DPL= DPL= DPL= DPL= DPL= DPL= 00000000 00000000 00000000 00000000 00024460 00000000 00000000 00000400 00023B7E 00020000 00022F30 000B8000 FFFF7000 80400000 00000000 80400000 digital self defense digital Base= Base= Base= Base= Base= Base= Base= Base= Base= Base= Base= Base= Base= Base= Base= Base= 0000006F 0000FFFF 0000FFFF 00003FFF 00003FFF 0000FFFF 00000000 FFFFFFFF FFFFFFFF FFFFFFFF FFFFFFFF 00000077 00001000 00000FFF 0000FFFF 0000FFFF INT 13h: Disk Reboot 19h: INT • • 10h: Video INT • • INT 14h: Serial•Configuration, Power Management 15h: System INT Keyboard 16h: INT • • INT 1Ah: Clock (Date and Time) subsequent protected mode startup code will invoke: subsequent protected (reserved) Limit= Limit= Limit= Limit= Limit= Limit= Limit= Limit= Limit= Limit= Limit= Limit= Limit= Limit= Limit= Limit= : : : : : : : : : : : : : : : : : –in NTLDR OSLOADER.EXE is a PE image embedded – 2003 No MZ header or PE signature prior to Windows – mode NTLDR executes its entry point in 32-bit protected –use throughout Windows startup Creates GDT and IDT for – functionality that Wraps real mode BIOS interrupt Maps OSLOADER.EXE at its preferred image base Maps OSLOADER.EXE at its preferred Enters 16-bit protected mode Enters 16-bit protected #0050 #0058 #0060 #0068 #0070 #0080 #0088 #0008 #0010 #0018 #0020 #0028 #0030 #0038 #0040 #0048 • • #0078 Windows Startup – NTLDR GDT Windows Startup NTLDR – Windows Startup Windows NTLDR – black hat briefings b l
17 Windows Startup – OSLOADER.EXE (1) a
• OSLOADER.EXE loads the operating system c – Processes \BOOT.INI
– Executes NTDETECT.COM in real mode at 1000h:0000h k – Enables paging • Applies /3GB BOOT.INI option • Sets typical virtual addresses for GDT, IDT, and page tables – Loads HAL.DLL and NTOSKRNL.EXE, and any import h dependencies (BOOTVID.DLL), at their preferred virtual addresses, and applies relocations
– Loads the registry (system32\config\system) a – Loads NLS code pages and required fonts t b r
Windows Startup – OSLOADER.EXE (2) 18 i e
• OSLOADER.EXE loads boot drivers
– Loads drivers with a Start type of Boot (0) f • Creates a PsLoadedModuleList-format list (*_BlLoaderBlock) • Does not realign image sections prior to Windows 2003:
in-memory image is the raw file contents! i – Drivers do not execute at this stage n
• Transfers execution to NTOSKRNL.EXE entry point g s
digital self defense 20 19 ) thread (P0BootThread) Phase1Initialization _KeServiceDescriptorTableShadow) and and KeInitializeThread , _PsInitialSystemProcess _KeServiceDescriptorTable (_KiIdleProcess) (creates digital self defense digital initializes ( – HAL.DLL!HalInitSystem – ExInitSystem – MmInitSystem (0) – ObInitSystem – SeInitSystem – PsInitSystem – PpInitSystem KiSystemStartup calls KiInitializeKernel, calls which ExpInitializeExecutive • KiInitSystem • KeInitializeProcess • ExpInitializeExecutive •thread Phase1Initialization separate system executes as a • Boot drivers execute during this phase •initialization user-mode SMSS.EXE Finishes kernel and starts • – Phase 1 initialization –2” with licensing (ExInitSystemPhase2) mostly deals “Phase – HAL.DLL!HalInitializeProcessor – KiInitializeKernel – of TSS, IDT, and GDT NTOSKRNL assumes control – Initializes processor(s) and ABIOS support – Phase 0 initialization NTOSKRNL.EXE!KiSystemStartup NTOSKRNL and HAL.DLL finish initializing machine state HAL.DLL finish initializing machine NTOSKRNL and initialize in two passes or Kernel subsystems “phases” • • • Windows Startup 0 Initialization – Phase Windows Startup Windows NTOSKRNL.EXE – black hat briefings b l
21 Windows Startup – Phase 1 Initialization a
• NTOSKRNL.EXE!Phase1Initialization c – HAL.DLL!HalInitSystem – MmInitSystem (2) (makes executive pageable) – PoInitSystem (0) – PoInitSystem (1) – ObInitSystem – PsInitSystem (locates certain NTDLL exports) k – ExInitSystem – KeInitSystem – SeInitSystem – MmInitSystem (1) h – CmInitSystem – FsRtlInitSystem
– PpInitSystem a – LpcInitSystem – ExInitSystemPhase2 – IoInitSystem (IopInitializeSystemDrivers runs boot drivers, PsLocateSystemDll loads NTDLL.DLL) t b r eEye BootRoot 22 i e f
Technology for Windows Kernel Pre-Subversion i n g s
digital self defense 24 23 digital self defense digital GDTR, IDTR, MSRs,etc. , n DR , hardware device n • Hooking BIOS interrupt services is like hooking APIs • See Ralf Brown’s MEMORY.LST for more information Any of our own “adjustments” – Other processors...? – Programmable Interrupt Controller Chipset: e.g., – – area (100h bytes at 0040h:0000h) BIOS data – memory 640KB conventional –CR – Interrupt Vector Table (100h doublewords at 0000h:0000h) – Our code is privileged is 0” –mode “ring real – code execution We can control all subsequent – No part of the operating system is loaded yet – with a few We need the system to function normally, except – state changes OS startup will bring about dramatic machine CPU and hardware settings Real mode environment features We execute after the BIOS but before the operating system the BIOS but before the operating We execute after Advantages Disadvantages • • • • • eEye BootRoot – Playing Field eEye BootRoot – The Problem black hat briefings b l
25 eEye BootRoot – Game Plan a
• Windows startup will assume exclusive control over almost c every facet of machine state... – CPU state, IRQs, chipset, eventually most hardware k – Eventually all other CPUs in a multiprocessor system – Unused memory
• ...But its weakness is reliance upon the BIOS h – It uses BIOS interrupts, so IVT is mostly preserved – It has to respect memory ranges reserved by BIOS a
We can exploit this trust to function like a BIOS “hook” t b r eEye BootRoot – Our Solution 26 i e
• “Go resident” – reserve memory for a copy of our code
– Reduce conventional memory KB reported by 0040h:0013h f • Boot virii have used this technique forever
• Hook INT 13h (Disk) to “patch” OS files as they load i
– Scan for a code signature in OSLOADER and patch there n – Must handle INT 13h/AH=02h (Read Sectors) and INT 13h/AH=42h (IBM/MS Extensions – Extended Read) g • OSLOADER patch gives us an intermediate point to regain execution and modify OS further (i.e., patch boot drivers) s
digital self defense 28 27 (ACPI Reclaimable) (ACPI NVS) Available Available Available (Reserved) (Reserved) (Reserved) (Reserved) (Reserved) (Reserved) (Reserved) Type 3 4 1 1 1 2 2 2 2 2 2 2
00004000 00100000 00010000 00001000 00020000 0009F800 00000800 00002000 00004000 0001C000 07DF0000 0000C000 digital self defense digital 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 Length 07EFC000 07F00000 FEC00000 FEE00000 FFFE0000 00000000 0009F800 000CA000 000DC000 000E4000 00100000 07EF0000 • Could we piggyback Windows code? off boot loader mode to modify OS memory above 1MB mode to modify OS memory above –NTFS code to navigate FAT and Intrusive; requires – to get memory map OSLOADER calls INT 15h/AX=E820h – More of OS is loaded – more available to modify – protected Our hook runs in real mode, so we must re-enter Modify system files on disk before Windows startup Modify system files memory reserve any amount of extended Hook INT 15h to interrupt called late in Regain execution by hooking an Windows startup System memory map generated using INT 15h/AX=E820h on a RAM. 128MB with system VMWare4.5 00000000 00000000 00000000 00000000 00000000 Base Address 00000000 00000000 00000000 00000000 00000000 00000000 00000000 • • • eEye BootRoot Map Example – System Memory eEye BootRoot – Other Possibilities black hat briefings b l
29 eEye BootRootKit a c k “Finally, someone implemented it.” h a t b r eEye BootRootKit – Overview 30 i e
• Proof-of-concept for eEye BootRoot technology
– Loads from many bootable media f – Installs INT 13h hook to “patch” OSLOADER on load – OSLOADER patch locates module list, hooks NDIS.SYS i – NDIS backdoor inspects incoming packets for code to run n • Features – Works on Windows 2000 and later – Fits into 512 bytes! g
• The idea is simple, but there are always hidden complexities s
digital self defense 32 31 ”) , and addr2 = [addr1] CMP reg1, [reg2+58h] CMP reg1, ”, where ”, are addresses in our resident code is 6 bytes – bytes 6 is perfect for this patch site ” addr2 digital self defense digital ” is 7 bytes and addr1 CALL DWORD PTR [addr1] CALL DWORD PTR [ofs32] CALL seg:ofs32 •“ •“ •(“checking code... Could disable checksum • from disk Executed –= 0000h:7C00h CS:IP • CD from Executed – CS:IP = 07C0h:0000h virtual memory to low 16MB physical memory and both INT 13h/AH=42h extended reads (required for large disks) INT 13h/AH=42h extended reads (required two sectors) split across a read boundary (i.e., across – We use “ 0031ADF1 8B F0 MOV ESI, EAX TEST ESI, ESI F6 0031ADF3 85 0031ADF5 74 21 JZ $+23h signature modified, used as part of ; not only 0031ADF7 80 ... – absolute be don’tmust Hook we – know where code will load – concern a not is Paging OSLOADER will map low 16MB – – Don’t Warning: value of CS! assume – to handle INT 13h/AH=02h INT 13h hook must be able – must not be Signature should be unique, cross-version, and – (except itself) Warning: OSLOADER verifies PE checksums We patch 6 bytes executed after boot driver load: We patch 6 bytes executed after boot Move to reserved conventional memory and hook INT 13h conventional memory and hook Move to reserved read sectors for a code signature INT 13h hook scans • • • eEye BootRootKit Patch – OSLOADER eEye BootRootKit 13h – INT Hook black hat briefings b l
33 eEye BootRootKit – OSLOADER Patch Function a
• Scan OSLOADER for address of _BlLoaderBlock c – Assume OSLOADER begins on a 1MB boundary • 00300000h for 2000 and XP, 00400000h for 2003 k – Use CALL hook return address as pointer into OSLOADER – Scan for the following code signature: 00301888 C7 46 34 00 40 00 00 MOV DWORD PTR [ESI+34h], 4000h ... h 00301895 A1 xx xx xx xx MOV EAX, [_BlLoaderBlock] – [[_BlLoaderBlock]+0] points to base of module list
• Search module list for NDIS.SYS a – Name is usually uppercase, but don’t assume t b r eEye BootRootKit – OSLOADER Module List 34 i e
+00h LIST_ENTRY module list links +08h [10h] ??? +18h PTR image base address f +1Ch PTR module entry point +20h DWORD size of loaded module in memory i +24h UNICODE_STRING full module path and file name +2Ch UNICODE_STRING module file name n g
Format of loaded module list nodes used by OSLOADER and based at [[_BlLoaderBlock]+0]. Structure is identical to that used by NTOSKRNL in PsLoadedModuleList. s
digital self defense 36 35 (exact value is irrelevant, we just subtract a lot) digital self defense digital BFECEE7E 50 PUSH EAX BFECEE7F 53 PUSH ECX BFECEE80 C7 46 10 0E 00 00 00 MOV DWORD PTR [ESI+10h], 0Eh BFECEE87 E8 xx xx xx xx CALL ethFilterDprIndicateReceivePacket PUSH EBP / MOV EBP, ESP / SUB ESP, / SUB EBP, ESP / MOV PUSH EBP imm Leads to ethFilterDprIndicateReceivePacket, hook we which CALL destination Addresses, and vice versa, to find actual hook there and then store our own relative JMP afterward if first instruction is “MOV EDI, EDI” afterward if first instruction is EDI, “MOV – not enabled yet, modify away! Write protection – not is pageable Code so it will never be reloaded from disk – DOS overwrite We “MZ” code at (image base + 40h) – function provides a remote kernel backdoor This hook – are in different PE sections Note: These two functions – Virtual We must translate raw offsets into Relative – If listed module size is 64KB multiple, sections are aligned(?) – or two bytes Store a relative JMP at function entry point, – will always be: Assume overwritten instructions – This signature within ndisMLoopbackPacketX: Store hook function code In 2000 and XP, boot drivers’aren’t yet! sections aligned Hook ethFilterDprIndicateReceivePacket Hook Scan NDIS.SYS for code signature Scan NDIS.SYS for • • • • eEye BootRootKit – Hooking NDIS (2) eEye BootRootKit – Hooking NDIS (1) black hat briefings b l
37 eEye BootRootKit – NDIS Backdoor a
• Hook function checks received packets for signature c – ethFilterDprIndicateReceivePacket sees all incoming frames
– arg_4 0 8 0C is pointer to Ethernet frame data k – arg_4 0 8 14 is frame size – Check offset 55h within frame for ‘eBR\xEE’ signature • Should be beyond IP and TCP/UDP headers, even with options • If present, execute code directly from frame at offset 59h h
• For large payloads, send “mini-payloads” to construct code a – SharedUserData (FFDF0000h) is universal and writable, and visible in user-land at 7FFE0000h t b r
Demonstration 38 i e
• From a floppy disk f • From a CD-RW i • Via network boot n g s Look for the blue smiley!
digital self defense 40 39 digital self defense digital kernel? little something extra for those who thought this talk little something extra for those who – without entering the You can perform raw disk operations – not an NT kernel vulnerability! It’s – It’s... A still be right) would be entirely boring... (you may Did you know: Adapt for more traditional Adapt for more traditional rootkit functionality of retaining execution potential Explore other methods hook-based patching besides INT 13h media USB storage and other bootable Investigate bootable • • • • • Bonus Material! To-Do black hat briefings b l
41 IOPL Technique a c k It’s a Feature, Not a Vulnerability h a t b r
IOPL Technique – Overview 42 i e
• EFlags contains an IOPL (I/O Privilege Level) field
– CPL <= IOPL (numerically less; greater privileges) can use: f • IN / INSB / INSW / INSD • OUT / OUTSB / OUTSW / OUTSD
• CLI / STI i – Only ring 0 can modify IOPL n
• Some CSRSS threads run with IOPL=3 (prior to 2003)
– These threads can be hijacked, or g – NtSetInformationProcess(ProcessUserModeIOPL) • Must have SeTcbPrivilege
– Either way requires SYSTEM-equivalent privileges s
digital self defense 44 43 ”) or loading a driver MOV AL, 0FEh / OUT 64h, AL MOV AL, 0FEh , [randnut] digital self defense digital Error, EIP, CS, EFlags, ESP, SS EIP, CS, EFlags,SS ESP, – Fault: – IRQ: address < < address MmUserProbeAddress? • ...And we can violently reboot (“ •an to get EIP exception / IRQ interrupt / Could a spurious software •handlers code EIP CPU to push error after Some fault expect • DMA required, No no IRQs generated, etc. •sample code, see [Kaze] For in References • Evade anti-virus boot sector protection? • Evade system integrity assurance software? • Defeat machine state preservation software? • Fun way to install eEye BootRootKitdrive hard a on ZwSystemDebugControl – modified... Arbitrary disk contents can be – Much harder to monitor than “\Device\PhysicalMemory”, – So what? – transfers DMA has provisions for memory-to-memory – PIC can be reprogrammed – IDE drives with only port I/O Possible on Could it allow kernel subversion? Allows low-level disk access using port I/O Allows low-level • • IOPL Technique Technique IOPL – Local Kernel Backdoor? IOPL Technique IOPL Technique –Access Disk black hat briefings b l
45 References a
Brown, Ralf. Ralf Brown’s Interrupt List. http://www.cs.cmu.edu/~ralf/files.html c
ECMA. Standard ECMA-119: Volume and File Structure of CDROM for Information Interchange. http://www.ecma- international.org/publications/files/ECMA-ST/Ecma-119.pdf
Intel Corporation. Preboot Execution Environment (PXE) Specification, Version 2.1. k ftp://download.intel.com/labs/manage/wfm/download/pxespec.pdf
Kaze
NTFS.com. “Hard Drive Partition – Partition Table.” http://www.ntfs.com/partition-table.htm h
[email protected]. “Multiple WinXP kernel vulns can give user mode programs kernel mode privileges.” http://lists.grok.org.uk/pipermail/full-disclosure/2004-February/017545.html
Russinovich, Mark. “Inside the Boot Process, Part 1.” a http://www.windowsitpro.com/Article/ArticleID/3952/3952.html
Stevens, Curtis E., and Stan Merkin. “El Torito” Bootable CD-ROM Format Specification, Version 1.0. http://www.phoenix.com/NR/rdonlyres/98D3219C-9CC9-4DF5-B496- A286D893E36A/0/specscdrom.pdf t b r
Questions? 46 i e f i n g s Questions? Comments? E-mail me!
digital self defense