Windows Internals: fuzzing, hijacking and weaponizing kernel objects

Windows Internals: fuzzing, hijacking and weaponizing
Ot´avio Augusto A. Silva
at
NullByte 5a. Ed.
10 Nov. 2018
Ot´avio Augusto A. Silva (LASCA-Unicamp) Windows Internals 10 Nov. 2018 1 / 35

Agenda
1 Introduction
Context
Overview
2 Kernel - Attacks
3 Old 0day
4 D.D 0day hunt

1 Introduction
Context
Overview
2 Kernel - Attacks
3 Old 0day
4 D.D 0day hunt

Introduction
In the last episode...
What is Windows 10?
It’s a Windows... means retro-compatibility.
New approach in a hybrid kernel.
Sanitized “sandboxes” for systems process and “critical user process”.
Enforced security behavior that were optional until Windows 8.1.
More obscure (Nt/Sys) internals.
TPM1-2 (Trusted Platform Mode), Device Guard etc.
Forced Updates
A lot of new features were added to ensure that the user will not screw
(less) with the system.

Overview
Device Guard
Whitelists parts of kernel code with Code Integrity (CI).
Restrict Windows to only authorized apps from Windows Store.
Also restrict execution only for signed with Microsoft Certiﬁcate exe.
Memory is hardened against attacks through the use of Hypervisor
Code Integrity (HVCI).
Applies Virtualization Based Security (VBS),using Hyper-V.
Those restrictions were never planned to a standard user, who remains
executing ﬁles brought from the Internet. Using the regular Win/NtApia
a
WinAPI is documented and open for directly calls. NtApi is what WinAPI
“uses” internally.

Overview
Virtualization Based Security (VBS)
“VBS uses software and hardware enforced mechanisms to create an
isolated, hypervisor-restricted, specialized subsystem for storing, securing,
transferring, and operating other sensitive subsystems and data.”
Uses Model Speciﬁc Registers (MSRs) to, among other things, enable
Secure Virtual Machine Enable (SVME) bits (aka. Hyper-V with smaller
scale virtualization).
Using:
CPU virtualization extensions; Intel VT or AMD-V.
Input–Output Memory Management Units; such as VT-d or
AMD-IOV.
Second Level Address Translation.

Recap: User-level attacks
Abusing Windows internals
Forwarding symbol resolution to a later stage in the execution, to
avoid user-side API hooking. Ex.:NtOpenProcess symbol in ntdll.dll.
Manual mapping a DLL, doing the work of a loader to inject code
Thread hijacking an external process’s thread to execute code (thread
I.P to code cave).
Sum it :)
Injecting a rogue DLL onto another process by hijacking one of its threads
and directly mapping the DLL in the process memory. KiInjectora?
a
https://github.com/otavioarj/KiInjector

Overview
Protected Process Light(PPL)
What is PPL?
Kernel “ﬂag”a into EPROCESS struct.
Protection that avoids user handles to it; System permission isolation
(can’t touch it).
Apply code integrity; only loads/runs signed code after launching;
PE32/+ to process.
A device driver must ﬂag a process (service) as PPL, it also claim the
level of code signing (3rd/MS).
No code injection, DLL hijacking etc. right?
Let’s make a tour into Win10’s process hierarchy and “isolation”.
a
W10 build ≥ 15063 added in kernel code sign check

Protected Process Light(PPL)
Is by all means an anti-malware enchantment added into Windows 8.1 to
protected system process and “special” services (likely A/V and DRM).

Overview
Win LPE?
UACMe:
https://github.com/hﬁref0x/UACME

Overview
Make an assurance: Windows UAC can be bypassed. So what an Admin
CAN’T do?
All the security mechanism listed before are just there to restrain the
Admin. Why? Rootkit.
MS reinforce its kernel isolation and control so hard, that A/V can’t hook
ANY kernel mechanism anymore. KPP scene...
Kernel Patch Protection
A.k.a Patch Guard, added in x64 editions of Windows(XP), to enforce
restrictions on what structures d.drivers cannot modify.

Kernel Patch Protection
It works by periodically checking protected system structures in the kernel have
not been modiﬁed.
Avoid modify/use:
system service tables.
the interrupt descriptor table.
the global descriptor table.
use kernel stacks not allocated by the kernel.
write code within the kernel, HAL or NDIS kernel libs.
Thus it doesn’t oﬀer any protection against one d.driver patching another.
It relies on security by obscurity and misleading symbol, using a mutate
algorithm to deploy into memorya
a
out of kernel phy. memory

1 Introduction
2 Kernel - Attacks
3 Old 0day
4 D.D 0day hunt

Kernel - Attacks
Ender game
Even with Admin access, a user can’t mess with kernel. Unless he have a
W10 kernel 0day, which cost ALOT.
Suppose one wants pretty hard to manipulate a protected process(PLLa),
e.g A/V, A/C, DRM. He have to build a kernel module and buy a
certiﬁcate from MS.
a
https://github.com/Mattiwatti/PPLKiller
Windows 10 have Signed Driver Enforcement... A/V,A/C and DRM
software usually check loaded drivera against a remote chain of trust. No
local certiﬁcate addition.
a
They also checks debug boot and some old version of vul. d.d

Attacks
RE-Starting the game :)
Direct Kernel Object Manipulation (DKom): a.k.a touch the kernel trough
user level, by hitting some trust entity, e.g. device driver.
DKom isn’t the unique way to manipulate a protected process, handle
stealing is easier and faster (one doesn’t need to R.E a device driver...).
But DKom always work, and trough kernel is cool :)
It relies on the manipulation of some kind of d.driver interface with the
kernel; usually trough I/O control (known as IOCTL).
Manipulation by a ﬂaw in the d.driver, or permission (wrong) management
in the device/end-point within user level.

Attacks
Windows drivers have an important interface with userlevel: I/O Request
Packets (IRPs).
IRPs are sent to a driver when a particular operation occurs on the driver’s
device object, e.g: DeviceDDevice.
The end interfaces which IRPs are sent: Major Functions as open/close,
read/write, and I/O control (IOCTL).
This interface is created at DriverEntry with IoCreateDevice and then
linked (user-kernel services) with IoCreateSymbolicLink.
Then the rest is a list of pointers to (Major Func.) that executes inside the
kernel; kernel interface visible into user level?

Devices?

ACLs?

Attacks
Many d.driver doesn’t register restrict ACL for its device endpoint,
meaning that unprivileged user can access it; privilege escalation at least....
Or simply a d.driver have a ﬂaw that can be exploited to manipulate kernel
pages,phy. memory or even d.driver pointers! Kernel arbitrary code
execution.
Dkom usually demands that the exploit implements some kernel function
to operates the kernel object through d.d functions.
Example: d.d have a function that allows one to read cr3 register, allowing
access to page directory and so, memory pages to be iterated through d.d
functions ;)

Attacks
We have a lot famous examples:
Capcom.sys: has an ioctl that disables SMEP (Supervisor Mode
Execution Protection Enable)a and calls a provided function pointer
(shell code?!), and sets SMEP back.
ASMMAP.sys: ioctls that map or unmap to the calling process’
address space ANY PART OF PHYSICAL MEMORY, with
READ/WRITE permissions.
WinNT/Turla VBoxDrv.sys: a set of ioctl and “magic word” for VBox
d.d API, that allows to read kernel symbols tabled and write to
speciﬁc regions (DSE)b.
a
If set, execution of code in a higher ring generates a fault, KPPable.
b
Driver Signature Enforcement.

Attacks
My contribution :P
CVE2018-8060 and 2018-8061 for HWiNFO AMD64 Kernel driver version
8.98 and lower, which allows unprivileged user to send IOCTL to device
driver.
Dispatching IOCTL 0x85FE2608 with in-buﬀer containing a physical
memory address, size and a virtual memory address, results in the driver
mapping the physical memory and reading it, copying its content to the
virtual address.a
a
Poc: https://github.com/otavioarj/SIOCtl
Basically if a company made d.d for control it’s product using “proprietary
API”, you probably got a new d.d IOCTL approach; bad practices is pretty
common.

1 Introduction
2 Kernel - Attacks
3 Old 0day
4 D.D 0day hunt

Old 0day
All the d.d with flaws listed here were exploited and widely spread. But
continues to work!!
One can right now download a vulnerable Nvidia d.d, even without a
Nvidia GPU, and exploit it to manipulate the kernel; an “old 0day” still
usable.
Remember how?
MS automatically sign OEM d.d; no code review!!
OEM uses the same certificate for multiples d.d; no vulnerable d.d
will have its certificate revoked!

Old 0day
Mitigations
It’s not always a double rainbow:
some A/Vs blocks old d.d which isn’t used anymore; only CPUID and
Process Hacker were blocked testing in Avast, Avira and AVG :)
A/C and DMR were more aggressive, they doesn’t care if you’re using
a old d.d, if they d.d loads and detects a blacklisted d.d loaded;
unload itself and alarm a user service.
some A/Ca uses high sophisticated approach; uses
ObRegisterCallbacks of Windows’s kernel API, to check for rogue d.d.
a
BattlEye, Lord of Bans
What about hutting your own d.d IOCTL 0day? Might work :)

1 Introduction
2 Kernel - Attacks
3 Old 0day
4 D.D 0day hunt

D.D 0day hunt
Be advised, it’s simply a R.E task. Bunch of senseless code, assembly and
a lot of pain.
Any debug which can read Windows Driver Dev. Kit symbols can be used;
I recommend IDA Pro or x64dbg :).
We are interested only into d.d which creates an IO device, so this cut
some fat from analysis; hunt ﬁrst of all IoCreateDevice.
There is no need to escalate permissions, so IO devices with
wrong/ineﬃcients permissions will not be a thing.
Winobj can be used to locate devices created with bad ACL; a.k.a privilege
escalation approach

D.D 0day hunt
So what?
IOCTLs code usually are clear when R.E:“cmp register, IOCTL”.
Provide enough data to follow the right ﬂux, and you can
trigger/reach d.d operations
Mostly all IOCTL moves kernel memory (virtual) to another
k.memory; likely a memncpy.
Lazy?
What about a fuzzer capable of ﬁnd IOCTL from a d.d, detect its mode of
operationa with a timed and guided test case tunning, including output
analysis?
a
METHOD BUFFERED, X DIRECT or NEITHER

https://github.com/otavioarj/SIOCTLBF

Demo

Questions?

Windows Internals: fuzzing, hijacking and weaponizing kernel objects

Recommended

Recommended

More Related Content

What's hot

What's hot (20)

Similar to Windows Internals: fuzzing, hijacking and weaponizing kernel objects

Similar to Windows Internals: fuzzing, hijacking and weaponizing kernel objects (20)

More from Nullbyte Security Conference

More from Nullbyte Security Conference (14)

Recently uploaded

Recently uploaded (20)

Windows Internals: fuzzing, hijacking and weaponizing kernel objects