SlideShare a Scribd company logo

Security research over Windows #defcon china

•Download as PPTX, PDF•
•
P
Peter Hlavaty

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.

Related slideshows

When is something overflowing
When is something overflowingWhen is something overflowing
When is something overflowing
 
Guardians of your CODE
Guardians of your CODEGuardians of your CODE
Guardians of your CODE
 
Ice Age melting down: Intel features considered usefull!
Ice Age melting down: Intel features considered usefull!Ice Age melting down: Intel features considered usefull!
Ice Age melting down: Intel features considered usefull!
 
1 of 33
Security Research over Windows [ kernel ]
$whoami • @zer0mem ~ Peter Hlavaty • Senior Security Researcher at KeenLab, Tencent • MSRC100, Pwn2Own • Focus : kernel / hyperv / mitigations • sometimes talk somewhere .. • wushu player +- 
Sandbox • Restrict resources of target ( process ) • #syscalls • file system • registry • inter-process interaction • Different integrity levels • Untrusted • App Container • Low • Medium, ..
sandbox attack surface +- IPC ~ Broker vs worker Windows ~ kernel syscalls RPC ~ inter process communication 3rd elements ~ Windows Defender ( AV in general )
Windows kernel ~ attack surface w32k ntoskrnl tm, afd, ..
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
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++ ?
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 ?
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
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
Native code exec But, OK .. you got a bug, what’s next ?
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
..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
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
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
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 ?
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
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
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
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
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
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
Sandbox++ When kernel is not a boundary
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/
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
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
Bug is just the start line But even though .. how to ?
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
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!
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, .. ?
Other windows cool targets ~ kernel • Sockets • UoW ( ubuntu on windows ~ WSL ) • SMB (v1, v2, v3) • HyperV ( user, kernel, hypervisor ) • VhdParser • RDP • .. .sys ?
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...
Thanks! Q & A

More Related Content

Security research over Windows #defcon china

  • 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 )
  • 5. Windows kernel ~ attack surface w32k ntoskrnl tm, afd, ..
  • 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
  • 11. Native code exec But, OK .. you got a bug, what’s next ?
  • 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
  • 23. Sandbox++ When kernel is not a boundary
  • 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...