Seven Cool Open Source Projects for Defenders

TaoSecurity: Seven Cool Open Source Projects for Defenders.

Richard Bejtlich wrote this good post over on his blog, a few good OpenSource tools to defend your networks with.  He talks about the newest updates with:

• Rumainte IDS


• Security Onion


• Bro IDS


• Suricata IDS


• Snorby


• OpenFPC


• Polman


• Snort


• ClamAV


• Razorback

Richard does pay me a kind compliment, so thank you Richard.  Take a look at his post and try some of the tools out.

Whew, what a whirlwind

Talk about a busy end of the year, so on top of going my actual consulting gigs for customers, I am also doing the other full time job I have of the Snort Community Manager. If you read my blog, you've known this.

So, what have I worked on so far.

• Snort Twitter account. Not really a lot of work here, other than getting Twitter to remove it from the parker's clutches and give it to us.


• Snort Blog. Getting this set up, with the DNS entries, blog posts, editing, writing, design, and even the banner image (thanks CC for that!) was about 3 weeks worth of work.  Check it out http://blog.snort.org


• Snort Mailing list/Forum Consolidation. I thought it best to let the Community decide, so I made a non-scientific poll to choose between the forums, the mailing lists, or the penultimate solution, to merge the two. Thought of Google Groups for this. Google Groups allows you to post like a forum, and post like a mailing lists, and Google Groups takes care of the arrangement, merging, and threading. Very nice. I had this all set up, and was preparing for everyone to start making the move over to Google Groups, and we came up with another idea. So we're working that angle right now (stay tuned).


• Snort Subscriptions. Been doing a bit of backend work on Snort subscriptions, trying to figure out how to work this out to be a more streamlined process and eliminate a lot of the headache and purchasing obstacles for our users. Concept work mostly.  Also talking about VRT Subscriptions with various members of the legal team and VRT.


• ClamAV subscriptions. Working on what we are doing and going to do for certified ClamAV code.


• Code licensing. Meetings with our legal team!


• Writing articles for magazines and getting ready for speaking engagements in 2011. Pretty much what it says.


• Laying the groundwork for webcasts and Snort User Group Meetings. Going to fire these up in 2011 again. Several Snort User Group meetings are wanting to start back up. Great to see that there is a lot of interest for our community.


• Bug filing and progress. What I've started doing is, if bug reports come in via various methods of bug reports, I take them in, triage them, put them into bugzilla, and provide feedback to the people that filed the bugs. This seems to be working quite well right now.


• Working with our Web-team on any Snort.org issues. Pretty much what it sounds like.


• Fixing Snort.org. For instance, I rearranged the http://www.snort.org/docs link. To bring the content that people are looking for the most to the front page. Also it was brought to my attention that we had a bunch of W3C html coding errors. I went through and fixed about 40+ of these.  Along with about 100 other barely seen or noticed changes to Snort.org in order to bring the good content to the front, and the content that is barely used to the back (or done away with).


• Internal VRT Subscriptions. It was brought to my attention that several people that work at Sourcefire apparently didn't have access to the VRT rules (like they should have).  Had to fix that!

Had an email that today that asked me about all these new "news" dissemination  methods that we are standing up and is it going to create confusion.  That's probably a blog post left for the Snort.org blog.

Snort has a Twitter account

Another post for my Snort/IDS audience that read my blog.

We managed to get a hold of the "Snort" account on Twitter.  Someone was simply squatting on the name, not using it, so Twitter has a way of petitioning to get a hold of a name for a bunch of different reasons.  So we got with Twitter and they freed up the @Snort Twitter name for us.

Using the @Snort Twitter account we'll post new news, upcoming items, blog posts, news about Snort and interesting other tidbits that may or may not be found anywhere else on Snort.org

Check it out, follow us:  http://twitter.com/Snort.  Thanks!

Snort 2.9.0.2 Released!

To let my Snort audience know, if you don't know already by the mailing list, we just released Snort v2.9.0.2, a bug fix release.  Enjoy!

Snort :: Snort 2.9.0.2 Released!.

"So I have this IDS now what?" presentation at BSidesDE

Joel Esler, so I have this IDS now what BSidesDE1 on USTREAM. Conference.

Above is a link to my presentation from BSidesDelaware a couple weeks ago.  For some reason the audio and video are like 5 minutes off, but the presentation (for the most part) is intact.

New Role at Sourcefire

This is just an announcement to let the users of our OpenSource products know that we have a new community manager here at Sourcefire.

Over the past year or so, Mike Guiterman, our former Community Manager has taken on a different role within Sourcefire.  In the meantime, I've been filling some of the void.

For those of you that weren't able to make the Snort Rally/Pig Roast this past Friday at Sourcefire HQ, I have been officially assigned the role of Sourcefire's OpenSource Community Manager.

I know many of you, but for those who I don't, I came from the OpenSource community, working for the government using Snort in actual deployments.  I submit rules to VRT, and was one of the original submitters to BleedingSnort (Now Emerging Threats).  I've worked with both the OpenSource community and with our Corporate customers since I came to Sourcefire giving me first hand knowledge at how the community plays a vital role in the direction, development, and QA of our products.

I'll be focusing on product innovation in our OpenSource projects, as well as:

• Communicating with the communities.


• Being available to answer questions and receive comments.


• Coordinating the release of OpenSource project software.


• Providing whitepapers and instructional materials on our software.


• Providing the go-between for the OpenSource communities and Sourcefire software developers, including receiving OSS feature requests and bugs.  Entering these into our internal bug tracking system, and following up with the submitters.


• Snort-Groups.  Standing these back up, both virtually and in person.


• Speaking about our software at events and shows.

I have several projects in mind alerady, but the first thing is I want to hear from you.  Suggestions, ideas, complaints, and compliments.

• How we can make things better.


• Problems with Snort, ClamAV, DaemonLogger, or Razorback


• Features you'd like to see with these projects


• What isn't working now?


• What is working now!


• How can we make bug tracking more efficient?


• How can we make False positive submissions better?


• What can we put out (in terms of training and whitepapers) for better understanding and results?


• ???

Let me hear it.  Email me directly at jesler@sourcefire.com.  I want to be able to track your ideas so I can write you back when we make movement.

I'll summarize your submissions in a blog post in the future and let everyone know where we are at with the progress of these great ideas.

I'd like to thank people both internally at Sourcefire and the community for building the community into what it is today, and I look forward to a great future!  Also thanks to Mike Guiterman for his years of hard service working with our OpenSource communities.

For Razorback(tm) please continue to submit feature requests and any
other Razorback items to the Razorback Trac at:

http://sourceforge.net/apps/trac/razorbacktm/

And for Nugget related items please use:

http://sourceforge.net/apps/trac/nuggetfarm/

You can of course, also use the mailing lists for Razorback and the
Nugget Farm.

Snort Community Pig Roast

(If you read this on Twitter, please RT!)

Sourcefire is going to throw a community pig roast at our World Wide Headquarters on November 12, 2010.  We'll have some talks by Marty Roesch (our fearless leader) and Matt Watchinski (or VRT fearless leader).

Date: Friday, November 12, 2010
Time: 12:00PM

Where: Sourcefire HQ
9770 Patuxent Woods Dr.
Columbia, MD 21046

The event is open to our community, and we'd like you to come on over and hang out!

Please RSVP at: http://now.sourcefire.com/?elqPURLPage=2?elqformname=101112_snort_bbq&URL=

Ray Ozzie leaving post as Microsoft's chief software architect

Ray Ozzie is the gentleman that took Bill Gates's place after he retired from his day to day duties at Microsoft, and unfortunately, this kinda makes me feel more confident in the opinion I had when that event took place.

Microsoft is losing their spirit.

Let's face it, it's quite obvious now that Bill Gates was the driver behind the Microsoft brand and direction.  This is the third notable post that is being vacated since Bill Gates left (the first being the designer behind the Zune interface Robbie Bach, second being CFO Chris Liddell), and yet, somehow Ballmer stays in charge.

Don't get me wrong, Ballmer knows how to make money.  Which is why he's a good CEO, but in my opinion, it doesn't feel like he is ushering in a strong "direction" for the company.  But maybe I'm being a little critical, trying not to compare him to Steve Jobs, but hate him or love him, Steve Jobs is a great CEO.

It just feels to me that Microsoft is playing the catchup game.  Saying "me too" to everything that is coming out.  Windows Mobile Phone 7, (which was started a long time ago, but not until the iPhone came out was serious pressure put on this), the Xbox360 (which is probably Microsoft's best product), the Zune copied after the iPod, Windows's constant comparison to OSX, chasing after Google with Bing, and chasing after the iPad now with whatever-the-heck tablets (slate) they come out with.

Sad part is, Microsoft almost invented the tablet business.  They pretty much pioneered it.  However, they tried to shoe horn a Desktop OS into a tablet PC and wrote enough software to be able to use a pen.  Well, it doesn't appear to have caught on en-masse.  They didn't go back to the drawing board (like they did with Windows Mobile Phone 7) and design a new user interface, even if they copied the WMP7 interface from the Zune HD.  Their current tablet offering does not bode well for touch, and it's unclear where their future direction is going as far as touch is concerned, but it doesn't look good right now.  It still looks like they are trying to shoehorn Windows 7, the desktop operating system, into the tablet.  It's not going to work!  You tried that once, and it failed.  So I refer to the current class of computing devices (the iPad, and all the competitors that are trying to come out now as "slate" devices.)

Ray Ozzie, as it states in the below linked article, is best known for creating Lotus Notes.  Which really doesn't speak volumes to quality, but it does speak to success.  Even a totally awful program can make tons of money.  But Mr. Ozzie didn't seem to provide the direction that Gates did.  Face it, Gates was the genius behind the Microsoft brand.  Even if his tactic was to copy everything he saw, which I'm not saying he did, but even if his tactic was that, it was genius and it worked well.

I am not a Microsoft Shareholder, heck, I'm not even an Apple shareholder anymore,  but I'd wonder why Ballmer was still in power considering the stock price hasn't moved much in over 10 years.

Ray Ozzie leaving post as Microsofts chief software architect.

I'm speaking at Security B-Sides Delaware

We have a lot going on in Delaware.  Tax-free shopping, we elect crazy people, and we have the Security B-sides Delaware event happening in November.

I was asked if I would submit a talk to the conference, and lo and behold, it was accepted. (Along with a bunch of other great presenters, check out the first round of CFP accepts here.  Hopefully lots of people will come.  I actually have a confession to make, I've never actually been to a Security B-sides, although, from watching the Twitter, they are very popular.

Abstract of my talk:

Shining light into the "now what" arena of IDS and IPS tuning, I'll talk about  what the next steps should be with the alerts, tuning, and maintenance of the ruleset and  configuration deployed into an IDS or an IPS.  General guidelines will be provided, however,  all guidelines must be adapted to your specific environment.

I look forward you seeing many of you there, thanks for supporting B-sides.  Okay, back to making slides.

Security B-Sides / BSidesDelaware.

Snort 2.9.0 has been released

Now available from Snort.org, Snort 2.9.0 and DAQ 0.2.    I'll be writing some articles at some point to expand upon some of the functionality of Snort 2.9, but for now, know that there are some very nice new keywords in 2.9 and also an improved Stream model, as well as lots of improvements all over the place in the engine.

...and now some cut and paste from the release notes!   Download it now!

http://www.snort.org/snort-downloads

[*] New Additions
* Feature rich IPS mode including improvements to Stream for
inline deployments.  Additionally a common active response API is
used for all packet responses, including those from Stream,
Respond, or React.  A new response module, respond3, supports the
syntax of both resp & resp2, including strafing for passive
deployments.  When Snort is deployed inline, a new preprocessor
has been added to handle packet normalization to allow Snort
to interpret a packet the same way as the receiving host.

* Use of a Data Acquisition API (DAQ) that supports many different
packet access methods including libpcap, netfilterq, IPFW, and
afpacket.  For libpcap, version 1.0 or higher is now required.
The DAQ library can be updated independently from Snort and is
a separate module that Snort links to.

* A new rule option 'byte_extract' that allows extracted values to
be used in subsequent rule options for isdataat, byte_test,
byte_jump, and content distance/within/depth/offset.

* Two new rule options to support base64 decoding of certain pieces
of data and inspection of the base64 data via subsequent rule
options.

* Added a new pattern matcher that supports Intel's Quick Assist
Technology for improved performance on supported hardware
platforms.  Visit http://www.intel.com to find out more about
Intel Quick Assist.

[*] Improvements
* Updates to HTTP Inspect to extract and log IP addresses from
X-Forward-For and True-Client-IP header fields when Snort generates
events on HTTP traffic.

* Updates to SMTP preprocessor to support MIME attachment decoding
across multiple packets.

* Updates to the Snort packet decoders for IPv6 for improvements to
anomaly detection.

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.

Now that I have these IDS events, now what?

In my full-time job I work for Sourcefire, as a Sourcefire and Snort Professional Services Consultant.  I deal with a different customer every week (sometimes every day), and with each customer comes a separate set of IDS events.  Customers will often tell me "this network is unlike any you've ever seen before", and for the most part, they are right.  While all networks consist of servers, desktops, switches, routers, firewalls, antivirus, and even IDSes, all networks are essentially the same in that respect.  However, each of them pose their own unique set up and vulnerability attack-landscape.  Each network is unique in this way, it doesn't matter if you have 300,000 users on your network or 10.  All that does is make your life as a security person more difficult, this is essentially a number.  That number may increase lots of things, people hired to handle them, number of sensors needed, the amount of bandwidth needed, etc.

So, in dealing with the hundreds, perhaps hundreds of thousands, perhaps millions of IDS events that I see during the day on different networks, how do I deal with them?  How can I get into a customer engagement and turn 400,000 events a day into 100?   How do I help my customers deal with this?

My answer is: One at a time.

How do I do it?  Well, I take the same fundamentals as I have applied to Getting Things Done and Inbox Zero (mostly the latter) to IDS events.  In other words, for each IDS or IPS event, there is at least one (maybe multiple) outcome(s) to that event.  While yes, that may seem redundant, (and it is) my point in saying that is that there should always be an outcome to any IDS event.  It shouldn't just sit.  You shouldn't just be "moving events to archive".

You can kind of think this as a flow chart.

First -> Look at the event, let's use this event as an example:

POLICY Adobe FLV file transfer

Analyze it in context, what does this event mean?  It means someone is watching a flash video on the internet.  Okay, big deal right?  Is that allowed by policy?  Look at the packet data, is it from youtube?  Is watching YouTube from the corporate network allowed?  Perhaps if you are on a Government network, this isn't allowed, okay, so what next?  Do I need to look at the flows around it recorded by Netflow or RNA?  Do I need to look at my SIEM tool?

Second, Now comes where you ask "what relevancy does this have to my network?"  If it's a Sourcefire protected network (read: not Snort) then you might have RNA to help you perform this function.  How is the impact rating on the alert?  Is it high?  Is the end host vulnerable to this "exploit"?  The impact rating for the above event is probably pretty high, since every browser on every OS (for the most part) can watch a flash video.  How old is the rule or alert?  Does it cover a CVE that was patched in 2002?

Now that we know what the event is, and what relevancy it has to our network, what are we going to do about it?  Well, I view this has having about four possible outcomes.  Of course, this is related to Snort, so your IPS may vary.  But all IPSes get better with tuning, so...

1. If you are in IPS mode, do you want to block it or not?


2. Threshold or Surpress?


3. Edit the rule manually?


4. Shut the rule off?


5. Does it provide relevance to other rules?


6. DO something about the alert.

1.  Set the rule to drop.

This only works if you are in IPS mode, should you change the rule to drop?  Do you want the traffic to go into the big bit bucket in the sky?  Prevent that FLV file from being downloaded?  Prevent that PDF from being downloaded, prevent that newest browser exploit?  If you are in IPS mode, this is your second question after you analyze the event.

2. Threshold or Suppress?

Thresholding in Snort essentially means you still want the rule to alert, but not as much.  Or not until a certain threshold is reached (or both).  Suppressing means you want to turn off alerting to a certain IP or CIDR block.  Say for instance an SNMP alert going to your HP OpenView server.  Legit traffic, so tune it out.

3. Edit the rule.

Probably something you want to stay away from as much as possible, unless you editing your own rules.  But it's always an option to edit the rule manually to reduce false positives.

4. Turn the rule off.

Is the rule out of date?  Do none of the above apply?  Has it no relevance to your network?  For instance, using our above example, if watching flash videos is allowed on the network, and you don't want to track to see if people are doing that kind of thing, then shut the rule off.  If you aren't going to use the final step in this process (DO SOMETHING) then do you need the rule?

5.  Is the rule providing you contextually aware information?

Some rules will make no sense on their own, but they may provide a contextual awareness to other rules.  For instance, if there was a rule to watch for vulnerabilities within a certain flash video file format to exploit older versions of the flash player, that rule coupled with the above example, may provide better contextually aware alerts.  You know the video was bad, but now you can refer back to the above example and perhaps see where the alert came from.  Kind of a bad example, because you could do it either way, but hopefully you grasp my point.

6. DO SOMETHING.

This requires you to go mitigate the problem.  Whether that be to "file a ticket" for your helpdesk to clean off spyware, clean up a botnet, perhaps you'll need to pull forensics on the host machine, perhaps you'll need to pull web proxy logs to get better awareness.  But this is the step where you actually have to use the alerts generated by your IDS to do your job.  Find the bad guy, eradicate the badness from the network, and move onto the next alert.  After all, that's the point of having an IDS or IPS right?

Following these simple steps should allow you to have a greater awareness of the alerts on the network, and perhaps actually do something about them.  Getting an IDS alert and then "moving it to archive" or "marking it as reviewed" is doing nothing.  Following the above ACTION steps should give you a more streamlined IDS or IPS, and then only cause your system to alerts when you need to conduct step 6, above.  DO SOMETHING.

Contrary to Recent Assertions - Snort 2.9 beta has been released, and it's awesome..

Snort 2.9 has been in the works now internally for awhile and the first beta release is out and ready for community feedback.

It's a big release with lots of enhancements, so here are the current list of things that need to be beta tested in Snort 2.9, and I'll expand upon them a bit:

* Feature rich IPS mode including improvements to Stream for inline deployments. A common active response API is used for all packet responses, including those from Stream, Respond, or React. A new response module, respond3, supports the syntax of both resp & resp2, including strafing for passive deployments. When Snort is deployed inline, a new preprocessor has been added to handle packet normalization to allow Snort to interpret a packet the same way as the receiving host.

This feature really does away with a lot of the old react/resp/reset code and unifies all that broken code under respond3.  It also allows for RST and ICMP injection into a stream in IPS mode (more reliable than IDS), so, for example, you want to cut a session off in midstream.  In regular IPS mode, we can drop the connection quietly.  With the new response module we can properly inject a RST (or other close) packet into a dropped stream, resetting the connection so that the end hosts don't have open TCP sockets.  There is also a normalization preprocessor,  (See README.normalize), which, essentially, cleans packets up.  For example here a just a few things that the normalization preprocessor can do to TCP:

• Remove data on SYN.


• Clear the reserved bits in the TCP header.


• Clear the urgent pointer if the urgent flag is not set.


• Clear the urgent pointer and the urgent flag if there is no payload.


• Set the urgent pointer to the payload length if it is greater than the payload length.


• Clear the urgent flag if the urgent pointer is not set.


• [..]

Flexresp (Flex Response) 1 and 2 are now deprecated and a new Flexresp3 has been introduced.  Flexresp3 supports ALL of the flexresp1 and flexresp2 keywords and syntax.  Easy to move right over.

* Use of a Data Acquisition API (DAQ) that supports many different
packet access methods including libpcap, netfilterq, IPFW, and
afpacket. For libpcap, version 1.0 or higher is now required.
The DAQ library can be updated independently from Snort and is
a separate module that Snort links. See README.daq for details
on using Snort and the new DAQ.

Hooray!  Libpcap 1.0 is now required.  Hooray Libdnet!  As you can read above, Snort 2.9 adds support for nfq and afpacket.  In addition to ipfw, ipq, and dump that they've read already.  IPQ wasn't working as well in past releases, so we replaced it with netfilterq.

* Updates to HTTP Inspect to extract and log IP addresses from
X-Forward-For and True-Client-IP header fields when Snort generates
events on HTTP traffic.

This was a feature requested by one of our community people.  They didn't want to see the IPs of their proxies as Source or Destination IPs in HTTP alerts.  They wanted the ability to see the "real" IPs for those proxies that support "X-Forward-For" and "True-Client-IP" header fields in their packets.  This output is only available if you are using the Unified2 output method.

Those of you that are NOT using Unified2 really, really need to move to it.  Older, slower, output methods are eventually going to be deprecated, so please, start your upgrades.

* A new rule option 'byte_extract' that allows extracted values to
be used in subsequent rule options for isdataat, byte_test,
byte_jump, and content distance/within/depth/offset.

This was a feature requested by the community as well, it came from an email I received as a request that we add something like this in Snort.  The ability to yank a value out of a packet and store it for later use with other keywords.  (Unlike byte_test or byte_jump that calculates the value on the fly.)

* Updates to SMTP preprocessor to support MIME attachment decoding
across multiple packets.

I think that one speaks for itself, but make sure you read README.SMTP in the doc/ directory of the tarball to make sure you fully understand what this does.

* Ability to "test" drop rules using Inline Test Mode. Snort will
indicate a packet would have been dropped in the unified2 and console event log if policy mode was set to inline.

This was a feature, also requested by our community.  They wanted to know, for a fact, what traffic would have been dropped had the rule in question be set to drop.  Again, this output is only available in Unifed2 and console, so please start moving over!

* Two new rule options to support base64 decoding of certain pieces
of data and inspection of the base64 data via subsequent rule
options.

Nice feature here.  Base64 decoding in a rule.

* Updates to the Snort packet decoders for IPv6 for improvements to
anomaly detection.

Also added into README.normalize.  This is to continue to support the United States Government's push to IPv6.  In many environments, this is now mandatory.

* Added a new pattern matcher that supports Intel's Quick Assist
Technology for improved performance on supported hardware
platforms. Visit http://www.intel.com to find out more about
Intel Quick Assist. The following document describes Snort's
integration with the Quick Assist Technology
http://download.intel.com/embedded/applications/networksecurity/324029.pdf

This optimization is very hardware specific.  Make sure you read the PDF linked above which is a joint research project underway by Sourcefire and Intel.

I'm sure more tweaks and things will be added to 2.9 before it's actual release, so I look forward to these enhancements.

Be sure and check out Snort 2.9's beta code here, at http://www.snort.org/

Project Razorback has been unleashed on the World

For several months, the Vulnerability Research Team (VRT) here at Sourcefire has been heads down in coming up with a new framework for detection called Razorback, and now, it's been unveiled to the world this this morning.

Being announced at Defcon this weekend by the VRT, so if you are in Defcon this week, reading my posts, First: Have a beer for me, as I am not there this year due to the impending birth of my child, and Second: Attend this talk.  If no other talks are attended during your drunken hacking binge in Vegas, go to this talk.

OH AND BUY THE VRT BEER IF YOU MEET THEM.  Mkay?

What is Razorback?

In Marketing speak: "Razorback is an Open-Source Framework for an intelligence driven security solution."  Okay, okay, what does that mean?

Razorback is a system that detects and decodes, well, just about anything you need it to.  Following that, it has the ability to then block and alert on that activity.  So, for example:

• Obfuscated Javascript?  Decoded, Blocked?


• Bad PDFs? Decoded, Blocked?


• Bad Word Documents? Powerpoint Documents? Decoded, Blocked?

This framework is aimed primarily at these Client based attacks, and, dare I use it?  Advanced Persistent Threat (APT).  It was born out of necessity and a discussion with the VRT during a panel they participated in last year about detection.  The community asked for something to be able to perform a function like this, and well, here it is.  Better.  There is nothing to combat these threats, so Sourcefire created one.

So, say for example, a PDF comes in via email.  The PDF is sent to Razorback by the SMTP engine, Razorback runs it through the detection, -- which I'm not even going to begin to explain here, because it's extremely awesome and complicated, and you should go to the talk to fully understand --, and if the detection decides the PDF is bad, it will record that fact in it's database so that all further attempts with a PDF like that one will be blocked from there on out.   Now, that's just one example.

Since Razorback is an Open-Source project and framework, anyone can write a detection "nugget" for it.  These nuggets, written in C, can detect pretty much anything and provide actionable intelligence on it afterwards, and of course, since it's Open-Source, many different "feeds" can be provided to Razorback.

SMTP, ClamAV, Snort, Web proxies, Web filtering devices, et all.  They can all be written to feed data to Razorback which then can have the ability to take further action after it's analyzation.

This is a different approach to detection than what's been tried before.  While IPS is great, it can't really grab a PDF off the wire, reassemble it, decode it, and block it in real-time.  With Razorback, Snort can grab the PDF off the wire, pass it to Razorback where it will be analyzed, and so on.

After the talk if the VRT puts their slides and more info up on their website, I'll make sure that I post further information about it.  But for now, here it is:

Razorback.

Here's another article about Razorback over at DarkReading.

Safari 5.0.1 Posted this morning

Back in June I wrote a post on a problem with Safari 5 creating a black background around certain objects when moved from one application to another.  For instance, when you attempt to use the "Mail this PDF" function from Preview.  Well, this morning Apple released version 5.0.1 of Safari.  This fixes the issue I described here, along with many others.  As posted on Apple's website here, the following are fixes:

• More accurate Top Hit results in the Address Field


• More accurate timing for CSS animations


• Better stability when using the Safari Reader keyboard shortcut


• Better stability when scrolling through MobileMe Mail


• Fixes display of multipage articles from www.rollingstone.com in Safari Reader


• Fixes an issue that prevented Google Wave and other websites using JavaScript encryption libraries from working correctly on 32-bit systems


• Fixes an issue that prevented Safari from launching on Leopard systems with network home directories


• Fixes an issue that could cause borders on YouTube thumbnails to disappear when hovering over the thumbnail image


• Fixes an issue that could cause Flash content to overlap with other content on www.facebook.com, www.crateandbarrel.com, and other sites when using Flash 10.1


• Fixes an issue that prevented boarding passes from www.aa.com from printing correctly


• Fixes an issue that could cause DNS prefetching requests to overburden certain routers


• Fixes an issue that could cause VoiceOver to misidentify elements of webpages

Safari 5.0.1 also packs in a bunch of security updates.  Of course Blackhat and Defcon are this week, so that may have something to do with this update being released.

Safari
Impact: Accessing a maliciously crafted RSS feed may cause files from the user's system to be sent to a remote server
Description: A cross-site scripting issue exists in Safari's handling of RSS feeds. Accessing a maliciously crafted RSS feed may cause files from the user's system to be sent to a remote server. This issue is addressed through improved handling of RSS feeds.
Credit to Billy Rios of the Google Security Team for reporting this
issue.

Safari
Impact: Safari's AutoFill feature may disclose information to websites without user interaction
Description: Safari's AutoFill feature can automatically fill out web forms using designated information in your Mac OS X Address Book, Outlook, or Windows Address Book. By design, user action is required for AutoFill to operate within a web form. An implementation issue exists that allows a maliciously crafted website to trigger AutoFill without user interaction. This can result in the disclosure of information contained within the user's Address Book Card. To trigger the issue, the following two situations are required. First, in Safari : Preferences : AutoFill, the "Autofill web forms using info from my Address Book card" checkbox must be checked. Second, the user's Address Book must have a Card designated as "My Card". Only the information in that specific card is accessed via AutoFill. This issue is addressed by prohibiting AutoFill from using information without user action. Devices running iOS are not affected.
Credit to Jeremiah Grossman of WhiteHat Security for reporting this issue.
(Nice work Jeremiah!)

WebKit
Impact: Visiting a maliciously crafted website may lead to an unexpected application termination or arbitrary code execution
Description: A use after free issue exists in WebKit's handling of element focus. Visiting a maliciously crafted website may lead to an unexpected application termination or arbitrary code execution. This issue is addressed through improved handling of element focus.
Credit to Tony Chang of Google, Inc. for reporting this issue.

WebKit
Impact: Visiting a maliciously crafted website may lead to an unexpected application termination or arbitrary code execution
Description: A memory corruption issue exists in WebKit's rendering of inline elements. Visiting a maliciously crafted website may lead to an unexpected application termination or arbitrary code execution. This issue is addressed through improved bounds checking.
Credit to wushi of team509 for reporting this issue.

WebKit
Impact: Visiting a maliciously crafted website may lead to an unexpected application termination or arbitrary code execution
Description: A memory corruption issue exists in WebKit's handling of dynamic modifications to text nodes. Visiting a maliciously crafted website may lead to an unexpected application termination or arbitrary code execution. This issue is addressed through improved memory management.
Credit? Apple Internal?

WebKit
Impact: Visiting a maliciously crafted website may lead to an unexpected application termination or arbitrary code execution
Description: A memory corruption issue exists in WebKit's handling of CSS counters. Visiting a maliciously crafted website may lead to an unexpected application termination or arbitrary code execution.
This issue is addressed through improved memory management.
Credit to wushi of team509, working with TippingPoint's Zero Day Initiative for
reporting this issue.

WebKit
Impact: Visiting a maliciously crafted website may lead to an unexpected application termination or arbitrary code execution
Description: An uninitialized memory access issue exists in WebKit's handling of the :first-letter and :first-line pseudo-elements in SVG text elements. Visiting a maliciously crafted website may lead to an unexpected application termination or arbitrary code execution. This issue is addressed by not rendering :first-letter or :first-line pseudo-elements in SVG text elements.
Credit to wushi of team509, working with TippingPoint's Zero Day Initiative for reporting this issue.

WebKit
Impact: Visiting a maliciously crafted website may lead to an unexpected application termination or arbitrary code execution
Description: A use after free issue exists in WebKit's handling of foreignObject elements in SVG documents. Visiting a maliciously crafted website may lead to an unexpected application termination or arbitrary code execution. This issue is addressed through additional validation of SVG documents.
Credit to wushi of team509, working with TippingPoint's Zero Day Initiative for reporting this issue.

WebKit
Impact: Visiting a maliciously crafted website may lead to an unexpected application termination or arbitrary code execution
Description: A memory corruption issue exists in WebKit's handling of floating elements in SVG documents. Visiting a maliciously crafted website may lead to an unexpected application termination or arbitrary code execution. This issue is addressed through improved memory management.
Credit? Apple Internal?

WebKit
Impact: Visiting a maliciously crafted website may lead to an unexpected application termination or arbitrary code execution
Description: A memory corruption issue exists in WebKit's handling of 'use' elements in SVG documents. Visiting a maliciously crafted website may lead to an unexpected application termination or arbitrary code execution. This issue is addressed through improved handling of 'use' elements in SVG documents. Credit to Justin Schuh of Google, Inc. for reporting this issue.

WebKit
Impact: Visiting a maliciously crafted website may lead to an unexpected application termination or arbitrary code execution
Description: A heap buffer overflow exists in WebKit's handling of JavaScript string objects. Visiting a maliciously crafted website may lead to an unexpected application termination or arbitrary code execution. This issue is addressed through improved bounds checking.
Credit: Apple.

WebKit
Impact: Visiting a maliciously crafted website may lead to an unexpected application termination or arbitrary code execution
Description: A reentrancy issue exists in WebKit's handling of just- in-time compiled JavaScript stubs. Visiting a maliciously crafted website may lead to an unexpected application termination or arbitrary code execution. This issue is addressed through improved synchronization.
Credit? Apple Internal?

WebKit
Impact: Visiting a maliciously crafted website may lead to an unexpected application termination or arbitrary code execution
Description: A signedness issue exists in WebKit's handling of JavaScript arrays. Visiting a maliciously crafted website may lead to an unexpected application termination or arbitrary code execution. This issue is addressed through improved handling of JavaScript array indices.
Credit to Natalie Silvanovich for reporting this issue.

WebKit
Impact: Visiting a maliciously crafted website may lead to an unexpected application termination or arbitrary code execution
Description: A memory corruption issue exists in WebKit's handling of regular expressions. Visiting a maliciously crafted website may lead to an unexpected application termination or arbitrary code execution. This issue is addressed through improved handling of regular expressions.
Credit to Peter Varga of University of Szeged for reporting this issue.

WebKit
Impact: Visiting a maliciously crafted website may lead to an unexpected application termination or arbitrary code execution
Description: A use after free issue exists in WebKit's handling of "font-face" and "use" elements in SVG documents. Visiting a maliciously crafted website may lead to an unexpected application termination or arbitrary code execution. This issue is addressed through improved handling of "font-face" and "use" elements in SVG documents.
Credit to Aki Helin of OUSPG for reporting this issue.

Safari 5.0.1 and Safari 4.1.1 address the same set of security issues. Safari 5.0.1 is provided for Mac OS X v10.5, Mac OS X v10.6, and Windows systems. Safari 4.1.1 is provided for Mac OS X v10.4 systems

The thing to remember with the above vulnerabilities is that things that are labeled "Webkit", affect more than just Safari. They could possibly affect anything using the Webkit framework. Chrome included.

Microsoft opens source code to Russian secret service

Microsoft opens source code to Russian secret service | Security | ZDNet UK.

The above is a link to ZDNet on the fact that Microsoft has signed a deal with the Russian Federal Security Service (FSB) access to Windows Server 2008 R2, Office 2010, SQL Server, and Windows 7.

The thing to remember about this deal is, this is nothing new...  from the article:

"The agreement is an extension to a deal Microsoft struck with the Russian government in 2002 to share source code for Windows XP, Windows 2000 and Windows Server 2000, said Vedomosti."

I'm not even sure that the United States Government has access to Microsoft's Source Code, although it stands to reason... If the Russians have it, the US has it too.

PulledPork 0.4.2 501 error when downloading rules

Security - The Global Perspective: PulledPork 0.4.2 501 error when downloading rules.

JJ, buddy, and fellow Sourcefire pimp wrote this blog post about errors that people are getting when trying to run PulledPork and it's not working when downloading rules under the new format when using Ubuntu.

Go read his post.

Apple updates Anti-Malware file

Last year in August I wrote a post called "Snow Leopard is coming..." where I mentioned the XProtect.plist file.  This file protects and defends the OSX system against "downloader" trojans.  Ones that you receive via iChat, or download via Safari, Mail.. basically if you download the trojan to your system.

In the most recent update of Snow Leopard that came out last week (10.6.4), that I didn't cover, it seems Apple has updated the XProtect.plist file to include a new trojan named "HellRTS".

I guess this answers my original question, if they are going to keep it updated, am I am glad they are, however, I'd like to see them update it even more often than that, and of course include more things.  It's better than nothing, I suppose..  but I'd like to see more.

As of right now, there are a whole three trojans protected against in the XProtect file.

• OSX.RSPlug.A
• OSX.Iservice
• OSX.HellRTS

You can find this file in the:

/System/Library/CoreServices/CoreTypes.bundle/Contents/Resources/

directory.

This article by Sophos turned me onto the update, but I reposted without the conspiracy theories:

http://www.sophos.com/blogs/gc/g/2010/06/18/apple-secretly-updates

Safari 5.0 and Safari 4.1 patches

About the security content of Safari 5.0 and Safari 4.1.

Apple posted Safari 5.0 for 10.5.8 and 10.6, and Safari 4.1 for 10.4.11 yesterday and above is a link to the full patch list (and it's quite extensive)

The things patched in this update are below:

• ColorSync (Windows versions only)


• Phishing


• Handling of PDF files


• Arbitrary code execution (Windows only)


• Webkit (tons of updates here including the infamous wushi exploits from team509, also lots of mentions of Chris Evans and Mark Dowd.  Nice work guys.)

Check the full list at the above URL for complete details.