OpenFPC, in other words, Leon is a Ninja

I put this up to basically draw attention to this project.  Leon (a fellow Sourcefire employee and Ninja over in the UK) can explain the project much better than I can, so I'll let him:

OpenFPC is a set of tools that combine to provide a lightweight full-packet network traffic recorder & buffering system. It's design goal is to allow non-expert users to deploy a distributed network traffic recorder on COTS hardware while integrating into existing alert and log management tools.

OpenFPC is described as lightweight because it follows a different design model to other FPC/Network traffic forensic tools that I have seen. It doesn't provide a user with the ability to trigger automatic events (IDS-like functions), or set watch events for anomalous traffic changes (NBA-like functions) as it is assumed external open source, or comercial tools already provide this detection capability. OpenFPC fits in as a companion to provide extra (full packet/traffic stream) data as a bolt-on to these tools allowing deeper analysis of event data where required.

Full packet capture is something that has been suggest as the answer to all by many.  I don't disagree, it does aid in the forensic investigation of traffic.  Heck I do it at my house (full packet capture).  I find this idea to very intuitive and interesting, especially the search capabilities.

To be honest, I've seen something like this before when I worked for the military.  I don't want to disclose where or what agency was using this, but it was vastly helpful when we wanted to investigate something.

We used Snort and another IDS to prompt us to look for something and we'd start going through the full packet captures to investigate it.  I got the idea for this from another Army agency that had a GUI for it, and the whole nine yards.  I thought it was a beautiful system and it worked great.  I was quite impressed.

Anyway, I'm glad to see that Leon is making a tool like this Open-Source.  I think this is a phenomenal idea, and I'd like to see something like this used in a test-production network system somewhere, just to prove how useful it could be.

OpenFPC.

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.

Verizon Rumored To Replace Google With Bing On All Android Devices

Yesterday, Spetember 9th, Verizon gave a preview to their newest "Android" phone coming out for their network, Samsung's Galaxy S.

It has a 4-in AMOLED screen, 1GHZ Hummingbird Processor, and it has the ability to become a hotspot.  However, Verizon has ruined the phone, and may ruin every phone on their network from now on.  Why?

The thing that makes Android great is it's integration.  Google built the OS, it's integrated into Google's infrastructure, and that's the way it works best.  Just like the iPhone, which works best with Apple's infrastructure (MobileMe, iTunes, etc).

Verizon has decided to cripple this phone by instead of tying it to Google, they have tied it to Bing.  Bing Search, Bing Maps, and instead of Google's awesome navigation app, they have replaced it with Verizon's own Navigation app, which, btw, they cleverly charge you 10 bucks a month to use.

Bloatware..  Blockbuster apps, Tetris apps that charge you money, etc.

To make it worse, Verizon has stated that they will be moving all of their "Droid" line to Bing.  It won't be exclusive, (meaning you can switch everything back to Google), but this is basically how to ruin a franchise.  (Verizon having Android on everything.)

This is where Verizon did it wrong with the iPhone as well.  When Apple came to Verizon and said "We are going to make a phone, you can be the carrier, but you can't put any apps or logos or anything on it"  Verizon said No.  So Apple went to Cingular (which later was bought by AT&T).  Cingular agreed, therefore the iPhone is on AT&T right now.

Apple's iPhone doesn't have bloatware (unless you count the apps that Apple puts on there themselves, which, I can understand your argument), it starts off with Google as the search engine by default, but you have the option to change it.

The iPhone doesn't force you to use a service, they force you to use the apps that are built in (unless you download new ones), like the "Maps" application, it's Google Maps and Google Search, but you'd almost never know it.  So far Apple hasn't ruined it, but we'll see.

Verizon may be ruining a good thing here.  Hopefully they don't.

Here's Gizmodo's review as well: here.

Verizon Rumored To Replace Google With Bing On All Android Devices | Markets | Minyanville.com.

The Heart of the Mustang is almost ready

351W Ford for my 1968 Mustang