A few weeks ago, SANS hosted a private event at the Smithsonian’s Air and Space Museum as part of SANS Hackfest. An evening in the Air and Space Museum just for us! And to sweeten the deal, they set up a scavenger hunt called “Hackers of Gravity” to work on while we were there!
We worked in small teams (I teamed up with Eric, who’s also writing this blog with me). All they told us in advance was to bring a phone, so every part of this was solved with our phones and Google.
Each level began with an image, typically with a cipher embedded in it. After decoding the cipher, the solution and the image itself were used together to track down a related artifact.
Live from the SANS Pentest Summit, I’m excited to announce the latest beta release of dnscat2: 0.04! Besides some minor cleanups and UI improvements, there is one serious improvement: all dnscat2 sessions are now encrypted by default!
Read on for some user information, then some implementation details for those who are interested! For all the REALLY gory information, check out the protocol doc!
It’s no secret that I love DNS. It’s an awesome protocol. It’s easy to understand and easy to implement. It’s also easy to get dangerously wrong, but that’s a story for last weeka few weeks ago. :)
I want to talk about interesting implication of DNS’s design decisions that benefit us, as penetration testers. It’s difficult to describe these decisions as good or bad, it’s just what we have to work with.
What I DON’T want to talk about today is DNS poisoning or spoofing, or similar vulnerabilities. While cool, it generally requires the attacker to take advantage of poorly configured or vulnerable DNS servers.
Technically, I’m also releasing a tool I wrote a couple weeks ago: dnslogger.rb that replaces an old tool I wrote a million years ago.
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.
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.
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.
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!
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!
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.
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!
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!
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. :)
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).
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 ihazhacked@skullsecurity.orgfrom the associated account3. I'll tell you the password that was associated with that account4. 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. :)
Every once in awhile, I like to post something random here. This is another one of those times. If you want some real security info, move along now. :)
This is a story about a random locked hatch I found in the middle of a field. Originally it was just neat, but after the “Safe” incident and the creating of /r/whatsinthisthing, I realized I had to learn more. What did it contain? Tunnels? Treasure? Dragons? A valve? I didn’t know, but I had to find out!
This is my writeup for byhd, a 2-point challenge from the Defcon Qualifier CTF. You can get the files, including my annotated assembly file, here. This is my second (and final) writeup for the Defcon Qualifiers, you can find the writeup for shitsco here.
This was a reverse engineering challenge where code would be constructed based on your input, then executed. You had to figure out the exact right input to generate a payload that would give you access to the server (so, in a way, there was some exploitation involved).
Up till now, cnot from PlaidCTF has probably been my favourite hardcore reversing level, but I think this level has taken over. It was super fun!
Apparently this blog has become a CTF writeup blog! Hopefully you don’t mind, I still try to keep all my posts educational.
Anyway, this is the first of two writeups for the Defcon CTF Qualifiers (2014). I only completed two levels, both of which were binary reversing/exploitation! This particular level was called “shitsco”, and was essentially a use-after-free vulnerability. You can download the level, as well as my annotated IDA file, here.
This is my last writeup for PlaidCTF! You can get a list of all my writeups here. Kappa is a 275-point pwnable level called Kappa, and the goal is to capture a bunch of Pokemon and make them battle each other!
Ultimately, this issue came down to a type-confusion bug that let us read memory and call arbitrary locations. Let’s see why!
I know in my last blog I promised to do a couple exploit ones instead of doing boring Web stuff. But, this level was really easy and I still wanted to do a writeup, so you’re just going to have to wait a little while longer for my ‘kappa’ writeup!
I know what you’re thinking of: what’s with all the Web levels!?
Well, I was saving the exploitation levels for last! This post will be about Pwnable-200 (ezhp), and the next one will be Pwnable-275 (kappa). You can get the binary for ezhp here, and I highly recommend poking at this if you’re interested in exploitation—it’s actually one of the easiest exploitation levels you’ll find!
