If you know me, you know that I love DNS. I’m not exactly sure how that happened, but I suspect that Ed Skoudis is at least partly to blame.
Anyway, a project came up to evaluate dnsmasq, and being a DNS server - and a key piece of Internet infrastructure - I thought it would be fun! And it was! By fuzzing in a somewhat creative way, I found a really cool vulnerability that’s almost certainly exploitable (though I haven’t proven that for reasons that’ll become apparent later).
Although I started writing an exploit, I didn’t finish it. I think it’s almost certainly exploitable, so if you have some free time and you want to learn about exploit development, it’s worthwhile having a look! Here’s a link to the actual distribution of a vulnerable version, and I’ll discuss the work I’ve done so far at the end of this post.
You can also download my branch, which is similar to the vulnerable version (branched from it), the only difference is that it contains a bunch of fuzzing instrumentation and debug output around parsing names.
Defcon quals: wwtw (a series of vulns)
This is going to be my final (and somewhat late) writeup for the Defcon Qualification CTF. The level was called “wibbly-wobbly-timey-wimey”, or “wwtw”, and was a combination of a few things (at least the way I solved it): programming, reverse engineering, logic bugs, format-string vulnerabilities, some return-oriented programming (for my solution), and Dr. Who references!
I’m not going to spend much time on the theory of format-string vulnerabilities or return-oriented programming because I just covered them in babyecho and r0pbaby.
And by the way, I’ll be building the solution in Python as we go, because the first part was solved by one of my teammates, and he’s a Python guy. As much as I hated working with Python (which has become my life lately), I didn’t want to re-write the first part and it was too complex to do on the shell, so I sucked it up and used his code.
You can download the binary here, and you can get the exploit and other files involved on my github page.
Defcon Quals: babyecho (format string vulns in gory detail)
Welcome to the third (and penultimate) blog post about the 2015 Defcon Qualification CTF! This is going to be a writeup of the “babyecho” level, as well as a thorough overview of format-string vulnerabilities! I really like format string vulnerabilities - they’re essentially a “read or write anywhere” primitive - so I’m excited to finally write about them!
You can grab the binary here, and you can get my exploit and some other files on this Github repo.
Defcon Quals: Access Control (simple reverse engineer)
Today’s post will be another write-up from the Defcon CTF Qualifiers. This one will be the level called “Access Client”, or simply “client”, which was a one-point reverse engineering level. This post is going to be mostly about the process I use for reverse engineering crypto-style code - it’s a much different process than reversing higher level stuff, because each instruction matters and it’s often extremely hard to follow.
Having just finished another level (r0pbaby, I think), and having about an hour left in the competition, I wanted something I could finish quickly. There were two one-point reverse engineering challenges open that we hadn’t solved: one was 64-bit and written in C++, whereas this one was 32-bit and C and only had a few short functions. The choice was easy. :)
I downloaded the binary and had a look at its strings. Lots of text-based stuff, such as “list users”, “print key”, and “connection id:”, which I saw as a good sign!
Defcon Quals: r0pbaby (simple 64-bit ROP)
This past weekend I competed in the Defcon CTF Qualifiers from the Legit Business Syndicate. In the past it’s been one of my favourite competitions, and this year was no exception!
Unfortunately, I got stuck for quite a long time on a 2-point problem (“wwtw”) and spent most of my weekend on it. But I did do a few others - r0pbaby included - and am excited to write about them, as well!
r0pbaby is neat, because it’s an absolute bare-bones ROP (return-oriented programming) level. Quite honestly, when it makes sense, I actually prefer using a ROP chain to using shellcode. Much of the time, it’s actually easier! You can see the binary, my solution, and other stuff I used on this github repo.
It might make sense to read a post I made in 2013 about a level in PlaidCTF called ropasaurusrex. But it’s not really necessary - I’m going to explain the same stuff again with two years more experience!
dnscat2 beta release!
As I promised during my 2014 Derbycon talk (amongst other places), this is an initial release of my complete re-write/re-design of the dnscat service / protocol. It’s now a standalone tool instead of being bundled with nbtool, among other changes. :)
I’d love to have people testing it, and getting feedback is super important to me! Even if you don’t try this version, hearing that you’re excited for a full release would be awesome. The more people excited for this, the more I’m encouraged to work on it! In case you don’t know it, my email address is listed below in a couple places.
GitS 2015: Huffy (huffman-encoded shellcode)
Welcome to my fourth and final writeup from Ghost in the Shellcode 2015! This one is about the one and only reversing level, called “huffy”, that was released right near the end.
Unfortunately, while I thought I was solving it a half hour before the game ended, I had messed up some timezones and was finishing it a half hour after the game ended. So I didn’t do the final exploitation step.
At any rate, I solved the hard part, so I’ll go over the solution!
GitS 2015: Giggles (off-by-one virtual machine)
Welcome to part 3 of my Ghost in the Shellcode writeup! Sorry for the delay, I actually just moved to Seattle. On a sidenote, if there are any Seattle hackers out there reading this, hit me up and let’s get a drink!
Now, down to business: this writeup is about one of the Pwnage 300 levels; specifically, Giggles, which implements a very simple and very vulnerable virtual machine. You can download the binary here, the source code here (with my comments - I put XXX near most of the vulnerabilities and bad practices I noticed), and my exploit here.
One really cool aspect of this level was that they gave source code, a binary with symbols, and even a client (that’s the last time I’ll mention their client, since I dislike Python :) )! That means we could focus on exploitation and not reversing!
GitS 2015: aart.php (race condition)
Welcome to my second writeup for Ghost in the Shellcode 2015! This writeup is for the one and only Web level, “aart” (download it). I wanted to do a writeup for this one specifically because, even though the level isn’t super exciting, the solution was actually a pretty obscure vulnerability type that you don’t generally see in CTFs: a race condition!
But we’ll get to that after, first I want to talk about a wrong path that I spent a lot of time on. :)
GitS 2015: knockers.py (hash extension vulnerability)
As many of you know, last weekend was Ghost in the Shellcode 2015! There were plenty of fun challenges, and as always I had a great time competing! This will be my first of four writeups, and will be pretty simple (since it simply required me to use a tool that already exists (and that I wrote :) ))
The level was called “knockers”. It’s a simple python script that listens on an IPv6 UDP port and, if it gets an appropriately signed request, opens one or more other ports. The specific challenge gave you a signed token to open port 80, and challenged you to open up port 7175. The service itself listened on port 8008 (“BOOB”, to go with the “knockers” name :) ).
You can download the original level here (Python).
Call for help: researching the recent gmail password leak
You probably heard this week about 5 million @gmail.com accounts posted. I’ve been researching it independently, and was hoping for some community help (this is completely unrelated to the fact that I work at Google - I just like passwords).
I’m reasonably sure that the released list is an amalgamation of a bunch of other lists and breaches. But I don’t know what ones - that’s what I’m trying to find out!
Which brings me to how you can help: people who can recognize which site their password came from. I’m trying to build a list of which breaches were aggregated to create this list, in the hopes that I can find breaches that were previously unreported!
If you want to help:
1. Check your email address on https://haveibeenpwned.com/
2. If you're in the list, email email@example.com from the associated account
3. I'll tell you the password that was associated with that account
4. And, most importantly, you tell me which site you used that password on!
In a couple days/weeks (depending on how many responses I get), I’ll release the list of providers!
Thanks! And, as a special ‘thank you’ to all of you, here are the aggregated passwords from the breach! And no, I’m not going to release (or keep) the email list. :)