Exploit Development
pwning asus driverhub, msi center, acer control centre and razer synapse 4
At the beginning of this year I spent a week finding several vulnerabilities in various “bloatware” software. This was after I got suspicious of how my ASUS motherboard’s “DriverHub” behaved. In the end I looked at 6 targets from 6 random vendors (apart from ASUS) and found vulnerabilities ranging from Remote Code Execution to Local Privilege Escalation in all of them. Those were: ASUS, Acer, Lenovo, HP, MSI and Razer.
The hunt for Chromium issue 1072171
Intro The last few months I’ve been studying Chrome’s v8 internals and exploits with the focus of finding a type confusion bug. The good news is that I found one, so the fuzzing and analysis efforts didn’t go to waste. The bad news is that I can reliably trigger the vulnerability but I haven’t found a way to weaponise it yet.
If you don’t have prior knowledge of v8, I encourage you to take some time and read through the previous post I wrote. It covers all of the basics regarding the v8 compiler and tools that helped me throughout my research. More importantly, it will help newcomers understand all of the research described within this post.
Being Stubborn Pays Off pt. 2 – Tale of two 0days on PRTG Network Monitor
Intro Last year I wrote how to weaponize CVE-2018-19204. This blog post will continue and elaborate on the finding and analysis of two additional vulnerabilities that were discovered during the process; one leading to an arbitrary write as system where the contents can’t be fully controlled and the other leading to Remote Code Execution as SYSTEM. Both vulnerabilities require you to have the administrator password for PRTG Network Monitor. Often you just get lucky, as the software defaults to prtgadmin:prtgadmin for the username and password respectively.
Intro to Chrome’s V8 from an exploit development angle
Intro Last Christmas I was doing quite a bit of research around an exploit for Chrome’s JavaScript engine, V8. While most of the concepts around the exploit might seem familiar: for example, what is known as a Type Confusion today has the almost exact concept (or outcome) as a Use-After-Free vulnerability, one of the differences is that there is no free/malloc exploited directly; there is a huge difference in the root cause of the exploitability of Type Confusion vulnerabilities. This is due to the optimisation phases that happen in the JavaScript engine before the Type Confusion bug is triggered. Because of this, after tackling an exploit and realising there’s so much about the internals that I needed to know, I tried getting my head around the tooling and the optimisation pipeline happening within V8, by reading the code and working on some examples while supporting myself on an amazing tool called Turbolizer by the v8 dev team.
Being Stubborn Pays Off pt. 1 – CVE-2018-19204
Intro During an internal assessment, I came across monitoring software that had default credentials configured. This monitoring software allowed for the creation of sensors, but, none of which would allow for code execution or any other things that could compromise an underlying system. Turns out, it was a vulnerable version based on a publicly known CVE, but there was no public exploit code. Join me in this quest on building an exploit!
Page 1 of 1