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.
IDA Vulnerabilities and Bug Bounty by Masaaki ChidaCODE BLUE
IDA Pro is an advanced disassembler software and often used in vulnerability research and malware analysis. IDA Pro is used to analyse software behavior in detail, if there was a vulnerability and the user is attacked not only can it have impact in a social sense but also impact legal proceedings. In this presentation I will discuss the vulnerabilities found and attacks leveraging the vulnerabilities and Hex-rays's remediation process and dialogue I had with them.
http://codeblue.jp/en-speaker.html#MasaakiChida
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.
IDA Vulnerabilities and Bug Bounty by Masaaki ChidaCODE BLUE
IDA Pro is an advanced disassembler software and often used in vulnerability research and malware analysis. IDA Pro is used to analyse software behavior in detail, if there was a vulnerability and the user is attacked not only can it have impact in a social sense but also impact legal proceedings. In this presentation I will discuss the vulnerabilities found and attacks leveraging the vulnerabilities and Hex-rays's remediation process and dialogue I had with them.
http://codeblue.jp/en-speaker.html#MasaakiChida
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.
4. • We focus on ELF (Executable and Linking
Format)
• What’s happened when we execute an elf file.
• ex : ./hello
How programs get run
5. Overview of the workflow (static linking)
./hello
fork()
execve(“./hello”,*argv[],*envp[])
sys_execve()
do_execve() search_binary_handler()
load_elf_binary()
_start
main
kernel mode
user mode
6. Overview of the workflow (dynamic linking)
./hello
fork()
execve(“./hello”,*argv[],*envp[])
sys_execve()
do_execve() search_binary_handler()
load_elf_binary()
ld.so
_start
__libc_start_main _init
kernel mode
user mode
main
7. • sys_execve()
• 檢查參數 ex: argv , envp
• do_execve()
• 搜尋執⾏行檔位置
• 讀取執⾏行檔前 128 byte 獲取執⾏行檔的資訊
• ex: magic number
How programs get run
9. • load_elf_binary()
• 檢查及獲取 program header 資訊
• 如果是 dynamic linking 則利⽤用 .interp 這個 section 來確定
loader 路徑
• 將 program header 紀錄的位置 mapping 到 memory 中,ex :
code segment 位置
• 將 sys_execve 的 return address 改為 loader (ld.so) 的entry
point
• static linking 下則會是 elf 的 entry point
How programs get run
10. • How program maps to virtual memory.
• 在 program header 中
• 記錄著哪些 segment 應該 mapping 到什麼位
置,以及該 segment 的讀寫執⾏行權限
• 記錄哪些 section 屬於哪些 segment
• 當 program mapping 記憶體時會根據權限的
不同來分成好幾個 segment
How programs get run
11. • How program maps to virtual memory.
How programs get run
權限
mapping 位置
segment 中有哪些 section
12. • How program maps to virtual memory.
How programs get run
other section
.data
.bss
.got.plt
.rodata
.text
.init
ELF Header
In disk In memory
kernel space
CODE VMA
DATA VMA
HEAP
STACK
R or RX
RW
0x08048000
0x0804a000
0x0804b000
0xbffff4b0
13. • ld.so
• 載⼊入 elf 所需的 shared library
• 這部分會記錄在 elf 中的 DT_NEED 中
• 初始化 GOT
• 其他相關初始化的動作
• ex : 將 symbol table 合併到 global symbol table
等等
How programs get run