Bug Hunting in Hard Targets
- Developer mindset vs Adversarial mindset - Code review as a bug hunter is often different from code reviewing as part of feature change. As a bug hunter you are only focusing on how to circumvent a control or use in a way it was not intended. Learning this mindset is key
- Going Deep vs Going Wide - Researching a target there is a trade off between going deep and going wide. If you have no knowledge then going wide helps to discover potential weak areas and build up a mental model. At some point it becomes important to focus down and refine
- Target Biases - Its common to think because something is well established then there will be less bugs lurking there. However, most software is evolving and new features are constant being added. This new code is often a really good source of bugs.
- Fuzzing Enhancements - As code moves on over time, developers need to create test code. This means that often this new code misses test coverage or has no tests at all. Binary diffing, API change logs and software update analysis are a great way to extend fuzzer coverage.
- Code/binary review lead fuzzing - It can be very challenging to spot certain bugs using only code review or binary analysis. Combing the approach allows to identify complexity and focus fuzzing to weak areas which may lead to vulns you would have not spotted
- Variant Analysis - As a researcher most of the bugs you find will not be particularly novel and are generally abstractions of a common vulnerability pattern. Knowing how to recognise these patterns and integrating into your toolset to allow faster identification is a must
- Research Tracking - In the area you are researching it is important to keep up-to date on published material. As new attack surfaces are unearthed or new vulnerability classes are identified then taking this knowledge and integrating it into your tooling is important.
- Collaboration - You can get quite far solo in bug hunting, however being able to work in a team allows effective use of the team members specialisation and allows for distribution of work. It helps with motivation on the VR emotional rollercoaster when failure is common.
- Bug Tracking - Whilst going for the most impact as possible is the goal, reaching that goal may require many other lesser impact vulnerabilities chained together. As you are performing your research it is important to make notes of literally anything of potential value.
- Target Knowledge Base - Whilst you are doing this research and afterwards it is important to maintain a target knowledge based. Building on existing knowledge is much easier than coming from zero knowledge of the target. Really helps if you switch between targets lots.
Windows Kernel Exploitation
The most complete and recent overview of the Windows Kernel Segment Heap from an exploitation perspective.
Two articles I wrote on what I assumed was a similar WNF technique seen in the wild to understand how this subsystem could have been abused and the vuln
CVE-2021-31956 Exploiting the Windows Kernel (NTFS with WNF) - Part 1
CVE-2021-31956 Exploiting the Windows Kernel (NTFS with WNF) - Part 2
A use-after-free in clfs.sys, then uses a similar WNF technique as explained in the previous tweet to enable better primitives and techniques mentioned in Scoop the Windows 10 Pool to perform heap grooming. Data only attack escalation
Exploiting a use-after-free in Windows Common Logging File System (CLFS) - Exodus Intelligence
A novel post exploitation primitive unique to Windows 11 22H2+ which can turn an arbitrary write/inc into full read and write of kernel memory by abusing I/O Ring and its operations. A POC was also released
One I/O Ring to Rule Them All: A Full Read/Write Exploit Primitive on Windows 11
Win32k has been a huge source of kernel bugs over the years. This talk goes into more than 15 bugs _arkon found and the novel bug class, attack techniques and mitigation by MSFT.
Investigates the bug class of arbitrary kernel pointer read (i.e. pointers read from attacker controlled input do not point to userspace). Investigates the true impact (i.e. DOS or second order info leak only?) or code exec / LPE
HCVI aims to mitigate an attacker being able too execute unsigned code within the Windows Kernel. 33y0re looks how HVCI affects a typical kernel exploit and shows a way which with arb read/write can call kernel functions without triggering HVCI/kCFG
Exploit Development: No Code Execution? No Problem! Living The Age of VBS, HVCI, and Kernel CFG
In these two a trick to trap access to virtual memory which could be used exploiting certain types of bugs and another on hunting for bugs within Mini-Filter drivers.
Actually looking at what Windows vulns are being exploited within the wild (in this case font bugs and CSRSS bug analysis) provides defenders with insights on where to focus their mitigation and detection efforts.
by rohitwas on finishing off KASLR where previously KUSER_SHARED_DATA was always mapped at a fixed page of memory within the kernel. The post shows strengthening KASLR in Windows by mitigating the last remaining blind-write target RCE could use
Linux Vulnerability Research
Understanding and Improving Linux Kernel Exploit Reliability
userfaultfd technique is dead on most Linux distros due to vm.unprivileged_userfaultfd. Fuse has come through as a good replacement for this technique.
Put an io_uring on it: Exploiting the Linux Kernel
CVE-2022-0185 - Winning a $31337 Bounty after Pwning Ubuntu and Escaping Google’s KCTF Containers
Syzkaller is a game changer in kernel. There’s a few things to say 1) Even existing publics grammars can find bugs when targeted at areas. 2) Extending coverage is a quick way to find bugs 3) N-day often sits around in https://syzkaller.appspot.com/upstream
syzkaller/syscall_descriptions.md at master · google/syzkaller
Tutorial on describing new subsystems
🔍 Looking for Remote Code Execution bugs in the Linux kernel
Using syzkaller, part 3: Fuzzing your changes
CVE-2022-1972: out-of-bound write in Linux netfilter subsystem leads to local privilege escalation
So N-day often just sitting around.. KCTF encourages researchers to triage existing bugs and develop new techniques to bypass existing mitigations
Trick & Treat! 🎃 Paying Leets and Sweets for Linux Kernel privescs and k8s escapes
both 0-day/N-day. As a researcher you can learn a lot from past bugs:
Keeping on top of mitigations in your head is hard. Especially if you are working on multiple platforms.
https://github.com/nccgroup/exploit_mitigations
to try to help track these. Really early days, but any contributions appreciated!
Finding the correct size structures with elements you want to control at certain offsets with them is tedious and time consuming. CodeQL massively helps speed up this process.mmolgtm article
One day short of a full chain: Part 1 - Android Kernel arbitrary code execution
shows a query which can be used for this.
The msg_msg technique which has been a favorite by exploit writes used in
CVE-2022-0185 - Winning a $31337 Bounty after Pwning Ubuntu and Escaping Google’s KCTF Containers
CVE-2021-22555: Turning \x00\x00 into 10000$
The Discovery and Exploitation of CVE-2022-25636
becomes less useful in 5.14 when GFP_KERNEL_ACCOUNT end up in kmalloc-cg-* caches and your vulnerable object is not.
Talking of kmalloc cache’s, cross-cache attacks are a thing and can be used when its not possible to find an interesting object within your initial target cache. Markak_ describes this and other factors to consider when evaluating AUTOSLAB
This list wouldn’t be complete andreyknvl and a13xp0p0v with linkersec and
https://github.com/xairy/linux-kernel-exploitation
which goes into way more things going back over the years.
Finally, if this kind of research interests you! My team at nccgroupinfosec position open currently at
