received signal SIGSEGV (lmao)
This is the second part of the two-part series covering a heap overflow I found in ReadyMedia MiniDLNA (CVE-2023-33476). This post will focus on the exploit development side of things, going over the various challenges that had to be overcome and how everything was put together to achieve remote code execution and pop a reverse shell using a tcache poisoning attack. Check out the first post for an in-depth root cause analysis and overview of the vulnerability.
This post provides the details and a root cause analysis of a heap buffer overflow vulnerability I discovered in the HTTP chunk parsing code of MiniDLNA, affecting versions up to 1.3.2. This vulnerability can be exploited to achieve remote code execution in the context of the user that the minidlna server is running as. The issue was reported to the package maintainer following best practices for responsible disclosure and a fixed version is now available. A follow up post will be published soon with a detailed write-up of the exploit development process along with two fully weaponized exploits for both x86_64 and ARM32 targets, so stay tuned :)
Having recently spent some time working on an exploit for an 0day I’d found on the RAX30, the recent release of a few ZDI advisories for this device caught my attention. I took a quick look to confirm there weren’t any collisions with my bug, and after confirming this wasn’t the case (phew!), I decided to use this as an opportunity to do some patch diff analysis and see if there were any bugs worth writing exploits for.
At the end of last year I stumbled on a crash in Xorg while playing with the GreatFET One but never really got around to follow up on it. Then a few weeks ago, I decided to finally root cause the issue and while in the middle of doing so I discovered that the issue had been reported and fixed only 3 months ago. Since I’d already started working on it though, I decided to just move onto writing some exploits. In this post I walk through the details of writing an exploit to leak the stack canary.
An unauthenticated command injection vulnerability in Netgear Orbi devices was reported to Netgear in December 2020 by ZDI. I wanted to learn more about the bug, but the details of the vulnerability were never released and there were no known exploits. Having spent the last year and a half looking at this system, I decided to try to find the bug myself and see if I could write a functional exploit. It was tougher than I expected, but I made it work in the end :)
The second part in this series going over my time hunting for bugs on the netgear orbi. This post is a walkthrough of a long journey that began with the discovery of a buffer overflow which I initially though was unreachable due to a separate null pointer dereference and eventually finding a way to get past that null deref — only to ultimately be thwarted by a stack canary that couldn’t be easily bypassed (at least, not by me). So, free 0day for anyone that can exploit it? Hit me up on twitter to let me know how you did it.
I’ve been hunting for bugs on the Netgear Orbi (RBR20) for about a year and half now. This is the first in a series of posts where I’ll be publishing my notes and findings from this research. This post provides an high-level overview of the system and notes on getting serial console access via UART.
I wanted to do some fuzzing against
udhcpdrecently but was feeling too lazy to write a harness from scratch, so instead modified the existing udhcp server code to turn it into a harness using AFL’s LLVM persistent mode and then modified the udhcp client (
udhcpc) to generate a corpus of testcases and write them out to files. Here’s what I was able to put together over a weekend.
I recently audited Santa, a binary authorization system for macOS, and discovered a technique for bypassing Santa’s controls using in-memory execution + userland-exec. I combine this with Python’s
NamedTemporaryFileobjects to create a proof-of-concept showing how this can be used to execute native code in a ‘fileless’ manner and bypass both Santa and at least one popular enterprise AV solution on macOS.
This will be the first in a series of posts about working with afl and documenting new things I learn about using it. I thought it would be good to start this off by describing my current fuzzing workflow and how I set everything up. This took me a little while to settle into so I’m hoping it’ll be useful to others just getting started.
While going over the assembly for the buggy function I discussed in my previous post, I came across a chunk of instructions that I was having a hard time mapping back to the source code. Suspecting compiler optimizations had something to do with it, I decided to go through the assembly line-by-line, documenting each operation along the way and trying to map it all back to the source, in an attempt to understand what the compiler had done.
A few weeks ago, I finally got around to trying out American Fuzzy Lop for this first time and chose to fuzz a couple of the binutils tools. While fuzzing
objdumpAFL found a few interesting crashes the led me to discover a bug in the version of libbfd (Binary File Descriptor) included with the version of binutils I tested. This post provides details on the bug and walks through the process of finding the root cause.
This post provides details on the discovery and exploitation of CVE-2017-17065, a vulnerability I found in certain D-Link routers.
While poking at an HTTP server I had come across I eventually discovered a buffer overflow in the code responsible for processing the URI part of an HTTP request. This post walks through the process of finding the root-cause of the bug and write a PoC exploit using return-to-libc to call
exit()cleanly across all running threads and kill the server.
I couldn’t find any good guides online about how to collect Bro logs with Logstash without having to run Logstash on the same server, so wrote my own. This solution uses Filebeat on the Bro server to forward the logs to a remote Logstash server, which then handles processing of that data using filters before forwarding the processed data to Elasticsearch.
This post provides details on the discovery and exploitation of CVE-2017-9675, a vulnerability I found in certain D-Link routers.
While working on berry-sense and learning about network traffic analysis recently, I had the need for a dedicated device to use as an Ethernet bridge/tap for capturing traffic. This would give me a chance to test the Raspberry Pi’s performance while performing traffic captures, as well as produce a usable device for performing simple captures.
A walkthrough of setting up YaF+SiLK network flow analysis tools on an Ubuntu 16.04 virtual machine.
subscribe via RSS