The past couple weeks I've had the opportunity to do some really amazing work, something that most people, if they could do, would understand a lot more of what goes on behind the veiled curtain.
The last two weeks I worked for Sourcefire's
Vulnerability Research Team (VRT).
First I'd like to say that I've never worked with a more professional organization. Period. I came in to do some technical work with them, which consisted of analyzing hundreds of pcaps, tons of analysis, and as a result writing rules for those threats. We did, kind of a tech exchange type of thing.
Now, we weren't shooting in the dark. (even though there is no overhead lighting in the VRT offices, and you have to watch for getting hit in the head with a Nerf dart) The VRT doesn't take the random vulnerability or exploit found on exploit-db.com or milw0rm or whatever, and just bang out a rule for it. They do labor intensive work.
For instance, I had to write a rule for a vulnerability in a piece of software that had to do with email. In order to test of this vulnerability, could I have taken a piece of a malicious attachment, or looked for a malicious attachment and written a "signature" to check for the exploit here. Sourcefire's standard is higher than that. We try to not do that kind of thing. We try and write a rule to look for the vulnerability itself. For example: If the vulnerability is actually the fact that a certain field, if it's over 512 bytes, can be used to overflow a buffer in the software, looking for a series of "A"s isn't going to work. Looking to see if the field is bigger than 512 bytes is the correct way to do it.
But I digress….The easiest way to emulate this problem is to send an email with an attachment on it, and capture the pcap, then pick it apart from there. The problem with that is, most email (well at least Sourcefire's) is encrypted. So, I got with one of the other VRT guys and we came up with a solution.
Write an email delivery system.
So he did. It's in ruby, and it allows you to send an email, just like any other email client would, unencrypted, and much faster and more reliable than a regular email client would, if we were trying to trick the client into doing something.
We took the ruby script that he wrote, made it attach a file in base64, and captured the pcap. Now, you may ask me a question, "Heck, why didn't you just make a new email with Outlook Express and make an attachment and send it?" Because Outlook Express uses a different attachment system, it's crackheaded, and it's non-standard. Don't believe me? Send an email with Outlook and then send an email with Outlook Express and compare the two pcaps.
So I captured the pcap -- that's all well and good, except that I noticed that the checksums in the pcap was wrong. Sometimes when you capture traffic on an interface, on certain OSes, it will capture the traffic before the checksum is computed, so it will write to disk incorrectly. So that has to be corrected before you can write a rule to look for the vulnerability.
So, I used tcprewrite to correct the checksums on the packet, and off I went from there.
Now, you come up with the realization that this happens, sometimes 10-20x a day for the VRT, and you come to realize that the rules that are written by these guys are very professional and come with a higher degree of accuracy and purpose.
I'd like to thank the VRT to allowing me to come in and learn and share with them. I hope I helped them out as much as they helped me.
Final thought -- Take your time when writing your rules. The time spent writing them makes for a much more reliable rule than just banging out a rule…. and I have seen a lot of "just banging out a quick rule" lately. A quick rule usually isn't a rule. It's a signature. There is a difference.
Oh, and whomever wrote the Microsoft Word and Excel standard is a crazy crack smoker.
Long live Razorback.
