Windows Kernel Exploitation : This Time Font hunt you down in 4 bytesPeter Hlavaty
In our recent work we targeted also win32k, what seems to be fruit giving target. @promised_lu made our own TTF-fuzzer which comes with bunch of results in form of gigabytes of crashes and various bugs. Fortunately windows make great work and in February most of our bugs was dead - patched, but not all of them…
Whats left were looking as seemingly unexploitable kernel bugs with ridiculous conditions. We decided to check it out, and finally combine it with our user mode bug & emet bypass. Through IE & flash we break down system and pointed out at weak points in defensive mechanism.
In this talk we will present our research dedicated for pwn2own event this year. We will describe kernel part of exploit in detail*, including bug description, resulting memory corruption conditions & caveats up to final pwn via one of our TTF bugs.
Throughout the talk we will describe how to break various exploit mitigations in windows kernel and why it is possible. We will introduce novel kernel exploitation techniques breaking all what stands { KASLR, SMEP, even imaginary SMAP or CFG } and bring you SYSTEM exec (from kernel driver to system calc).
* unfortunately bug was not fixed at the time of talk, so we do not exposed details about TTF vulnerability, and we skipped directly to some challenges during exploitation, and demonstrate how OS design can overpower introduced exploit mitigations.
You didnt see it’s coming? "Dawn of hardened Windows Kernel" Peter Hlavaty
Past few years our team was focusing on different operating systems including Microsoft windows kernel. Honestly our first pwn at Windows kernel was not that challenging. Number of available targets with friendly environment for straightforward pwn, from user up to reliable kernel code execution.
However, step by step, security policies continue to evolve, and it becomes more troublesome to choose ideal attack surface from various sandboxes. In addition, what steps to follow for digging security holes is highly dependent upon the chosen target. In general, a few common strategies are available for researchers to choose: e.g choose “unknown” one which hasn’t been researched before; Select well fuzzed or well audited one, or research on kernel module internals to find “hidden” attack surfaces which are not explicitly interconnected. In the first part of the talk we introduce our methodology of selecting, alongside with cost of tricks around to choose seemingly banned targets, illustrated by notable examples.
After getting hands on potential bug available from targeted sandbox, it is time for Microsoft windows taking hardening efforts to put attacker into corner. Strong mitigations are being introduced more frequently than ever, with promising direction which cuts lots of attack surface off, and a several exploitation techniques being killed. We will show difficulties of developing universal exploitation techniques, and demonstrate needed technical level depending on code quality of target. We will examine how different it becomes with era of Redstone and following versions even with those techniques and good vulnerability in hand. How it changed attacker landscape and how it will (and will not) kill those techniques and applications. However will it really change the game or not?
Recently our team researched various ntos subsystem attack vectors, and one of the outputs we will present in our talk. DeathNote as our internal code name to this component, which resides in Microsoft Windows kernel, hiding behind different interfaces and exposed to user differently.
What can goes bad with it?
Basically two kinds of problems, one is syscall handling via direct user interaction. We will describe how to obtain basic understanding of what's going on, how it interacts with other components and what is its purpose. With those knowledge we will dig deeper how to make more complex fuzzing logic to cause enough chaos that will end up in unexpected behaviors in Windows kernel, and demonstrate some of them.
And as for second, as it hints from title, this module does bit of data parsing, so we will dive deep into internals, pointing out some available materials, and move on to reverse engineered structures and internal mechanism. We will show how some tricks can outcome with various results, and how structured approach can expose more problems than is expected.
Compromising Linux Virtual Machines with Debugging MechanismsRussell Sanford
This presentation covers utilizing VMwares (GDB) debugging protocol to invasive inject commands into a Linux-x64 target. Automatic detection of kernel API is performed to locate _vmalloc & call_usermodehelper* functions across all 3x and 4x kernels.
A short introduction on how functions work. Functions are the building blocks of any modern programming language. This tutorial shows you how functions are implemented and how the process stack plays an important role in supporting functions.
Windows Kernel Exploitation : This Time Font hunt you down in 4 bytesPeter Hlavaty
In our recent work we targeted also win32k, what seems to be fruit giving target. @promised_lu made our own TTF-fuzzer which comes with bunch of results in form of gigabytes of crashes and various bugs. Fortunately windows make great work and in February most of our bugs was dead - patched, but not all of them…
Whats left were looking as seemingly unexploitable kernel bugs with ridiculous conditions. We decided to check it out, and finally combine it with our user mode bug & emet bypass. Through IE & flash we break down system and pointed out at weak points in defensive mechanism.
In this talk we will present our research dedicated for pwn2own event this year. We will describe kernel part of exploit in detail*, including bug description, resulting memory corruption conditions & caveats up to final pwn via one of our TTF bugs.
Throughout the talk we will describe how to break various exploit mitigations in windows kernel and why it is possible. We will introduce novel kernel exploitation techniques breaking all what stands { KASLR, SMEP, even imaginary SMAP or CFG } and bring you SYSTEM exec (from kernel driver to system calc).
* unfortunately bug was not fixed at the time of talk, so we do not exposed details about TTF vulnerability, and we skipped directly to some challenges during exploitation, and demonstrate how OS design can overpower introduced exploit mitigations.
You didnt see it’s coming? "Dawn of hardened Windows Kernel" Peter Hlavaty
Past few years our team was focusing on different operating systems including Microsoft windows kernel. Honestly our first pwn at Windows kernel was not that challenging. Number of available targets with friendly environment for straightforward pwn, from user up to reliable kernel code execution.
However, step by step, security policies continue to evolve, and it becomes more troublesome to choose ideal attack surface from various sandboxes. In addition, what steps to follow for digging security holes is highly dependent upon the chosen target. In general, a few common strategies are available for researchers to choose: e.g choose “unknown” one which hasn’t been researched before; Select well fuzzed or well audited one, or research on kernel module internals to find “hidden” attack surfaces which are not explicitly interconnected. In the first part of the talk we introduce our methodology of selecting, alongside with cost of tricks around to choose seemingly banned targets, illustrated by notable examples.
After getting hands on potential bug available from targeted sandbox, it is time for Microsoft windows taking hardening efforts to put attacker into corner. Strong mitigations are being introduced more frequently than ever, with promising direction which cuts lots of attack surface off, and a several exploitation techniques being killed. We will show difficulties of developing universal exploitation techniques, and demonstrate needed technical level depending on code quality of target. We will examine how different it becomes with era of Redstone and following versions even with those techniques and good vulnerability in hand. How it changed attacker landscape and how it will (and will not) kill those techniques and applications. However will it really change the game or not?
Recently our team researched various ntos subsystem attack vectors, and one of the outputs we will present in our talk. DeathNote as our internal code name to this component, which resides in Microsoft Windows kernel, hiding behind different interfaces and exposed to user differently.
What can goes bad with it?
Basically two kinds of problems, one is syscall handling via direct user interaction. We will describe how to obtain basic understanding of what's going on, how it interacts with other components and what is its purpose. With those knowledge we will dig deeper how to make more complex fuzzing logic to cause enough chaos that will end up in unexpected behaviors in Windows kernel, and demonstrate some of them.
And as for second, as it hints from title, this module does bit of data parsing, so we will dive deep into internals, pointing out some available materials, and move on to reverse engineered structures and internal mechanism. We will show how some tricks can outcome with various results, and how structured approach can expose more problems than is expected.
Compromising Linux Virtual Machines with Debugging MechanismsRussell Sanford
This presentation covers utilizing VMwares (GDB) debugging protocol to invasive inject commands into a Linux-x64 target. Automatic detection of kernel API is performed to locate _vmalloc & call_usermodehelper* functions across all 3x and 4x kernels.
A short introduction on how functions work. Functions are the building blocks of any modern programming language. This tutorial shows you how functions are implemented and how the process stack plays an important role in supporting functions.
Check out my blog : https://oalieno.github.io/2019/06/07/security/pwn/rootkit/
Introduction and implementation of rootkit. Targeting linux kernel 5.x.x.
21. Return to dl_resolve
• DT_SYMTAB
• address of symbol table
• Symbol table
• 存的 struct 為 Elf32_Symol
• st_name
• index of string table
• st_value ( symbol value )
• st_size ( symbol size )
• st_info ( symbol type and binding )
• st_other ( symbol visibility )
• st_shndx ( section index )
21