Shamless Plugs, Unit Testing, and Fuzzing

So recently, I attended a product demo of Mu Security's Mu-4000 and I have to say that it's interesting. Essentally, the product is a fuzzer with components to automatically detect failure as defined by things like regular expression matching of logs of failure to pass network traffic from point a to b or vice versa, and isolate the input that caused that failure to occur.

All of this talk about fuzzing got me interested in looking at it again. So I started reading some of the material about PROTOS and the chapter in the Shellcoder's Handbook. Now one of the things that I've had the good fortune of being exposed to was my old roommate Ian's book Perl Testing: A Developer's Notebook. It amazes me as to how similar the process of writing a semi-intelligent fuzzer is to creating mocking objects for unit testing.

If you haven't been exposed to the whole extreme programming(XP), thing then the relationship may not be obvious. In the XP world you try to construct unit tests to cover as much code as is possible to make sure that you get the desired functionality. To achieve this level of code coverage one needs to fullfil dependencies for that function or method. For example if you're testing a function that is supposed to generate some data and send it back down an already established socket, what you really want to test is the data generation, but you'll need something that supports the API of the socket. This is where mocked objects come in. In this case you'd generate a class that acts like the socket and perhaps spits a response back to the piece of code your testing if neccessary. This way you can determine if the meat of the function works as expected or at the very least as tested.

Fuzzing or fuzz testing on the other hand aims at finding faults by injecting random data into a black box be it function/method calls, network data or any other input. So in a strange way it can be thought of as almost an inversion of unit testing with mocked objects. This becomes especially true when trying to isolate which particular input is the one that caused the error.

So a lot of the work in mocking is providing something that the program can interact with such that you can test the component you want. The same is true for fuzzing, you have to provide enough of the functionality to penetrate deep enough into the code to find the bug.

Matrioshka of Malware

One of the blogs I like to check in on regularly is Kaspersky labs' blog. Today I noticed an article about a new piece of malware, that works like the famous russian dolls. First it attracts users by spaming their ICQ accounts. Then it uses an encrypted/obfuscted javascript, to redirect the victim to download a java applet similarly obfuscated which then loads yet another obfuscated applet. Which loads another page with obfuscated which downloads a trojan horse which downloads another trojan horse. The last trojan horse as reported by Kaspersky labs changes on a weekly basis -- switching to a banking trojan currently.

So what can we make of this? First and foremost people fall prey to spam. Nothing new there. Second, it's become in the interest of criminals to attempt to slow the malware analysis process by using a set of complex interactions and scripts. One thing I wish the article had empahsized was how long did it take them to do the analysis of each piece and in total. As they've noted that the last trojan is changing regularly. This implies that the intermediary steps are staying relativly constant. But if they changed I imagine the analysis would take significantly longer each time.

All in all very interesting.

Friends Don't Let Friends Drink Cheap Beer

This is a repost. However since I'm still getting a lot of traffic from the Arbor Networks ASERT blog I figured I'd be lazy and just put the link back.

Before I get into my usual life rants let me tell you about the title. I went to the Black Cat last night and started drinking some mixed drinks for caffeine, I thought that the mixed drinks were pretty weak, so I decided that having a Miller Lite or two wouldn't be a problem. Now normally I'm a beer snob. I just don't have the stomach for the cheap stuff but for some reason I just felt like it. Now if you're out with friends and someone says hey [insert cheap beer name here] sounds good, stop them now I implore you. I got far too sick last night and am still paying for it as I type this.

It's been a while since I last wrote on this blog, and man have I been busy. I had my interview with Arbor Networks and was reminded just how green I am in this industry. Really smart people, and they certainly know how to dig through your brain for what you know. I came away from the process feeling drained and like I needed to learn more.

This is the second time in my life I've really felt like that after an interview. The last time was with Sun Microsystems. I remember being asked a crypto question that I just couldn't answer at the time -- how does diffie-hellman work? I could tell that my lack of understanding had sort of killed the interview. I believe that the main reason I was being considered for the job was because I had written a python script utilizing SRP. Now at the time I had never taken a class on crypto nor had I read any books on cryptography. So everything that I had tried to learn from the modules was cloudy at best.

Now wheather or not that was the one thing that caused Sun Microsystems not to hire me or if there were other factors, I don't know. But what I do know is how I reacted to that set back. It started with a small period of questioning my own ability followed by a reading freenzy. I remember that I went home for winter break after that ordeal and had picked up at least two books on crypto and tore through them as a man on a mission.

The interviews at Arbor left me in the same place. I found myself questioning what I knew and what had I done in the industry. Which means the next step is to ralley back. I know this sounds cheesy but it's just how I operate and in this light I've started tearing through my reading list again.

At the top of this list has been reading a paper from the 3rd USENIX Windows NT Symposium on Detours. Detours is a library for intercepting and extending x86 functions in a binary. Interception is achieved by rewriting the function to be rerouted at runtime so that it first goes through a user defined function.

So how does it do this? Detours replaces the first few instructions of the target function with an unconditional jump to a detour function containing user supplied code. After executing the code in the detour function, control is transfered to a trampoline function. The trampoline function contains the instructions of the target function that were replaced with the unconditional jump and an unconditional jump to the rest of the target function. Thus after the target function returns, control is returned to the detour function and then back to the original caller of the target function.

Why do this? If you've ever wondered about application protocols in closed source applications, you'll find a fair amount of encryption usage. This makes answering the question of how is the protocol structured more difficult you can't just fire up ethereal and look at data you need to dig around in program, using a debugger or disassembler. Often you'll find that you'll have to overcome packing or some checks for a debugger in order to actually see how the program works. All in all much more of a pain in the ass when you just want to look at a dump of the protocol.

The Matasano blog has a more concise write up of detours here