I registered “skullsecurity.org” (along with .net and .com) a couple years ago, to host the site for a Shadowrun campaign that ended up with the same name (that’s a long story, but maybe I’ll tell it some day!). When I created it, I knew it’d be an awesome name for a security site or group or whatever, so I told myself that someday, I’d create a blog there. And here we are.
This blog is, as the tagline (currently) says, “just another security weblog”. I’ve been in the security field for awhile now, and am doing some work that I consider interesting, and thought I’d start sharing it. If you want to know what I’m working on, or what I do for fun, or what I need to access later, check out my wiki.
Anyway, with that aside, a little about myself. My name is Ron Bowes, I’m 2425262738 (wow, what a gap in updates) 39 and have a Bachelors of Computer Science (honours) from the University of Manitoba. I have a bunch of expired certifications, I’ve worked at big companies (like Google), moved from Canada to the US, and have had a pretty cool life.
These days, I do security research for the Emergent Threats team at Rapid7. I use my personal blog largely for CTF writeups, but I have this idea where I want to post more short-form blogs on techniques I use a lot.
I cut my teeth, security-wise, on reverse engineering games for Battle.net, for the purposes of writing emulation bots, non-malicious hacks/plugins, and just plain educational tinkering. To my knowledge, I’m the first to have publicly released code for Warcraft 3 SRP, the Lockdown Modules, and Warden. One of my favourite things I wrote for Battle.net, in my programming infancy, was a Message Spoofer, which would allow users to send various control characters in their messages for effects like colours and alighment. To my knowledge, it was the first and only program that specialized in message spoofing.
My work in late 2008 and all of 2009 revolved around Microsoft’s NetBIOS and SMB (aka, CIFS) protocols. Using a fantastic book called Implementing CIFS, by Christopher R. Hertel, I learned how Windows systems talk to each other, on a low level, and how I can manipulate this to assist penetration testers. I wrote a large collection of Nmap scripts to take advantage of this protocol in some interesting ways. You can find lots of blogs on this site about them.
Updated on January 1, 2010
2009 was the first year I participated significantly in the security community.
I met a lot of well known folks at Defcon in Vegas and gave my first real presentation at Toorcon in San Diego. I also finished SANS 504 and, toward the start of 2010, started learning the DNS protocol in detail and writing some tools for cute DNS tricks. You can look forward to some blogs about DNS coming up, and hopefully 2010 will be another great year!
If you have any questions, feel free to email me or post a response here!
Bio (updated 2015-09-09)
(I keep needing a bio when submitting talks and keep losing it, so I’ll keep it
here for safe keeping)
From the time he was in highschool, Ron Bowes was fascinated by hacking and
tinkering. He pushed some boundaries early in his career when he was the first to document and publish source code for Battle.net’s secure login sequences. When he didn’t get in trouble for that, he started publishing password breaches on his site - skullsecurity.org - where they can still be found. After graduating with a Computer Science degree, Ron has been everything from an analyst to a researcher to a PHP dev (yes, PHP dev). Currently, he spends his days as a security engineer at Google and his nights working on open source projects, such as SMB and MSRPC support in Nmap and his DNS-based command-and-control backdoor, dnscat2.
Recently, I had the privilege to write a detailed analysis of
CVE-2023-34362,
which is series of several vulnerabilities in the MOVEit file transfer
application that lead to remote code execution. One of the several
vulnerabilities involved an ISAPI module - specifically, the MoveITISAPI.dll
ISAPI extension. One of the many vulnerabilities that comprised the MOVEit RCE
was a header-injection issue, where the ISAPI application parsed headers
differently than the .net application. This point is going to dig into how to
analyze and reverse engineer an ISAPI-based service!
This wasn’t the first time in the recent past I’d had to work on
something written as an ISAPI module, and each time I feel like I have to start
over and remember how it’s supposed to work. This time, I thought I’d combine
my hastily-scrawled notes with some Googling, and try to write something that I
(and others) can use in the future. As such, this will be a quick intro to
ISAPI applications from the angle that matters to me - how to reverse engineer
and debug them!
I want to preface this with: I’m not a Windows developer, and I’ve never run an
IIS server on purpose. That means that I am approaching this with brute-force
ignorance! I don’t have a lot of background context nor do I know the correct
terminology for a lot of this stuff. Instead, I’m going to treat these are
typical DLLs from typical applications, and approach them as such.
Have you ever tested a Linux application that forks into multiple processes?
Isn’t it a pain? Whether you’re debugging, trying to see a process crash, or
trying to write an exploit, it can be super duper annoying!
In a few days, I’m giving a talk at NorthSec in Montreal. I asked some
co-workers to review my slides, and they commented that I have some neat
techniques to deal with forking, so I thought I’d share a couple!
Spoiler alert: The last one is the best, so you can just skip to that. :)
Lately, I’ve been reverse engineering a reasonably complex network protocol, and I ran into a mystery - while the protocol is generally an unencrypted binary protocol, one of the messages was large and random. In an otherwise unencrypted protocol, why is one of the messages unreadable? It took me a few hours to accomplish what should have been a couple minutes of effort, and I wanted to share the trick I ultimately used!
I’m going to be intentionally vague on the software, and even modify a few things to make it harder to identify; I’ll probably publish a lot more on my work blog once I’m finished this project!
too-latte
is a challenge I wrote based on
CVE-2023-0669,
which is an unsafe deserialization vulnerability in Fortra’s GoAnywhere MFT
software. I modeled all the vulnerable code off, as much as I could, that
codebase. It’s obviously themed quite differently.
ROP Petting Zoo is a challenge designed to teach the principles of
return-oriented programming. It’s mostly written in Javascript, with a backend
powered by a Ruby web server, along with a tool I wrote called
Mandrake. Source code is shared between
the three parts of the challenge, and is available
here.
Overflow is a straight-forward buffer overflow challenge that I copied from
the Hacking: Art of Exploitation examples CD.
I just added a flag. Full source is here.
id-me is a
challenge I wrote to teach people how to determine file types without extensions.
My intent was to use the file command, but other solutions are absolutely
possible!
They are somewhat difficult challenges where the player reverses a network
protocol, finds an authentication bypass, and performs a stack overflow to
ultimately get code execution. It also has a bit of thematic / story to it!
Last year, I worked on a vulnerability in Zimbra
(CVE-2022-41352 - my
AttackerKB analysis for Rapid7)
that turned out to be a new(-ish) exploit path for a really old bug in cpio -
CVE-2015-1194. But that was patched in 2019, so what happened?
(I posted this as a tweet-thread awhile back, but I decided to flesh it out and
make it into a full blog post!)
While reverse engineering a Linux binary, I ran into a fairly common situation:
I wanted to understand how a decompression function works, but I didn’t have
compressed data to test with. In this blog, I’ll look at how to we can
manipulate the instruction pointer in the GNU debugger (gdb) to trick the
software into generating test data for us!
I posted this on Mastodon awhile back, but I cleaned it up and expanded it a bit
to make it a full blog post.
This is my (Ron's / iagox86's) author writeups for the BSides San Francisco 2022 CTF. You can get the full source code for everything on github. Most have either a Dockerfile or instructions on how to run locally. Enjoy!
This is my (Ron's / iagox86's) author writeups for the BSides San Francisco 2022 CTF. You can get the full source code for everything on github. Most have either a Dockerfile or instructions on how to run locally. Enjoy!
This is my (Ron's / iagox86's) author writeups for the BSides San Francisco 2022 CTF. You can get the full source code for everything on github. Most have either a Dockerfile or instructions on how to run locally. Enjoy!
This is my (Ron's / iagox86's) author writeups for the BSides San Francisco 2022 CTF. You can get the full source code for everything on github. Most have either a Dockerfile or instructions on how to run locally. Enjoy!
This is a video walkthrough of Log ‘em All, a difficult Hacking / Reverse Engineering challenge based on a classic bug in Pokemon Red. You can view the video below, or directly on Youtube.
I’ve never done a video-based writeup before, so I’d love feedback!
First, a bit of history: the original idea I had behind Glitter Printer was to make a video game challenge involving cartridge-swap, where I’d write a handful of simple video games in 100% x86 code with no imports or anything (like an old fashioned cartridge game), and the player could swap between them without memory being re-initialized. Folks used to do this sorta thing on NES, and maybe I’ll use it in a future challenge, but I decided to make this a bit simpler.
While experimenting with writing libraries without libc, I realized just how much work it was going to be to write a bunch of games, and decided to simplify. My next ide was to write a “driver” type thing, where a blob of code is loaded into +RWX memory and the player could go wild on it. The the name Glitter Printer came across my radar, I don’t even remember why, and that gave me the idea to do an LPR server.
It’s designed to be a sort of “server management software”. I sort of chose that theme to play off the Solarwinds thing, the theme wasn’t super linked to the challenge.
The challenge was to analyze and reverse engineer a piece of client-side software that “checks in” with a server. For the check-in, the client is required to “validate” itself. The server sends a random “challenge” - which is actually a block of randomized x86 code - and that code used to checksum active memory to prevent tampering. If anybody reading this worked on bots for the original Starcraft (and other Battle.net games), this might seem familiar! It’s based on Battle.net’s CheckRevision code.
This is actually a reasonable simple challenge, overall. I got the idea of using a bad mt19937 implementation (the Mersenne Twister PRNG used by Ruby and Python) from SANS Holiday Hack Challenge 2020 (which is still online if you want to play!), and wanted to build a challenge around it. I had the idea of Battleship originally, but ended up deciding on Hangman for reasons I no longer remember, but that I’m sure made sense at the time.
Both parts are reasonably simple reverse engineering challenges. I provide the compiled binaries to the player (you can find those in the respective distfiles/ folders), and you have to figure out what to do with them.
Both challenges use the same basic code as the runme challenges, where you send shellcode that is executed. Only in this case, the shellcode must be modified or “encoded” in some way first!
The three challenges I’ll cover are runme, runme2, and runme3, which are increasingly difficult write-shellcode challenges. As always, the binary and info the player gets is in the respective distfiles/ folder, and source is in challenge/.
For my third and final blog post about the BSidesSF CTF, I wanted to cover the solution to Chameleon. Chameleon is loosely based on a KringleCon challenge I wrote (video guide), which is loosely based on a real-world penetration test from a long time ago. Except that Chameleon is much, much harder than either.
As mentioned in a previous post, I was honoured to once again help run BSidesSF CTF!
This is going to be a quick writeup for three challenges: config-me, rusty1, and rusty2. All three are reversing challenges written in Rust, although the actual amount of reversing required is low for the first two.
Once again, it was my distinct privilege to be a BSidesSF CTF organizer! As somebody who played CTFs for years, it really means a lot to me to organize one, and watch folks struggle through our challenges. And more importantly, each person that comes up to us and either thanks us or tells us they learned something is a huge bonus!
But this week, I want to post writeups for some of the challenges I wrote. I’m starting with my favourite - Gman!
I run a lot of lockpicking villages and such, and have a pretty big collection of locks, picks, and knowledge. A ton of people ask me how to get started, and unfortunately I don’t think there are any particularly good walkthroughs of how to get the basic stuff needed to start. Since Peterson just announced their winter sale, and I’ve had several requests to recommend lockpicking-based Christmas gifts, I figured this would be a good time to post some info!
Lots of the advice I see is around clear (acrylic) locks and progressive locks. I’m gonna be slightly controversial here by saying: clear and progressive locks are almost universally bad for learning or training - they’re badly made, unrealistic, have cheap parts, etc. They’re great for learning how locks work, but not for any serious practice.
In this post, I will talk about a few things: what are the first picks you should get, what are some good locks to practice on, and what are good resources to use for learning?
In addition to genius, whose writeup I already posted, my other favourite challenge I wrote for BSidesSF CTF was called launchcode. This will be my third and final writeup for BSidesSF CTF for 2019, but you can see all the challenges and solutions on our Github releases page.
This post will be more about how I developed this, since the solution is fairly straight forward once you know how it’s implemented.
This is yet another author’s writeup for BSidesSF CTF challenges! This one will focus on three crypto challenges I wrote: mainframe, mixer, and decrypto!
This is going to be an author’s writeup of the BSidesSF 2019 CTF challenge: genius!
genius is probably my favourite challenge from the year, and I’m thrilled that it was solved by 6 teams! It was inspired by a few other challenges I wrote in the past, including Nibbler. You can grab the sourcecode, solution, and everything needed to run it yourself on our Github release!
It is actually implemented as a pair of programs: loader and genius. I only provide the binaries to the players, so it’s up to the player to reverse engineer them. Fortunately, for this writeup, we’ll have source to reference as needed!
This is a technical rundown of a vulnerability that we’ve dubbed “WebExec”. The summary is: a flaw in WebEx’s WebexUpdateService allows anyone with a login to the Windows system where WebEx is installed to run SYSTEM-level code remotely. That’s right: this client-side application that doesn’t listen on any ports is actually vulnerable to remote code execution! A local or domain account will work, making this a powerful way to pivot through networks until it’s patched.
High level details and FAQ at https://webexec.org! Below is a technical writeup of how we found the bug and how it works.
A couple months ago, we ran BSides San Francisco CTF. It was fun, and I posted blogs about it at the time, but I wanted to do a late writeup for the level b-64-b-tuff.
The challenge was to write base64-compatible shellcode. There’s an easy solution - using an alphanumeric encoder - but what’s the fun in that? (also, I didn’t think of it :) ). I’m going to cover base64, but these exact same principles apply to alphanumeric - there’s absolutely on reason you couldn’t change the SET variable in my examples and generate alphanumeric shellcode.
In this post, we’re going to write a base64 decoder stub by hand, which encodes some super simple shellcode. I’ll also post a link to a tool I wrote to automate this.
I can’t promise that this is the best, or the easiest, or even a sane way to do this. I came up with this process all by myself, but I have to imagine that the generally available encoders do basically the same thing. :)
So, this is going to be a bit of an unusual blog for me. I usually focus on technical stuff, exploitation, hacking, etc. But this post will be a mixture of a book review, some discussion on my security review process, and whatever asides fall out of my keyboard when I hit it for long enough. But, don’t fear! I have a nice heavy technical blog ready to go for tomorrow!
While this is technically a CTF writeup, like I frequently do, this one is going to be a bit backwards: this is for a CTF I ran, instead of one I played! I’ve gotta say, it’s been a little while since I played in a CTF, but I had a really good time running the BSidesSF CTF! I just wanted to thank the other organizers - in alphabetical order - @bmenrigh, @cornflakesavage, @itsc0rg1, and @matir. I couldn’t have done it without you folks!
BSidesSF CTF was a capture-the-flag challenge that ran in parallel with BSides San Francisco. It was designed to be easy/intermediate level, but we definitely had a few hair-pulling challenges.
A long time ago, I wrote a coupleblogs that went into a lot of detail on how to use padding oracle vulnerabilities to decrypt an encrypted string of data. It’s pretty important to understand to use a padding oracle vulnerability for decryption before reading this, so I’d suggest going there for a refresher.
When I wrote that blog and the Poracle tool originally, I didn’t actually know how to encrypt arbitrary data using a padding oracle. I was vaguely aware that it was possible, but I hadn’t really thought about it. But recently, I decided to figure out how it works. I thought and thought, and finally came up with this technique that seems to work. I also implemented it in Poracle in commit a5cfad76ad.
Greetings, and I hope you’re all having a great holiday!
My Christmas present to you, the community, is dnscat2 version 0.05!
Some of you will remember that I recently gave a talk at the SANS Hackfest Summit. At the talk, I mentioned some ideas for future plans. That’s when Ed jumped on the stage and took a survey: which feature did the audience want most?
The winner? Tunneling TCP via a dnscat. So now you have it! Tunneling: Phase 1. :)
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!
This is my writeup for Whatscat, just about the easiest 300-point Web level I’ve ever solved! I wouldn’t normally do a writeup about a level like this, but much like the mtpox level I actually wrote the exact tool for exploiting this, and even wrote a blog post about it almost exactly 4 years ago - April of 2010. Unlike mtpox, this tool isn’t the least bit popular, but it sure made my life easy!
This is my second writeup from PlaidCTF this past weekend! It’s for the Web level called kpop, and is about how to shoot yourself in the foot by misusing serialization (download the files). There are at least three levels I either solved or worked on that involved serialization attacks (mtpox, reeekeeeeee, and this one), which is awesome because this is a seriously undersung attack. Good on the PPP!
This is going to be my first of a couple writeups about this past weekend’s CTF: PlaidCTF!
My first writeup is for a 150-point Web level called mtpox. I chose this one to do first not only because it’s the first level I completed, but also because the primary vulnerability was a hash extension issue, and I wrote one of most popular tools for exploiting those. So it’s like the level made for me!
(Actually, there’s another level that I wrote a less popular tool for. I’ll talk about that one in my next post. :) )
It’s a little bit late coming, but this is my writeup for the Fuzzy level from the Ghost in the Shellcode 2014 CTF! I kept putting off writing this, to the point where it became hard to just sit down and do it. But I really wanted to finish before PlaidCTF 2014, which is this weekend so here we are! You can see my other two writeups here (TI-1337) and here (gitsmsg).
Like my other writeups, this is a “pwnage” level, and required the user to own a remote server. Unfortunately, because of my slowness, they’re no longer running the server, but you can get a copy of the binary at my github page and run it yourself. It’s a 64-bit Linux ELF executable. It didn’t have ASLR, and DEP would have been
“It’s Saturday night; I have no date, a 2L bottle of Shasta, and my all-rush mix tape. Let’s rock!”
…that’s what I said before I started gitsmsg. I then entered “Rush” into Pandora, and listened to a mix of Rush, Kansas, Queen, Billy Idol, and other 80’s rock for the entire level. True story.
Anyway, let’s get on with it! Not too long ago I posted my writeup for the 100-level “Pwnage” challenge from Ghost in the Shellcode. Now, it’s time to get a little more advanced and talk about the 299-level challenge: gitsmsg. Solved by only 11 teams, this was considerably more challenging.
As before, you can obtain the binary, my annotated IDA database, and exploit code on my Github page
Most years I go to Shmoocon, but this year I couldn’t attend, so I did the next best thing: competed in Ghost in the Shellcode! This year, our rag-tag band of misfits—that is, the team who purposely decided not to ever decide on a team name, mainly to avoid getting competitive—managed to get 20th place out of at least 300 scoring teams!
I personally solved three levels: TI-1337, gitsmsg, and fuzzy. This is the first of three writeups, for the easiest of the three: TI-1337—solved by 44 teams.
You can download the binary, as well as the exploit, the IDA Pro files, and everything else worth keeping that I generated, from my Github repository.
On a recent trip to Tyson’s Corner, VA, I had some time to kill, so I took a careful look at a malware sample that a friend of mine sent to me some time ago, which I believe he originally got off somebody else’s hosed system. The plan was for me to investigate it, and I promised him I would; it just took awhile!
Anyways, the sample has a few layers of packing, and I thought it’d be fun/interesting to show you how to unwrap the entire thing to obtain the final payload. I am not going to discuss the payload itself in this post, largely because I haven’t spent much time reversing it. Perhaps in the future I’ll dig a little deeper, but for now we’ll focus on the packing.
I called this sample “lcmw”. It stood for something interesting, but I don’t really remember what—I may have been drinking when I named it. :)
For those of you who are close to me, you’ll know that my life has been crazy lately. Between teaching courses, changing jobs (here I come, Google!recently started at Google! (I’m slow at posting these :) )), and organizing BSides Winnipeg, I’ve barely had time to breathe!
Things are still chaotic, of course (in fact, movers were packing up my life as I wrote this), but I wanted to take some time and talk about BSides Winnipeg.
I’ll go over the background, the planning, the day-of, and some lessons learned. If you just want to see cool photos, here you go!
One of the worst feelings when playing a capture-the-flag challenge is the hindsight problem. You spend a few hours on a level—nothing like the amount of time I spent on cnot, not by a fraction—and realize that it was actually pretty easy. But also a brainfuck. That’s what ROP’s all about, after all!
Anyway, even though I spent a lot of time working on the wrong solution (specifically, I didn’t think to bypass ASLR for quite awhile), the process we took of completing the level first without, then with ASLR, is actually a good way to show it, so I’ll take the same route on this post.
Before I say anything else, I have to thank HikingPete for being my wingman on this one. Thanks to him, we solved this puzzle much more quickly and, for a short time, were in 3rd place worldwide!
When I was at Shmoocon, I saw a talk about how to write an effective capture-the-flag contest. One of their suggestions was to have a tar-pit challenge that would waste all the time of the best player, by giving him a complicated challenge he won’t be able to resist. In my opinion, in PlaidCTF, I suspected that “cnot” was that challenge. And I was the sucker, even though I knew it all the way…
(It turns out, after reviewing writeups of other challenges, that most of the challenges were like this; even so, I’m proud to have been sucked in!)
If you want a writeup where you can learn something, I plan to post a writeup for “Ropasaurus” in the next day or two. If you want a writeup about me being tortured as I fought through inconceivable horrors to finish a level and capture the bloody flag, read on! This level wasn’t a lot of learning, just brute-force persistence.
Early last week, I posted a blog about padding oracle attacks. I explained them in detail, as simply as I could (without making diagrams, I suck at diagrams). I asked on Reddit about how I could make it easier to understand, and JoseJimeniz suggested working through an example. I thought that was a neat idea, and working through a padding oracle attack by hand seems like a fun exercise!
(Having done it already and writing this introduction afterwards, I can assure you that it isn’t as fun as I thought it’d be :) )
I’m going to assume that you’ve read my previous blog all the way through, and jump right into things!
This post is about padding oracle vulnerabilities and the tool for attacking them - “Poracle” I’m officially releasing right now. You can grab the Poracle tool on Github!
At my previous job — Tenable Network Security — one of the first tasks I ever had was to write a vulnerability check for MS10-070 — a padding oracle vulnerability in ASP.net. It’s an interesting use of a padding oracle vulnerability, since it leads to code execution, but this blog is going to be a more general overview of padding oracles. When I needed to test this vuln, I couldn’t find a good writeup on how they work. The descriptions I did find were very technical and academic, which I’m no good at. In fact, when it comes to reading academic papers, I’m clueless and easily frightened. But, I struggled through them, and now I’m gonna give you a writeup that even I’d be able to understand!
By the way, the Wikipedia page for this attack isn’t very good. If somebody wants to summarize my blog and make it into a Wikipedia page, there’s now a source you can reference. :)
On a related note, I’m gonna be speaking at Shmoocon in February: “Crypto: You’re doing it wrong”. Among other things, I plan to talk about padding oracles and hash extension attacks — I’m really getting into this crypto thing!
That’s a post I wrote about SkullSpace - the hackerspace that me and several others helped found a couple years ago. We went down a “too good to be true” road, where we had a ton of space and super cheap rent. And, eventually, got bitten by it. We’re in the process of moving, and started a fundraiser to make it happen.
(Administrative note: I'm no longer at Tenable! I left on good terms, and now I'm a consultant at Leviathan Security Group. Feel free to contact me if you need more information!)
Awhile back, my friend @mogigoma and I were doing a capture-the-flag contest at https://stripe-ctf.com. One of the levels of the contest required us to perform a hash length extension attack. I had never even heard of the attack at the time, and after some reading I realized that not only is it a super cool (and conceptually easy!) attack to perform, there is also a total lack of good tools for performing said attack! After hours of adding the wrong number of null bytes or incorrectly adding length values, I vowed to write a tool to make this easy for myself and anybody else who's trying to do it. So, after a couple weeks of work, here it is!
While I was doing a pentest last month, I discovered an attack I didn’t previously know, and I thought I’d share it. This may be a Christopher Columbus moment - discovering something that millions of people already knew about - but I found it pretty cool so now you get to hear about it!
One of the first things I do when I’m looking at a Web app - and it’s okay to make a lot of noise - is run the http-enum.nse Nmap script. This script uses the http-fingerprints.lua file to find any common folders on a system (basically brute-force browsing). I’m used to seeing admin folders, tmp folders, and all kinds of other interesting stuff, but one folder in particular caught my eye this time - /.git.
There have been a lot of discussion and misconceptions about Battle.net’s authentication lately. Having done a lot of work on the Battle.net protocol, I wanted to lay some to rest.
The first thing to understand is that, at least at the time I was working on this, there were three different login methods (this is before they combined the Web logins with Battle.net logins - I can’t speak on those). The three methods are:
CHAT protocol - deprecated a long, long time ago
Old Login System (OLS) - used by Diablo, Warcraft 2 BNE, Starcraft, and Diablo II
New Login System (NLS) - used by Warcraft 3, World of Warcraft, and in some fashion by newer games. Also supported - but unused - by Diablo II
I’ll describe, in detail, how each of these work. The summary is, though, that at no point does a game client ever send a plaintext password to the server. The closest is the SHA1 of the password, which is used for account creation in old games. For more information, read on!
Today, I thought it’d be fun to take a good look at a serious flaw in some computer-management software. Basically, the software is designed for remotely controlling systems on networks (for installing updates or whatever). As far as I know, this vulnerability is currently unpatched; there are allegedly mitigations, but you have to pay to see them! (A note to vendors - making us pay for your patches or mitigation notes only makes your customers less secure. Please stop doing that!)
This research was done in the course of my work at Tenable Network Security on the Reverse Engineering team. It’s an awesome team to work on, and we’re always hiring (for this team and others)! If you’re interested and you have mad reverse engineering skillz, or any kind of infosec skillz, get in touch with me privately! (rbowes-at-tenable-dot-com if you’re interested in applying)
Two weeks ago today, Microsoft released a bunch of bulletins for Patch Tuesday. One of them - ms11-058 - was rated critical and potentially exploitable. However, according to Microsoft, this is a simple integer overflow, leading to a huge memcpy leading to a DoS and nothing more. I disagree.
Although I didn’t find a way to exploit this vulnerability, there’s more to this vulnerability than meets the eye - it’s fairly complicated, and there are a number of places that I suspect an experienced exploit developer might find a way to take control.
In this post, I’m going to go over step by step how I reverse engineered this patch, figured out how this could be attacked, and why I don’t believe the vulnerability is as simple as the reports seem to indicate.
Oh, and before I forget, the Nessus Security Scanner from Tenable Network Security (my employer) has both remote and local checks for this vulnerability, so if you want to check your network go run Nessus now!
As I’m sure you all know, I normally post about IT security here. But, once in awhile, I like to take a look at physical security, even if it’s just in jest.
Well, this time it isn’t in jest. I was at Rona last week buying a lead/asbestos/mold-rated respirator (don’t ask!), when I took a walk down the lock aisle. I’m tired of all my practice locks and was thinking of picking up something interesting. Then I saw it: a lock that advertised that it could re-key itself to any key. Woah! I had to play with it.
Now, maybe I’m an idiot (in fact, my best friends would swear it). But I hadn’t ever heard of a lock that can do that before! So I did the obvious thing: I bought it, took it apart, figured out how it worked, then took pictures of everything.
This is part 3 to my 2-part series on password reset attacks (Part 1 / Part 2). Overall, I got awesome feedback on the first two parts, but I got the same question over and over: what’s the RIGHT way to do this?
So, here’s the thing. I like to break stuff, but I generally leave the fixing to somebody else. It’s just safer that way, since I’m not really a developer or anything like that. Instead, I’m going to continue the trend of looking at others’ implementations by looking at three major opensource projects - Wordpress, SMF, and MediaWiki. Then, since all of these rely on PHP’s random number implementation to some extent, I’ll take a brief look at PHP.
In my last post, I showed how we could guess the output of a password-reset function with a million states. While doing research for that, I stumbled across some software that had a mere 16,000 states. I will show how to fully compromise this software package remotely using the password reset.
This is part one of a two-part blog on password resets. For anybody who saw my talk (or watched the video) from Winnipeg Code Camp, some of this will be old news (but hopefully still interesting!)
For this first part, I’m going to take a closer look at some very common (and very flawed) code that I’ve seen in on a major “snippit” site and contained in at least 5-6 different applications (out of 20 or so that I reviewed). The second blog will focus on a single application that does something much worse.
It’s rare these days for me to write blogs that I have to put a lot of thought into. Most of my writing is technical, which comes pretty naturally, but I haven’t written an argument since I minored in philosophy. So, if my old Ethics or Philosophy profs are reading this, I’m sorry!
Most of you have probably heard of the exim vulnerability this week. It has potential to be a nasty one, and my brain is stuffed with its inner workings right now so I want to post before I explode!
First off, if you’re concerned that you might have vulnerable hosts, I wrote a plugin for Nessus to help you find them (I’m not sure if it’s in the ProfessionalFeed yet - if it isn’t, it will be soon). There’s no Nmap script yet, but my sources tell me that it’s in progress (keep an eye on my Twitter account for updates on that).
Last year (if this intro doesn’t work, I give up trying to post this :) ), I presented at B-Sides Ottawa, which was put on by Andrew Hay and others (and sorry I waited so long before posting this… I kept revising it and not publishing). I got to give a well received talk, meet a lot of great folks, see Ottawa for the first time, and learn that I am a good solid Security D-lister. w00t!
B-sides conferences, for those of you who don’t know, are awesome little conferences that often (but not always) piggyback on other conferences. They are free (or cheap), run by volunteers, and have raw and technical talks. B-sides Ottawa was no exception, and I’m thrilled I had the chance to not only see it, but take part in it. I really hope to run our own B-sides Winnipeg next year!
This is partly an overview of a new Nmap feature that I’m excited about, but is mostly a call to arms. I don’t have access to enterprise apps anymore, and I’m hoping you can all help me out by submitting fingerprints! Read on for more.
It’s been awhile since I’ve written on my blog, and I apologize. I’m at a job now where I actually spend my day working instead of pondering, so it’s hard to find time! :)
So, what’s new with me?
I’m working on some cool new Nmap stuff right now, so I’m hoping to write about that in the next couple months. Web application fingerprinting isn’t something I’ve seen done much, but I’m hoping Nmap can make some good progress on it with the help of Yokoso, Nikto, and some other resources.
Some of you may have heard what I did this month. It turns out, depending on who you listen to, that I’m either an evil “Facebook hacker” or just some mischievous individual doing “unsettling” research. But, one way or the other, a huge number of people have read or heard this story, and that’s pretty cool.
Although it’s awesome (and humbling) that so much attention was paid (at least for a couple days) to some fairly straight forward work I did, I want to talk about this from my perspective, including why I did it and what I think this means to the community. Then, for fun, I’ll end by talking about other places this research can go and open up the floor for some discussion.
First and foremost: if you want to cut to the chase, just download the torrent. If you want the full story, please read on….
Background
Way back when I worked at Symantec, my friend Nick wrote a blog that caused a little bit of trouble for us: Attack of the Facebook Snatchers. I was blog editor at the time, and I went through the usual sign off process and, eventually, published it. Facebook was none too happy, but we fought for it and, in the end, we got to leave the blog up in its original form.
My first idea was simple: spider the lists, generate first-initial-last-name (and similar) lists, then hand them over to @Ithilgore to use in Nmap’s awesome new bruteforce tool he’s working on, Ncrack.
I just released the second alpha build of nbtool (0.05alpha2), and I’m hoping to get a few testers to give me some feedback before I release 0.05 proper. I’m pretty happy with the 0.05 release, but it’s easy for me to miss things as the developer.
I’m hoping for people to test:
Through different DNS servers (requires an authoritative DNS server)
With different operating systems (doesn't require an authoritative server) -- I've tested it on Slackware 32-bit, Slackware 64-bit, FreeBSD 8 64-bit, and Windows 2003, those or others would be great!
With different commandline options (also doesn't require authoritative server)
We hired a new pair of co-op students recently. They’re both in their last academic terms, and are looking for a good challenge and to learn a lot. So, for a challenge, I set up a scenario that forced them to use a series of netcat relays to compromise a target host and bring a meterpreter session back. Here is what the network looked like:
To describe in text:
They have already compromised a Web server with a non-root account
The Web server has no egress filtering, but full ingress filtering, and they aren’t allowed to install anything (fortunately, it already had Netcat)
The target server has both egress and ingress filtering, and is not accessible at all from the Internet, but the Web server can connect to it on 139/445 (which are vulnerable to ms08-067). The target can also connect back to the Web server on any port.
The challenge was to exploit the target server with ms08-067 and bring a meterpreter session back to the attacker server.
Recently, I was given the opportunity to work with an embedded Linux OS that was locked down to prevent unauthorized access. I was able to obtain a shell fairly quickly, but then I ran into a number of security mechanisms. Fortunately, I found creative ways to overcome each of them.
Here’s the list of the biggest problems I encountered, in the order that I overcame them:
The user account couldn't 'ls' most folders due to lack of privileges
Process management tools (like ps) didn't work (thanks to the missing 'ls')
The user account could only write to designated areas, in spite of file permissions
Architecture was PowerPC, which I have no experience with
netstat, ifconfig, arp, and other tools were disabled
Today seemed like a fun day to write about a really cool vector for cross-site scripting I found. In my testing, this attack is pretty specific and, in some ways, useless, but I strongly suspect that, with resources I don’t have access to, this can trigger stored cross-site scripting in some pretty nasty places. But I’ll get to that!
Interestingly enough, between the time that I wrote this blog/tool and published it, nCircle researchers have said almost the same thing (paper (pdf)). The major difference is, I released a tool to do it and demonstrate actual examples.
I am not a forensics expert, nor do I play one on TV. I do, however, play one at work from time to time and I own some of the key tools: a magnifying glass and a 10baseT hub. Oh, and a Sherlock Holmes hat – that’s the key. Unfortunately, these weren’t much help when I was handed a pile of drives and was asked to find out which version of Windows they had been running. I wasn’t allowed to boot them, and I couldn’t really find the full answer of how to get the version after a lot of googling, so I figured it out the hard way. Hopefully I can save you guys some time by explaining it in detail.
And if there’s a better way, which I’m sure there is, please let me know. I don’t doubt that I did this the hard way – that’s kinda my thing.
The order of events is, basically:
Step 1: Copy the system's registry hive to your analysis system
Step 2: Mount the registry hive in regedit.exe
Step 3: Navigate to the OS version in regedit.exe
Step 4: Unmount the registry hive.
If you know how to do all that, then thanks for reading! Check back Tuesday for a brand new blog posting! I have an interesting blog that combines DNS and cross-site scripting lined up.
Otherwise, keep reading. Or just look at the pictures.
In honour of this special day, I’m releasing an Nmap script I wrote a few months ago as a challenge: http-california-plates.nse. To install it, ensure you’re at the latest svn version of Nmap (I fixed a bug in http.lua last night that prevented this from working, so only the svn version as of today will work), download http-california-plates.nse, and install it.
So, I realized that the reCAPTCHA plugin for Wordpress sucks was marking a lot of comments as spam, when it was actually working and not getting timeout errors (thanks to my egress filtering). I decided to toss it out and go with a math-based CAPTCHA for posts, so you should once again be able to post comments reliably! I’m hoping that by customizing the math CAPTCHA to use different field names/numbers, it should eliminate the same amount of spam that reCAPTCHA did.
Also worth noting: at the moment, registration isn’t going to work because I don’t have email set up. I’ll post an update to that when it’s going again. It shouldn’t matter, though, registration isn’t required to comment.
I also added an infobox on the side (–>) with information about the author of the post, since I’ve been taking turns with my buddy Matt Gardenghi lately. Now you can see who posted what.
If anything isn’t working, or you’d like some feature/widget/whatever that I don’t currently have, let me know!
Now that we know what we need to send and receive, and how it’s encoded, let’s generate the actual packet. Then, once we’re sure it’s working, we’ll convert it into an Nmap probe! In most of this section, I assume you’re running Linux, Mac, or some other operating system with a built-in compiler and useful tools (gcc, hexdump, etc). If you’re on Windows, you’ll probably just have to follow along until I generate the probe.
In Part 2: runtime analysis, we discovered some important addresses in the Energizer Trojan – specifically, the addresses that make the call to recv() data. Be sure to read that section before reading this one.
Now that we have some starting addresses, we can move on to a disassembler and look at what the code’s actually doing. Fortunately, the author made no attempt to disguise the code or pack or or anything like that, so a simple disassembler is all we need to examine the code.
A word of warning: this is the longest, most complicated section. But stick with it, by the end we’ll know exactly how the Trojan ticks!
In Part 1: setup, we infected the system with the Trojan. It should still be running on the victim machine. If you haven’t read that section, I strongly recommend you go back and read it.
Now that we’ve infected a test machine, the goal of this step is to experiment a little with the debugger and learn a little about the Energizer Trojan. This can all be discovered with a simple disassembler, but I find it more fun to take apart a live sample. All we’re going to do is add a breakpoint at the recv() function and see where it’s called from.
This step is going to require Debugging Tools for Windows. If you haven’t installed it already, install it on the victim machine.
As most of you know, a Trojan was recently discovered in the software for Energizer’s USB battery charger. Following its release, I wrote an Nmap probe to detect the Trojan and HDMoore wrote a Metasploit module to exploit it.
I mentioned in my last post that it was a nice sample to study and learn from. The author made absolutely no attempt to conceal its purpose, once installed, besides a weak XOR encoding for communication. Some conspiracy theorists even think this may have been legitimate management software gone wrong – and who knows, really? In any case, I offered to write a tutorial on how I wrote the Nmap probe, and had a lot of positive feedback, so here it is!
Just be sure to take this for what it is. This is not intended to show any new methods or techniques or anything like that. It’s a reverse engineering guide targeted, as much as I could, for people who’ve never opened IDA or Windbg in their lives. I’d love to hear your comments!
I’ve been letting other projects slip these last couple weeks because I was excited about converting dnscat into shellcode (or “weaponizing dnscat”, as I enjoy saying). Even though I got into the security field with reverse engineering and writing hacks for games, I have never written more than a couple lines of x86 at a time, nor have I ever written shellcode, so this was an awesome learning experience. Most people start by writing shellcode that spawns a local shell; I decided to start with shellcode that implements a dnscat client in under 1024 bytes (for both Linux and Windows). Like I always say, go big or go home!
This is going to be a fun post that’s related to some of my password work. Some of the text may not be PG13, so parental discretion is advised.
As most of you know, I’ve been collecting password lists. In addition to normal password lists that are useful in bruteforcing, I have a (so far) lame collection of non-hacking dictionaries. Things like cities, English words, etc.
There was a time when the biggest dictionary I had, weighing in at 6.4mb, was a German wordlist. 6.4mb doesn’t sound like much, but at the time I was on a DSL connection; with about 400kbit upstream (on a good day), I could feel every download.
Yes, I’m still working on making the ultimate password list. And I don’t mean the 16gb one I made by taking pretty much every word or word-looking string on the Internet when I was a kid; that was called ultimater dictionary. No; I mean one that is streamlined, sorted, and will make Nmap the bruteforce tool of the future!
I don’t usually write two posts in one day, but today is a special occasion! I was reading my news feeds (well, my co-op student (ie, intern) was – I was doing paperwork), and noticed a story about a remote backdoor being included with the Energizer UsbCharger software</a>. Too funny!
As you probably know, I’ve been working hard on generating and evaluating passwords. My last post was all about Rockyou.com’s passwords; next post will (probably) be about different groups of passwords from my just updated password dictionaries page. This will be a little different, though.
As some of you know, I’ve been working on collecting leaked passwords/other dictionaries. I spent some time this week updating my wiki’s password page. Check it out and let me know what I’m missing, and I’ll go ahead and mirror it.
I’ve had a couple new developments in my password list, though. Besides having an entirely new layout, I’ve added some really cool data!
Just a quick note – I updated my blog template a bit. On the right, I added some new links and I added some info about myself at the top. I also added “previous” and “next” links above the posts. Hopefully these changes make it easier to get around. Let me know if I broke anything in the process!
I often find myself explaining to people how to install a script that isn’t included in Nmap. Rather than write it over and over, this is a quick tutorial.
If you were at Shmoocon this past weekend, you might remember a talk on Friday, done by Justin Morehouse and Tony Flick, on VMWare Guest Stealing. If you don’t, you probably started drinking too early. :)
I spent a good part of the past month traveling, which meant staying in several hotels, both planned and unplanned. There’s nothing like having a canceled flight and spending a boring night in San Francisco! But hey, why be bored when you have a packet sniffer installed? :)
Thanks for everybody who came out to my Toorcon talk! I had a great weekend, even the part where I got stuck in San Fransisco and spent two full days getting home. Oops :)
This is just a quick shout out to Michel Chamberland over at the SecurityWire blog. He wrote a <a href=http://blog.securitywire.com/2009/10/10/nmap-nse-script-to-enumerate-iscsi-targets/>Script to enumerate iSCSI Targets</a>. Unfortunately, I don’t have any iSCSI to test on, but if you do he’d love to hear from you!
I just finished updating my smb-check-vulns.nse Nmap script to check for the recent SMBv2 vulnerability, which had a proof-of-concept posted on full-disclosure.
WARNING: This script will cause vulnerable systems to bluescreen and restart. Do NOT run this in a production environment, unless you like angry phonecalls. You have been warned!
I was going to do a post about Nmap today, but since their svn is having some issues, you’re going to get something a little more fun (in my opinion)!
My friend snapped this picture in Vancouver, BC near Stanley Park (the picture is geocoded, so check out the Exif data if you want to know exactly where).
It’s been awhile since my last post, but don’t worry! I have a few lined up, particularly about scanning HTTP servers with Nmap. More on that soon!
In the meantime, I wanted to direct your attention to <a href=’http://blog.rootshell.be/2009/09/01/detecting-vulnerable-iis-ftp-hosts-using-nmap/’‘>This post (update here) about finding potentially vulnerable Microsoft FTP servers.
I’m just going to quote my Slashdot post inline.. check out the links for all the nitty gritty details. The bottom line is that 5.00 is awesome, and includes everything I’ve written as yet – download it! :)
I had the weirdest thing happen to me today, and I couldn't resist sharing it. If you're looking for security tips or tricks, move along. If you want a funny story (that sort of involves security), stick around!
For my SANS GPEN Gold certification (first Gold-certified analyst for GPEN – go me!) I wrote a paper on my SMB scripts for Nmap. The paper is titled “Scanning Windows Deeper With the Nmap Scanning Engine”. I started writing it a few months ago, and collaborated with Fyodor in the early stages. Hopefully it’s a useful guide!
I talk a bit about the theory and protocols behind the scripts, then dive into a few of the more interesting ones and talk about how they work and how they can be used.
With the upcoming release of Nmap 4.85, Brandon Enright posted some comments on random Nmap thoughts. One of the things he pointed out was that people hadn’t heard of nbstat.nse! Since I love showing off what I write, this blog was in order.
This morning I heard (from the security-basics mailing list, of all places) that there’s a zero-day vulnerability going around for WebDAV on Windows 2003. I always like a good vulnerability early in the week, so I decided to write an Nmap script to find it!
In case you haven’t heard, Fyodor released Nmap 4.85beta9 this week. This is the first release in awhile that wasn’t related to my code (or, most properly, mistakes :) ). It looks like the new stable version will be here soon, so give this one a shot and report your bugs. Here’s the download page.
With the help of Symantec’s Security Intelligence Analysis Team, I’ve put together a script that’ll detect Conficker (.C and up) based on its peer to peer ports. The script is called p2p-conficker.nse, and automatically runs against any Windows system when scripts are being used:
Last night Fyodor and crew rolled out Nmap 4.85beta7. This was because some folks from the Honeynet Project discovered a false negative (showed no infection where an infection was present), which was then confirmed by Tenable. We decided to be on the safe side, and updated our checks.
I’m going to start off this blog by wishing a happy birthday to a very important person – me. :)
Now, onto the content!
PsTools is a suite of tools developed by Sysinternals (now Microsoft). They’re a great complement to any pen test, and many of my Nmap scripts are loosely based on them. As good as they are, they aren’t without their quirks!
Here are a few topics worth discussing:
Ports and traffic
Specifying an account
Running it purely in a console
Most (possibly all) of the PsTools use standard Windows functions. That makes life easy – we can expect PsTools to act the same way other remote functions work. If we know how!
Today, I’m going to share some knowledge and techniques on bruteforcing Windows passwords. Hopefully, some of you have thought about this and can give me even more advice. If you know anything, post it!
Today I want to discuss how the pwdump6 and fgdump tools work, in detail, and how I was able to integrate pwdump6 into my Nmap scripts. Is this integration useful? Maybe or maybe not, but it was definitely an interesting problem.
Last month, I posted about some password dictionaries I’ve collected. Well, thanks to a hacker who compromised PHPBB’s site, I added another. There’s a big caveat to this one, though – these passwords are apparently based on ones that were cracked by the hacker, so they’re only an accurate representation of weak passwords.
I have a real post planned for the near future, but for now you’re stuck with something short (and probably more useful, ultimately). I just wanted to draw attention to a few password databases I put on my wiki. You can find them here.
I spent most of last Saturday exploring how SysInternals’ PsList program works, and how I could re-implement it as an Nmap script. I quickly discovered that the HKEY_PERFORMANCE_DATA (HKPD) registry hive was opened, then it got complicated. So I went digging for documentation and discovered a couple journals posts written by Microsoft’s Matt Pietrek wrote back in 1996. Those led me to the WinPerf.h header file. The three of those together were enough to get this working.
Microsoft released ms08-068 this week, which fixes a vulnerability that’s been present and documented since 2001. I’m going to write a quick overview of it here, although you’ll probably get a better one by reading The Metasploit Blog.
This is going to be a fairly high level discussion on the sequence of calls and packets required to make MSRPC calls over the SMB protocol. I’ve learned this from a combination of reading the book Implementing CIFS, watching other tools do their stuff with Wireshark, and plain ol’ guessing/checking.
Lately I’ve been putting a lot of work into Nmap scripts that’ll probe Windows deeply for information. I’m testing this with both authenticated and unauthenticated users, mostly to determine how well error conditions are handled. Every once in awhile, however, I notice something that the anonymous account or guest account can access that seems odd. And today, I felt like I ought to post a blog, so you get to hear about it!
As you can see from my past few posts, I’ve been working on implementing an SMB client in C. Once I got that into a stable state, I decided to pursue the second part of my goal for a bit – porting that code over to an Nmap script. Never having used Lua before, this was a little intimidating. So, to get my feet wet, I modified an existing script – netbios-smb-os-discovery.nse – to have a little bit of extra functionality:
Last post, I promised I’d post about NTLMv2 once I got it implemented. And, here we are.
The LMv2 and NTLMv2 responses are a little bit trickier than the first versions, although most of my trouble was trying to figure out how to use HMAC-MD5 in OpenSSL. The good news is that LMv2 and NTLMv2 are almost identical to each other, with only one minor difference.
As I’m sure you’ve noticed with my first two posts, my NetBIOS/SMB project is taking up most of my time. I hit a bump this weekend, and almost got to the point where the only valid answer was throwing things; luckily, however, I figured it out. I did make a new enemy, though: signed data types! The devil’s datatype.
My current project, as you can see by my last post, is to learn how to work in Microsoft’s networking protocols (NetBIOS, SMB, CIFS, etc). This is obviously difficult due to the lack of standards and documentation, but there are two things that are seriously making my life difficult:
All right, maybe 0.02 doesn’t sound so impressive, but I’ve put a lot of work into it so eh?
Anyway, I just finished putting together nbtool 0.02. It is partly a test program for myself, and partly a handy tool for probing NetBIOS networks. Here is a link to the tool itself (I’ve tested this on Linux, OS X (ppc + intel), iPhones, and Windows (cygwin)):
http://www.skullsecurity.org/wiki/index.php/Nbtool
To describe in text:
