Past several years Microsoft Windows undergo lot of fundamental security changes. Where one can argue still imperfect and bound to tons of legacy issues, on the other hand those changes made important shifts in attacker perspective. From tightened sandboxing, restricting attack surface, introducing mitigations, applying virtualization up to stronger focus even on win32k. In our talk we will go trough those changes, how it affects us and how we tackle them from choosing targets, finding bugs up to exploitation primitives we are using. While also empathize that windows research is not only about sandbox, and there are many more interesting target to look for.
2. $whoami
• @zer0mem ~ Peter Hlavaty
• Senior Security Researcher at KeenLab, Tencent
• MSRC100, Pwn2Own
• Focus : kernel / hyperv / mitigations
• sometimes talk somewhere ..
• wushu player +-
3. Sandbox
• Restrict resources of target ( process )
• #syscalls
• file system
• registry
• inter-process interaction
• Different integrity levels
• Untrusted
• App Container
• Low
• Medium, ..
4. sandbox attack surface +-
IPC ~ Broker vs worker
Windows ~ kernel syscalls
RPC ~ inter process communication
3rd elements ~ Windows Defender ( AV in general )
6. w32k attack surface hardening
4 years ago
• Fonts
• TTF emulation in kernel
• Loading custom fonts
• GDI
• 6+ different kernel objects
• *huge* source of UAF, overflows, …
• EMF – *remote*
• User
• User mode callbacks machinery
now
• Fonts
• TTF emulation in kernel user mode
• Sandboxes low priv proc for custom
• GDI -> restricted/no mode
• 6+ different kernel objects
• *huge* source of UAF, overflows, …
• EMF – *remote* -> disabled by def
• User -> restricted/no mode
• User mode callbacks machinery
7. w32k security hardening
• Restricted resources for exploitation
• No resources if DisableW32kSystemCalls flag on
• Type isolation
• Tactical mitigations, f.e. tagWnd
• bugs--
• Refactored w32k ( win32k -> win32kfull + win32kbase )
• this also left/brings lot of bugs, but showing importance of cleaning up mess
• Security researchers community support ( msrc100, insider bounties, .. )
• Internal fuzzing++ ?
8. w32k still alive
• DirectX
• w32k – user callbacks
• Small parts of GDI + DComposition
• New syscalls keep added in new builds
• ~ no w32k in your target ?
• w32k is somehow essential of GUI app
• Bridge from your target to part of app which have access
• Perhaps you can attack another part of app with w32k on ?
9. ntos attack surface
• TM + CLFS
• ‘hidden syscalls’
• CLFS : Lockdown for sandboxed processes!
• Well finally, heavy parsing in kernel mode..
• Without CLFS backup it is very simple logic
• However nice connections ~ Manager + Transaction + Enlistment + Resource
• (A)LPC, Pipe, Sockets, Registry hives
• Good amount of logic there
• In SDL quite some time, crucial part of windows kernel!
• Memory management, Sync, ..
• + : lots of syscalls!
• - : logic you can alter is way too simplistic
10. RPC – user processes
• Any process has opened ALPC port
• Everybody needs to have opened port at least to csrss.exe !
• Mostly ‘unknown’ area ~ previous research :
• https://hakril.net/slides/A_view_into_ALPC_RPC_pacsec_2017.pdf
• https://recon.cx/2008/a/thomas_garnier/LPC-ALPC-slides.pdf
• NtAlpc* ~ undocumented
• http://alex-ionescu.com/Publications/SyScan/syscan2014.pdf
• COM using ALPC at the background
• C++ inter-process interface
12. Mitigations on the rise
• Past years Windows invest heavily into breaking attack surface and
techniques !
• Guards :
• (k)CFG
• HVCI
• VBS
• ACG
• CIG
• Jit OoP
• ..
w32k + clfs
lockdown + filter
ntoskrnl filter via
ACL
Mitigation against
native code exec
Type Isolation
Tactical mitigation
13. ..G, ..G, ..G .. wut ?
• Lots of guards in windows ;)
• Must read :
• https://cansecwest.com/slides/2017/CSW2017_Weston-
Miller_Mitigating_Native_Remote_Code_Execution.pdf
• https://github.com/Microsoft/MSRC-Security-
Research/blob/master/presentations/2018_02_OffensiveCon/The%20Evolution%20
of%20CFI%20Attacks%20and%20Defenses.pdf
• How those are enabled for sandboxing :
• SetProcessMitigationPolicy
• PROC_THREAD_ATTRIBUTE_MITIGATION_POLICY of UpdateProcThreadAttribute
14. CFG
• _guard_check_icall
• More about CFG :
• https://blog.trendmicro.com/trendlabs-security-intelligence/exploring-control-flow-guard-in-windows-10/
• This is nice article :
• https://www.endgame.com/blog/technical-blog/disarming-control-flow-guard-using-advanced-code-reuse-attacks
• Covering also mini COOP ;) – check that out
15. RFG
FS:: delta
return return
call [callee]
mov r11, [rsp]
..
mov fs::[rsp], r11
Data
Stack
Control
Stack mov r11, fs::[rsp]
cmp ..
jnz ..
ret
16. RFG ~ pulled down, but CET ( check CET! )
• 2 stacks : Control + Data
• Control stack no pointer in user mode
• It is OK to be write-able ~ therefore with write primitive you can write there
• But problem : how to find it ? => no leaks == no way ?
• At each function prolog store return address also to Control stack
• At each function epilogue check if ControlStack[rsp]==DataStack[rsp]
• Aka return address match
• BRILIANT IDEA + DESIGN = no compatibility issues, can plug it right now!
• Only 5 instruction per function!
• Key Problems :
• Race condition -> could be done in stable way
• Secret based ~ what if is possible to reveal address of control stack without pointer leak ?
17. CIG + ACG + Jit OoP : In short
• Code Integrity (CIG) ~ only signed images can be loaded
• Ok but we can do RWX + shellcode
• Arbitrary code guard (ACG) -> no you can not ..
• No RWX page same time!
• X pages -> in fact you can not VirtualProtect to Exec* anymore
• JIT : but I need it!
• Nope … nope .. nope
• Process can not have RWX pages nor from Data page make Code page
• Therefore only different process can do it for you
• Browser : Jit Process -> Worker process
18. Type Isolation
• Important exploit primitives consists :
• Structure with control and data parts
• Control : pointers, sizes
• Data : controlled data by user
• Outcome :
• Data or size overflow lead to full compromise of domain
• Mitigation :
• Separate Control & Data part of structure to two different places
• Crucial : data should not reach control part ~ page guards / different pools
19. Header ( size .. )
Data
Data
Header ( size .. )
Header ( size .. )
Data
Data
Header ( size .. )
AFTERBEFORE
Overflow
Overlap
https://blog.quarkslab.com/reverse-engineering-the-win32k-type-isolation-mitigation.html
https://github.com/Microsoft/MSRC-Security-Research/tree/master/presentations/2018_04_OPCDE
20. Tactical mitigation
• prevalent methodology of misusing object for arbitrary read / write
• Start with limited read/write
• Boost it to full read/write to domain
• Usually pivot-worker schema
• Tactical mitigation == Break particular techniques, one by one!
• How : Introduce safe – checks
• Buffer ranges
• Pool limitation
• Outcome : need to chain *limited* read/write primitives
• Crucial :
• safe boundaries must not be reachable by our limited write
• broken for tagWnd ~ check this nice references :
https://github.com/MortenSchenk/tagWnd-Hardening-Bypass/blob/master/tagWnd/tagWnd/tagWnd.cpp
https://improsec.com/blog/hardening-windows-10-with-zero-day-exploit-mitigations-under-the-microscope
21. Tactical mitigation or just nice check ?
• Triaging one of our bug
• We investigated possible exploitability
• In one of the branch there was interesting check
• Guess what is it
22. Therefore..
• Theory
• No W^X memory anymore
• No Arbitrary modules
• No @rip hijack
• No return address hijack
• No Overflows ( buffer or size/counters ) exploitable
• No/Limited Read/Write primitive
• Practice
• Not there yet, most of those bypass-able by design limitations
• However showing interesting shift towards security, doesn’t it ?
• especially memory corruptions
24. virtualization
• HyperV technology
• VM machine
• Well Security designed!
• Legacy striped
• (relatively) small ( + heavily audited ) attack surface
• Mitigations applied
• WDAG applying HyperV technologies
• Another layer of sandbox introduced for edge
• And not only for edge!
https://cloudblogs.microsoft.com/microsoftsecure/2018/04/19/introducing-windows-defender-system-guard-
runtime-attestation/
25. vmwp overview
• What ?
• User mode process on host side responsible for running guest-partition
• Minimum legacy
• IO devices
• No complex structures ( in IO )
• Minimal interaction ( no Drag&Drop, basic session by default, .. )
• Generation2 way to go, however Generation1 still default
• Clean design
• All mitigations
• Sandboxed!
• pwn vmwp complexity ~ remote pwn
26. Successful attack in the future (?)
Get a bug in
remote target
( browser, .. )
Get RCE or
COOP-ish
style control
Escape
sandbox
Get bug in
kernel
Bypass proc
restrictions or
get RCE
(coop-ish
style is OK)
Get a bug in
virtualization
Bypass
mitigations in
virtualization
target
pwn
27. Bug is just the start line
But even though .. how to ?
28. How to approach
• Understanding of attack surface
• Windows landscape
• Understanding of target
• Reverse engineering & internals
• Make use of technologies :
• IntelPt (+ QemuPt)
• windbg + TTD
• Qemu + KVM
• Hypervisors ( tooling + automatization )
• BochsPwn reloaded / DigTool alike approaches
• Make use ( and proper understanding ) of “state of the art” tools
• syzkaller
• (k)AFL
• .. then make your own patches / tools / plugins
29. Fuzzing vs Eye-balling
• Fuzzing :
• Easy to make dummy fuzzer
• Easy to overengineer fuzzer and kill its randomness
• Eyes :
• You can easily miss trivial bugs
• Hard to comprehend complex logic
• Why not combine both ?
• Make random-enough fuzzing
• Inject ( to fuzzer ) knowledge from auditing-code
• Use fuzzer to check some complex logic for you + automate it!
30. RCE
• RCE is not all about browsers!
• Microsoft Office
• SMB
• SMB v1 non default ~ big attack surface
• non auth attack vector seems finally heavily audited ?
• But was kAFL alike fuzzing approach applied ?
• Most modern apps connect over internet
• Skype, Slack, games, .. ?
31. Other windows cool targets ~ kernel
• Sockets
• UoW ( ubuntu on windows ~ WSL )
• SMB (v1, v2, v3)
• HyperV ( user, kernel, hypervisor )
• VhdParser
• RDP
• .. .sys ?
32. Conclusions
• Attack surface reduction is most effective
• Sandbox becoming solid boundary
• However not applied everywhere
• Native code execution mitigations on the raise
• But bypass-able by nature ( architecture + legacy )
• Finding & exploiting bugs becoming more challenging
• …but no that hard as it may be...
![Security Research over
Windows
[ kernel ]](https://image.slidesharecdn.com/securityresearchoverwindowsdefconcnzer0mem-181008220326/85/Security-research-over-Windows-defcon-china-1-320.jpg)
