I read a lot of blogs / sites today... besides a few humourous stories like the McVirus... there were two items that really caught my attention... two items... four blog postings.... from the SecuriTeam Blog and Matasano Chargen.
Gil Dabah over at SecuriTeam started the day off with a Code Crunching - Tiny PE Challenge.
From the original post:
Ground rules
It might sound fairly easy at first, but it’s not, and there is merely one simple goal:
Grab a file from the Internet and execute it.
With the following rules:
1) Only Imports section is allowed for kernel32.dll to get LoadLibraryA and GetProcAddress.
2) All strings must not be viewable (except rule 1), so we xor…
Now, I can see that this is being written on a level that's both low and complex enough to exceed my current grasp... but I'll watch because it interests me greatly... From that same blog posting Gil mentions that he's gotten the file down to 411 bytes... The challenge was to drop the file below 400 bytes. This challenge was answered with a solution less than 24 hours later... by Gil, with a follow up post, offering a file a mere 384 bytes in size. This seems quite impressive... Something else I found of interest was a point made on DailyDave in a thread following this topic by Damien Miller... If the file is less than 536 bytes, it'll fit into a single UDP datagram without fragmentation.
The second item of interest was a software release from Thomas Ptacek over at Matasano Security. The software, blackbag 0.9, is described as:
(a) collection of sharp, pointy metal bars that I use to explore protocols and prototype tools. It is an intensely Unix-y answer to classic fuzzing tools like “Spike”, centering on a binary interactive netcat program.
My favourite part however was the Caveats section of the post:
Caveats: You aren’t going to be able to build this. I can build it clean under FreeBSD-CURRENT, Mac OS X, and OpenBSD. It has been built under Linux and Solaris in the past. If you make it work somewhere, post how you did it in a comment, and I’ll incorporate your fix.
I compiled this on SuSE Linux 10.1. Here's the process I took to install the software (commands in Italics, results in Bold Italics).
make
tsec.c: In function ‘main’:
tsec.c:44: error: too many arguments to function ‘setpgrp’
make: *** [tsec.o] Error
vi tsec.c
comment out line 44 -- if(setpgrp(0, getpid()) == -1) {
replace with -- if (setpgrp() == -1 ) {
:wq
make
--Successful Build--
sudo make install
I haven't had much of a chance yet to play with the software, however the small functions that are included I could see as being very useful.
Thomas followed the release up with a second posting regarding one of the tools from blackbag called sub. The article starts off with this great intro:
You’re starting on a new project, attacking a product with its own custom protocol. There’s a couple of things you’re going to do to get started, and then a few ways to go from there.
First, you’re going to set the product up and see it working in its natural habitat. Then, when you know it’s working, you’re going to repeat that step, this time with some form of traffic capture in place. (A year ago “capture” would have meant “sniffing” for me, but now it’s almost always a logging plugboard proxy. A good, easy-to-use [as in, no config files] proxy is one of the most valuable tools you can have).
Next, you’ll eyeball the captures to get an idea of how the protocol works. Your goal: break the TX stream up into individual messages, which you’ll later replay. You’ll do this in any of a number of ways, most of which involve a decent hex editor:
- Looking for common Type/Length/Value patterns, such as big-endian 32 bit integers less than 65k that match up in the hex dump.
- Looking for “signpost values”, byte sequences that occur at regular intervals, like “NTLMSSP” and “SMB” in the simplest cases.
- Looking for ASCII strings and delimiters, like NUL characters, or prefixing length words.
- Looking at the order in which traffic is sent, breaking up the stream at each place where the server responded.
- Feeding bytes to the real server one-at-a-time until a response is forthcoming.
If you’re me, your aim is a directory full of little files, like “msg.0”, “msg.1”, etc, any of which you can cat onto the network and observe the results. Which is what you’re going to do next, to see if messages are simply replayable as-is.
This made me think of a python tool that I wrote that essentially acts like tcpreplay... that I may make available in the near future. Now I don't want to past all of Thomas' article.. (as i've already CnP'd a good chunk there)... but the rest covers the usage of the command, and how it can apply to fuzzing. I definately suggest jumping over to the page and given it a read..
Peace,
HT
... I'll be updating it as I update my own feed... and I'll also welcome input from anyone who feels they have input to add. The file was exported from NewsFox, so if you import it into any other reader the feeds will be added in a folder called NewsFox.