Slide 1

Slide 1 text

Story of win32k: Dumb Fuzzing to Code Execution Nafiez

Slide 2

Slide 2 text

About Me •Nafiez (@zeifan) • HITB CTF Core Crew (3rd Generation, after Spoonfork & RuFI0) • Passionate in Memory Corruption • Windows Internal Fan • As long as not related to Web Hacking ☺ (allergic!)

Slide 3

Slide 3 text

Agenda •Introduction •Story of Dumb Fuzzing • Manual Auditing: Bug Hunting •Attack Vector •Real Man Kernel Fuzzing: Present and Future

Slide 4

Slide 4 text

Recap •Modern Apps use sandboxing (Windows 10) •Huge attack surface •Exploit != Malware •Memory corruption in Windows Kernel ain’t dead •Bug collisions • Internal finding, researchers, etc. •Fix & Unfix Bug

Slide 5

Slide 5 text

Demo Windows 7 SP1 – Kernel Integer Overflow (fixed on MS13-053)

Slide 6

Slide 6 text

Introduction

Slide 7

Slide 7 text

Source: https://upload.wikimedia.org/wikipedia/en/8/86/Journey_to_the_Center_of_the_Earth_Ride.jpg

Slide 8

Slide 8 text

Source: http://i-web.i.u-tokyo.ac.jp/edu/training/ss/lecture/new-documents/Lectures/17-Win32K/Win32K.pdf 1. Windows Sub-system 2. GUI infra (architecture) of the OS 3. Core Kernel a) > 950 syscalls (up to Windows 10) 4. Complex System ☺ a) Callback in Kernel Mode b) Font Parsing 5. Including: a) Windows Manager (USER) b) Graphics Device Interface (GDI) c) DirectX

Slide 9

Slide 9 text

Story of Dumb Fuzzing

Slide 10

Slide 10 text

Reverse Engineering •Fresh installed of Windows • Windows XP, Windows 7, Windows 8, 8.1, Windows 10 (started early this year only!) •Reversing core kernel win32k.sys • BinDiffing + IDA Pro, a little help from WinDBG (symbols FTW!) • 2 – 3 months • Manual finding > 20+ bugs (5 vulnerabilities, 2 still unfix bug, rest are DoS / non-security related) • Patch Tuesday •Move to Fuzzing

Slide 11

Slide 11 text

No content

Slide 12

Slide 12 text

Problematic •Windows APIs •Memory Layout •Interrupts •Synchronization •Paging •Driver structure •Intel Manual FTW!

Slide 13

Slide 13 text

Dumb Fuzzing • Required small amount of work to produce (Lazy Way) • Complexity of the module • Unknown functions, symbols, etc. • Things are getting harder and harder (Patch Tuesday) • Gambling with kernel • Call from User-mode to Kernel-Mode (e.g.: notepad.exe) • Single system calls • e.g.: NtUserGetDCEx • How-to-FAQ: • Menu structures • Callback • Handle • Etc.

Slide 14

Slide 14 text

Cont. •Callback functions •Scenario: 1) Creating kernel window 2) Get any pointer to the kernel window object 3) Overwrite WndProc pointer 4) Send message to window to trigger crash on WndProc (based on overwrite pointer)

Slide 15

Slide 15 text

No content

Slide 16

Slide 16 text

Bug Hunting

Slide 17

Slide 17 text

Case Study 1: Kernel Integer Overflow •Target module: Coordinate Spaces & Transformations • Scale, Rotate, Translate, Graphics Output •Two different SysCalls shared the same vulnerability • ScaleViewportExtEx() • ScaleWindowExtEx() •Both function modifies the window for a device context using the ratios formed by the specified multiplicands and divisors. •Reported in 2013, someone found it few months before and reported. Lost track of the KB ☺

Slide 18

Slide 18 text

No content

Slide 19

Slide 19 text

Cont. •There is no checking after dividing the value • It does not recognize the pattern of “Positive” or “Negative” numbers (Intel Manual explained in details) •Signed divide EDX:EAX by [ebp+Xdenom], with result stored as: • EAX = High-Level Address, EDX = Overflow. •Trivia • Sign of the remainder is always the same as the sign of the dividend. • The absolute value of the remainder is always less than the absolute value of the divisor. • Overflow is indicated with the #DE (divide error) exception rather than with the OF (overflow) flag.

Slide 20

Slide 20 text

Proof-of-Concept •The Maths • Putting all possible numbers • 0xFFFFFFFF, 0x80000000, etc. • Negative and Positive numbers • In Math, calculating “X” and “Y” axis should return any result, even remainder. • Regardless of negative or positive numbers • e.g.: 100, -1, 212, -12, 12.1 • Example equation: a = a / b * a % b •3 lines of C should be more than enough ☺

Slide 21

Slide 21 text

No content

Slide 22

Slide 22 text

No content

Slide 23

Slide 23 text

Case Study 2: Null Pointer Dereference •Trivia • Some security vendors told this bug allow REMOTE execution (bullshit!) • Local EOP != Remote Execution • Someone write fully exploitable code • Posted on exploit-db.com

Slide 24

Slide 24 text

No content

Slide 25

Slide 25 text

•1. Set SYSTIMER to 0x118 (WinSpy should be able to help) •2. Create new shape and assign ownership to specified window using CreateCaret() •3. Verify check by adding FlashWindow() function •4. The math: rand() % 0xFFFF

Slide 26

Slide 26 text

Cont. •Passed string and compare it • String passed when accessing pWnd->ppropList •Crash will trigger on GetProp() • The main idea is to passed string that will trigger memory corruption on function itself. •Lesson learned: • Remote Code execution != Local EOP • GetProp() does not handle any socket

Slide 27

Slide 27 text

No content

Slide 28

Slide 28 text

Demo Windows 7 SP1 – Local Elevation of Privileged (fixed on MS15-010)

Slide 29

Slide 29 text

Attack Vector !exploitable -v

Slide 30

Slide 30 text

•Relying on crash dumps •Re-code from Fuzzer •We need ACCESS_VIOLATION •Many exploitation tricks available • Writing exploit cost more time ☺ • I won’t explain any of it here • Token stealing, w-w-w, etc.

Slide 31

Slide 31 text

Flow of Exploitation •Some exploitation scenario: 1. Find the address of RegisterClassExWOWW 2. RegisterClassExWOWW() passing the FNID for a Menu and a WNDCLASSEX structure with a negative number for the extra bytes 3. CreateWindow() 4. SetWindowLongPtr() with a non-NULL array 5. DestroyWindow() 6. Find offset 7. Repeat steps 3-5, this time passing the actual address to overwrite minus the offset 8. Get the overwritten pointer to be called

Slide 32

Slide 32 text

No content

Slide 33

Slide 33 text

No content

Slide 34

Slide 34 text

Mitigations •Kernel ASLR •SMEP / PXN •Null Pointer •Linked-list •Pool Memory Allocator •Windows 10 • Kill everything ☹ • It was written from scratch (at least win32k.sys)

Slide 35

Slide 35 text

Real Man Kernel Fuzzing Present & The Future

Slide 36

Slide 36 text

Present •Lacked of: • Tools • Hardware • Fuzzers • Community

Slide 37

Slide 37 text

Kernel Instrumentation •j00ru from Google Project Zero released instrumentation tool • Kfetch-Toolkit •Designed to perform advanced logging of memory references in Kernel level • Relying on Bochs IA-32 Emulator •Hard to setup • It took me one month to finish the project • Modifying few modules that do not work on the latest build of requirement tools.

Slide 38

Slide 38 text

Cont. •Capability • Monitor and logging performed by kernel-mode components • Post processing • Filtering • Separation •Upon installation, the BOCHS will boot up in between 10 – 12 hours. •Combining smart fuzzer with kfetch-toolkit • Target in Kernel Level: Anti-Virus, DirectX, Audio, Video, AFD.sys, etc. •Things are getting harder, time to move to smart way ☺

Slide 39

Slide 39 text

Guide to Smart Fuzzing 1. Constant base identifier for syscall 2. Specify maximum number of parameters target syscall can take 3. Number of syscalls on each supported platform 4. Reduce / Exclude service ID from fuzzing / being trigger 5. Fuzzing iteration used to detect hang threads 6. Algorithm to generate (RDTSC FTW) 7. Invoke each and every single syscall from win32k.sys

Slide 40

Slide 40 text

The Ideas •Deployed proper Kernel Fuzzer • Targeting specific driver such as win32k.sys •Run the Fuzzer in the BOCHS machine (Windows 7, etc.) • Let the instrumentation toolkit figure it out • More crash dump will be produced ☺ • Time consuming when move the mouse or even typing keyboard •You can always run public fuzzer • e.g.: Peach Fuzzer, IOCTLbf, etc.

Slide 41

Slide 41 text

BOCHS Emulator Windows 7 (BOCHS) Fuzzer win32k.sys Kernel-Mode Fuzzer Log ☺ Hardware Specs: • Core 2 Duo • 4GB RAM • 500GB HDD • Windows 7 Instrumentation Tool User-Mode Fuzzer Fuzzer executed Sending instruction executed after fuzzed Fuzzer deployed Emulator Installed on Windows 7 or 8 Windows 7 (Physical) Windows 7 used as target OS Log will be in Physical machine Sending crash log (crash dump) Logged every single instruction executed e.g.: callback, etc.

Slide 42

Slide 42 text

No content

Slide 43

Slide 43 text

No content

Slide 44

Slide 44 text

Demo Windows 7 SP1 - Kernel Callback Exploitation, found using kfetch-toolkit

Slide 45

Slide 45 text

Bonus •Vulnerability found during fuzzing Anti-Virus

Slide 46

Slide 46 text

• Shout to DurianConf organizer and Yeh Thank you!