Skip to main content

Let me tell you about my past two weeks

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.

Comments

Adam said…
Very cool stuff. Thanks for the insight.

Popular posts from this blog

Offset, Depth, Distance, and Within

Without going off the deep-end here and discussing every single Snort rule keyword, I just wanted to touch on a few modifiers that people sometimes misunderstand.  They aren't difficult, and hopefully after this explanation and a few examples, I can clear some of the air around these five modifiers.

The five modifiers that I am talking about are
OffsetDepthDistanceWithinnocaseThese five modifiers are not keywords of themselves, but rather they apply as modifiers to another keyword.  That keyword is "content". The content keyword is one of the easiest pieces of the Snort rules language as all it does is look for a particular string.  So for instance if I wanted to look for the word "joel" within a packet.  A simple:
content:"joel";Would allow me to do that.  The interesting part comes into play when you want to specify where inside of a particular packet you want the string "joel" to be looked for.  If you are running just a plain content ma…

Writing Snort Rules Correctly

Let me start off by saying I'm not bashing the writer of this article, and I'm trying not to be super critical.  I don't want to discourage this person from writing articles about Snort rules.  It's great when people in the Snort community step up and explain some simple things out there.  There are mistakes, it comes with the territory.  If you choose to be one of the people that tries to write Snort rules, you also choose to be someone who wants to learn how to do it better.  That's why I write this blog post, not to bash the writer, but to teach.

I noticed this post today over at the "Tao of Signature Writing" blog, and to be honest I glanced over most of it figuring it was a rehash of things I've already read or things that have already been written from countless people about "Here's how you write Snort rules!".  I scrolled down quickly skimming, not reading at all really, and noticed this part:
Now, let us look at the second questio…

Safari 5.1.4 now available

Safari 5.1.4 now available, fixes issues and improves performance | TUAW - The Unofficial Apple Weblog:


Improve JavaScript performanceImprove responsiveness when typing into the search field after changing network configurations or with an intermittent network connectionAddress an issue that could cause webpages to flash white when switching between Safari windowsAddress issues that prevented printing U.S. Postal Service shipping labels and embedded PDFsPreserve links in PDFs saved from webpagesFix an issue that could make Flash content appear incomplete after using gesture zoomingFix an issue that could cause the screen to dim while watching HTML5 videoImprove stability, compatibility and startup time when using extensionsAllow cookies set during regular browsing to be available after using Private BrowsingFix an issue that could cause some data to be left behind after pressing the "Remove All Website Data" button