Thursday, July 30, 2009

Freakshow

We'll be attending the Freakshow on Saturday, come along and say hello.

You can also find us at the Microsoft Security Appreciation Reception tonight at Treasure Island. You can't get in without an invite though, so if you have one and you're going, come find us and say hi.

Tuesday, July 28, 2009

Microsoft Out of Band Patch - 28th July 2009

So, today, Microsoft released an out of band patch, two issue, one for Internet Explorer...

Microsoft Security Advisory (MS09-034):
Microsoft Internet Explorer contains programming errors that may allow a remote attacker to execute code on a vulnerable system.

Rules to detect attacks targeting these vulnerabilities are included in this release and are identified with GID 3, SIDs 15731 through 15733.

Advisory is here: http://www.snort.org/vrt/advisories/2009/07/28/vrt-rules-2009-07-28.html

Sourcefire 3D customers can get SEU 250 with these rules in it.

Monday, July 27, 2009

Only whitehat journalists need Metasploit to hack oracle

I'm astounded at the number of crazy articles concerning the release of Oracle exploits for PATCHED vulnerabilities. How is it that oracle in particular gets this kind of response, when Metasploit has been doing this with other vendors for years and years? Never mind the fact that I released a module for my oracle weblogic bug the day it was patched. Metasploit is useful in that it allows sysadmins to demonstrate to their bosses that they need time and money to patch by demonstrating concretely that they are vulnerable. This does NOT mean that if an exploit is not in metasploit that no one can own you. This is not rocket science.

From Olney:

In the end, this whole argument stems from one of the most egregious thought errors in the industry: The absence of PoC code, or worse, the lack of a public exploit, is justification for a delay in patching. Both Patrick and I have been confronted by managers saying "Prove to me this is exploitable" prior to allowing a patch to be applied. The sad truth is, there are more security slots in the world than there are people with the talent and background to PoC every patch Microsoft puts out. This thinking, often complicated by business drivers, also extends into software development. Last month's 0-day in Microsoft's MPEG2TuneRequest was CVE-2008-0015…how long were they aware of this bug before it was found by the bad guys? Why were customers placed at risk when the response in the end was simply to killbit the CLSID?


The fact is, there is always someone out there with more time, knowledge, background, contacts or just raw intelligence working on these issues. The problem is that they are working for the bad guys. While you are setting up the VPN to the new remote office, they are working on 0day. While you are checking firewall logs, they are working on 0-day. While you are writing policy documents on the use of USB memory devices, they are working on 0-day. Very few companies have the time, resources and talent to individually evaluate patches. Yet there are many who attempt to do just that.


In truth, the reaction to the release of the Oracle attack packages for Metasploit should have been a collective yawn. Here is why: for every new Oracle attack in Metasploit there is a patch from Oracle. If you're honestly concerned about this package, and aren't just being a self-serving media whore, then you've already made some very critical errors in your implementation and management of some high value targets. What you should do after reading this blog is go and patch your Oracle system, and every other system that you've declined to patch because it is "behind a firewall" or "there isn't a known attack for it". Because in all honesty, if there wasn't an attack available before the patch, you probably have less than 72 hours before someone out there has one put together. If you're lucky, it will be Carnal0wnage, and it will be in Metasploit for all to see. But most likely, it will be in China, Poland or maybe inside your company. Fact is, you just don't know.


Listen to the cat: The people who are stupid enough to require someone else to write their exploits for them are not the people you need to worry about. If you can't defend against them, you deserve to fail.

Friday, July 24, 2009

Adobe 0-day update

We love adobe. We love the u30. We love 32 bit values that are encoded as somewhere between 1 and 5 bytes. This is certainly a file format which has outlasted it's day in the sun. (56k modems)

Here Adobe mentions a CVE. Keep that in mind.

Yesterday, they locked a bug you might find interesting: (picture courtesy of Shirkdog)

One of the big problems with tracking the bug down is that if you change a value in the file, it no longer crashes. This isn't because you've found the triggering condition, but because if the flash is changed, Acroread gives up, and displays what it can, without any error message at all. The trick is not making the bad file not crash, but making a good file crash, and as you can see from the bug, this involves not a single issue, but multiple issues which can be hard to isolate.

Also, it seems like a few other people have caught on to the flash heap spray techniques after my tweet. The sample mentioned in a comment on the sans website as 0-day yesterday was actually a geticonv bug, which we quickly determined to be a different bug (since it didn't trip any of the breakpointed codepaths necessary to the flash bug), but still a live exploit of some kind. So yeah, we're only tracking a single bug at this point as live despite my big mouth. At the time we had two bad files, which exploited different vulnerabilities and I didn't take the bandwidth from bug one to eval bug two.

The patch I released on the 22nd was for the version of Acroread just before the current one (released on the 23rd), so it won't work on the latest one, but you should probably just delete authplay.dll until I can find a prettier way to disable javascript in a patch. It'll tank the program when it tries to load the missing dll, but that's just because some people don't check error codes, and it is not a vulnerable condition.

Wednesday, July 22, 2009

Rule release for today - July 22nd 2009

Adobe Acrobat and Reader Buffer Overflow:

Adobe Acrobat and Adobe Reader suffer from a programming error that may allow a remote attacker to execute code on an affected system. The problem occurs during the processing of a flash file embedded in a pdf document.

Rules to detect attacks targeting this vulnerability are included in this release and are identified with GID 1, SIDs 15727 through 15729.

Advisory is up here: http://www.snort.org/vrt/advisories/2009/07/22/vrt-rules-2009-07-22.html

Don’t read this post

So Lurene is mad at me, me being Matt W. The reason for this is the following conversation.

Me: Hey you guys see the US-CERT notice on ISC dhclient overflow?
Lurene: Yup, working on coverage right now for release today.
Lurene: You do know this vuln is awesome right?
Me: How so?
Lurene: Well its in every major linux/bsd/etc distro, and those guys patch process and auto-update tools suck. Everyone will be vulnerable for a long time.
Me: Ok, but its local network only. (Me checks my Ubuntu box for an update, not there yet, ...) (Me also checks my mac real quick, sweet doesn't run dhclient)
Lurene: Yeah, like hotel network, or conferences......
Me: Oh I get it, you want play with your toys at Defcon
Lurene: Your words not mine, but my exploits already works..... and with all the Windows Vulns and firefox vulns no one is writing about this one....
Me: (Quickly returns to desk patches vuln, by hand, rebuilds dhclient, checks logs)
Me: (While my inner evil really enjoys the idea of using this at defcon, I think it makes for a much better blog post, which is why Lurene, wrote the following blog post that I am now editing)


Lurene's Blog Post with Edits:
I really didn't want to write this blog entry. This whole bug seemed to go by without a whisper, and I was really hoping it'd stay that way. I feel like I'm taking away my own toys. The dhclient bug CVE-2009-0692 is classic stack based buffer overflow in a simple memcpy that allows for easily gaining code execution. Additionally, it affects a lot of different distro's and will probably take people a long time to patch it.

Here's a run down of the bug.

Vulnerable code was:
memcpy (netmask.iabuf, data.data, data.len);
netmask.len = data.len;

Patch was:
memcpy (netmask.iabuf, data.data, 4);

Seriously. That's it. Large subnet option in a DHCP ACK packet. Netmask.iabuf is on the stack.

Living in front of it on the way to ret are a few pointers and structs:
int i;
struct data_string data;
struct option_cache *oc;
struct envadd_state es;

You can ignore es I think, set *oc to a readable location, then you get to mess with data. That's cool because AFTER it copies the netmask (AFTER!) it checks the length to see if data.len value is the same as the size of the IP address. As you're walking up the stack, just whack that size with 4 and roll on along to RET. Done deal. There are a couple other places you need to put in a readable address, but that's easy.

Now all the linux box on the network segment belong to you. Now you just need to have it rerun dhclient to get an IP and send you back a shell, or hotpatch the process, set the stack up to return to your callback shell, then ret back to main. Tada.

(Ed note: If you haven't already patched your laptops, VM images, servers, etc you should especially if you run this on your laptop and are going to defcon or any fun conference. Since the airport has WiFi, SouthWest has WiFi on the plane, the conference has WiFi, and so do people with heavy backpacks..... )

Also if you're running the VRT rules this vulnerability is already covered GID 3 SID 15700

Tuesday, July 21, 2009

Rule release for today - July 21st 2009

A few new rules and some modifications to improve rule performance in today's release.

Apple iTunes Buffer Overflow (CVE-2009-0950):
Apple iTunes contains a programming error that may allow a remote attacker to execute code on a vulnerable system.

Rules to detect attacks targeting this vulnerability are included in this release and are identified with GID 1, SIDs 15703 through 15707.

Unisys Business Information Server Buffer Overflow (CVE-2009-1628):
The Unisys Business Information Server contains a programming error that may allow a remote attacker to execute code on an affected system.

A rule to detect attacks targeting this vulnerability is included in this release and is identified with GID 1, SID 15708.

As a result of ongoing research the Sourcefire VRT has added multiple rules to the SCADA, Oracle, specific-threats, chat, web-client and exploit rule sets to provide coverage for emerging threats from these technologies.

Advisory is located here: http://www.snort.org/vrt/advisories/2009/07/21/vrt-rules-2009-07-21.html

Friday, July 17, 2009

Vulnerability Report July 2009



This is a Beta version of our Vulnerability Report. We haven't done this, or anything like it before and we got it together pretty quickly. We're learning as we go. We would really appreciate some thoughts, tips and suggestions on it.

How do I become a Ninja?

Earlier this week, we posted this blog item: Ask the VRT a question. We had a few people write in and ask us questions about Snort, Snort rules and the other obvious Snort related questions. Then, we got something interesting...

mish asks "How do I become a Ninja?"

(His question was a little longer than that, and we of course assumed that he meant "Vulnerability Research Ninja")

We threw this around between various VRT people and it apparently hit the hot button on our Senior Director of Vulnerability Research, Matt Watchinski. Here is his manifesto in reply to mish's question:

1. You need to fix your thought process. Most people see computers and programs as tools that have functions that complete the tasks they need accomplished on a day to day basis. If you see everything around you as something that needs to work to do your job then you'll never see it for what it is, something to break and use to your advantage. The best way I've heard this summed up is "Be Evil".

2. Reading books without ever turning that information into practical knowledge is not going to make a ninja. Only experience will make a ninja, sitting in a library never resulted in anything useful.

Once you have the thought process down, technical skills now come into play.

3. The main thing with technical skills is you don't need to be a master of any of them, you need to be a master of recalling where the information you need is located.

4. Get yourself an old ass RedHat box without PAX/AppArmor/etc make sure stack randomization is off, then go download all the ABO's from Gera. Start working on the simple buffer overflow examples. All the answers are on google if you get stuck (but don't cheat, it's not worth it).

5. After that, you now hate GDB. Time to move on to a real debugger. Get yourself a Windows XP box (no service pack), or a Windows 2000 box with any service pack (VMWare is great, just saying). Start working through the AWBO examples that we have on our blog. These will get you all the way up to SEH exploitation on Windows. (shameless plug about our Fundamentals of Exploit Development class should go in here, and here it is Fundamentals of Exploit Development (pdf))

After completing those, you are by no means a master at exploiting things, but all the basics should now be in place. Additionally, you've probably now read every paper on overflows that can be found by google to help you finish all the above examples. You are also now familiar with WinDBG, OllyDBG, or ImmunityDebugger (WinDBG is better), and are unfortunately familiar with GDB, the worst debugger on the planet.

6. Now its time to try some code auditing. The easiest way to do this is with known vulnerabilities. The best example of this type of work is here http://xorl.wordpress.com/. Start doing exactly what this guy is doing. Also its now time to download the C99 standard, and actually read it. Also since it takes a bit to get, order the Intel OPCode manuals, these are free.

After auditing a couple of hundred programs you'll be relatively familiar with patterns in C and other languages which result in coding mistakes that you can now use to your advantage. It's really all about patterns at this stage, since real software packages are huge, being able to quickly find patterns that might be bad is important, as it lets you skip lots of code and only focus on what is interesting.

7. Now it's time to start using and playing with a couple of other tools. Fuzzers, the best place to start in my opinion is with something like FileFuzz from iDefense. Also check out Sully or Peach. Get a bunch of VM's up and running with different programs and let these things in go in the background, while you learn other things. Eventually, you'll hate these tools so much you'll get that idea that you can write a better one, go with that feeling and start writing a simple filefuzzer. Just learn to hate Sully or Peach and be ok with it, as rewriting one of these takes a long time, and you'll forget a bunch of stuff along the way. However, you might come to like python in the process, not sure if thats a good thing or a bad thing.

8. Hopefully at this point, you've got a couple crashes from your fuzzers. This is where being a master of nothing, but recalling information comes in very handy. Time to start reading RFC's, protocol docs, fileformat docs, or whatever is relevant to the crash you have. It is now time to buy IDA Pro. Work on developing a reliable test case for your crash, so you understand exactly what is happening. This is an art, and isn't something that can be reliably taught, as debugging binary only applications requires tons of trial and error for determining if something is exploitable or not in a lot of situations.

At this point you'll be a borderline alcoholic, from banging your head on some problem you just can't figure out and turning to the bottle in an attempt to dull the pain. It's now time to get a support network, not for the alcoholism, but for your other problem. Alcoholism is fine (not really), if you get really good at this you'll need this to get though your day, when you realize that every tool and software app you run contains massive amounts of vulnerabilities that can be used to own your box. Also if you've written a number of tools in the above process you will now find vulnerabilities in them, because most "in training" ninja's are crappy coders. (Sometimes real ninjas are still crappy coders) (Ed note: actually boss, they all are)

9. Once you get your first actual working 0-day, you will now need to invent a root dance. This is important, as it will used in the future when you find more to signify to your friends that you have a new 0-day. Comes in very handy at a Defcon, as long as you're not playing vulnerability poker, as it will tip your hand. While this seems silly, its very important, since you are now an alcoholic, you need to be able to quickly celebrate your accomplishments, without dulling your senses.

10. Now you essentially have a choice. You have a skill that is worth money, you can strike out on your own and start selling your vulnerabilities, or you can now impress some employer with a portfolio of disclosed vulnerabilities. If you're used to a professional services life, then striking out on your own may be the way to go. However, it does have its ups and downs, just like any consulting job. But this isn't a business lesson, its a "how to be a ninja" manifesto.

11. If you go the job route, it's now possible to specialize. This will really open your mind as you will have to invent new tools and techniques if you pick a realm that has little to no public information. Let's take vxWorks applications as an example. Nothing useful about reversing vxWorks exists on the InterTubes. Sorry, Matasano your singular blog post on the subject doesn't count, and mine probably violates something in the DMCA, so I can't post it.

Now that you've read all of the above I'm going to assume something in the back of your mind says "You didn't answer my question, I asked for specific steps, books, and articles to help me out." Well, unfortunately nothing you will read will ever make you what you want to be, its all about cold hard practical experience. You won't see it unless you go do it, as each adventure will open up new paths to information and ideas that didn't seem relevant until you needed them. Finally, you need to love the quest, and it needs to consume you. If walk into a restaurant and see a computer with a menu on it and your first thought isn't to touch all the buttons and see if it breaks, then you don't love the quest.

If you have a question you would like to be answered, feel free to send us an email (research at sourcefire dot com) with the subject line "Ask the VRT" or post a comment on this blog post Ask the VRT a question.

Thursday, July 16, 2009

Rule release for today - July 16th 2009

For those of you following our twitter feed, you now know why we were laughing last night...

ISC DHCLIENT Buffer Overflow (CVE-2009-0692):
The ISC DHCLIENT daemon suffers from a programming error that may allow a remote attacker to capitalize on a stack overflow and execute code on an affected machine.

A rule to detect attacks targeting this vulnerability is included in this release and is identified with GID 3, SID 15700.

Advisory is here: http://www.snort.org/vrt/advisories/2009/07/16/vrt-rules-2009-07-16.html

Wednesday, July 15, 2009

Rule release for today - July 15th 2009

Couple of Mozilla Firefox issues that need to be addressed...

Mozilla Firefox Remote Code Execution:
Mozilla Firefox contains a programming error that may allow a remote attacker to execute code on an affected system. A failed attempt will cause a Denial of Service against the application. The problem occurs in the Tracemonkey JavaScript engine.

A rule to detect attacks targeting this vulnerability is included in this release and is identified with GID 1, SID 15696.

Mozilla Firefox Stack Overflow:
Mozilla Firefox contains a programming error that may allow a remote attacker to execute code on an affected system. The problem occurs when Firefox fails to correctly handle Unicode data.

A rule to detect attacks targeting this vulnerability is included in this release and is identified with GID 1, SID 15699.

Details available here: http://www.snort.org/vrt/advisories/2009/07/15/vrt-rules-2009-07-15.html

Tuesday, July 14, 2009

Why I'd Dress LIke a Cheerleader

Twitter, the Internet’s biggest game of telephone, occasionally yields some interesting material. Yesterday, as an example, Lurene got a tweet that someone was upset about the Saphead’s write up of their work in this year’s DefCon CTF qualifier. The imagery they used to convey their message had a definite sexist overtone, with the only female member of their cartoon team labeled as the “cheerleader” and basically asking a bunch of silly questions in what I would call the “I’m just a girl” tone.

In what is, unfortunately for the edgier side of security, a fairly rare show of class, the Sapheads have apologized and are reworking their (very informative) comic to put the character in a better light. (See here: http://hackerschool.org/DefconCTF/17/B300.html) But the incident got me thinking about how rare superstars are in the world, how lucky a business is to have one walk in their door every day and how crazy one would be to ignore someone based on their race, sexual preference or any other marker not associate with their talent.

The VRT is stacked to the gills with people who fit into a group or, more likely, groups that might be described as “those people” by some members of society. We have men and women, we have people from four different continents, speak multiple languages and in general each of us brings a vastly different background to the table. And that is why every day I hop up, eager to get to work to find out what this menagerie of human talent will cook up.

The reason the comic really caught my eye though, is that some of the most dangerous talent we have here at Sourcefire has the double-X chromosome setup. In fact, when every Macintosh on the Sourcefire network simultaneously rebooted it was Judy who had handcrafted the IPv6 packet that corrupted the network stack. When the Vulnerability Research Team member stepped off the plane in Washington state to talk to a major software development company about how attackers reverse engineer patches into exploits it was Lurene. And it is Sojeong (call me Monica) that has been dropping 0-day non-stop since she has walked in the door of Sourcefire.

The people I work with every day are scary-smart. Your company would kill to have their brains working on your security problems. But the sad fact is that there are people out there that would immediately discount Mr. Zidouemba’s contributions simply based on the color of his skin. Of course, they would never say so to him directly, that would be wrong. But he might not get the opportunities, the slack or the resources that would allow him to truly shine.

In this day and age, I can’t imagine how some management feels that it can compete by only pulling from a pool of people that look, talk and think like them. If you or people in your company feel that women should dress in white, like all other domestic appliances, or that intelligence is somehow related to skin pigment, then your company is in peril. True superstars, with the right mix of talent, drive and business savvy are far too rare to waste over discrimination. We’ll happily take any superstars that attitude drives off; because at Sourcefire, they’ve recognized that it’s worth the effort to work through the accent to get to the genius.

TL;DR: I’ll field an All-Women’s Sourcefire hacker team against any group in the industry and happily sit back in the cheerleader outfit and watch.

P.S. Don’t tell anyone on the team I’ve been saying nice things about them, they’ll think I’ve gone all soft.

Rule release for today - July 14th 2009

A number of issues for Microsoft products this month, here are some selections...

Microsoft Security Advisory (MS09-028):
Microsoft DirectShow contains programming errors that may allow a remote attacker to execute code on an affected system.

Rules to detect attacks targeting these vulnerabilities are included in this release and are identified with GID 3, SIDs 15680 and 15682.

Microsoft Security Advisory (MS09-029):
The Microsoft Open Type Font implementation contains programming errors that may allow a remote attacker to execute code on an affected system.

Rules to detect attacks targeting this vulnerability are included in this release and are identified with GID 3, SIDs 15530, 15532 and 15533.

Microsoft Security Advisory (MS09-030):
Microsoft Publisher contains a programming error that may allow a remote attacker to execute code on an affected system.

A rule to detect attacks targeting this vulnerability is included in this release and is identified with GID 3, SID 15681.

Microsoft Security Advisory (MS09-031):
The Microsoft ISA server contains a programming error that may allow a remote attacker to gain unauthorized access to an affected system.

A rule to detect attacks targeting this vulnerability is included in this release and is identified with GID 3, SID 15683.

Microsoft Security Advisory (MS09-032):
The Microsoft Video ActiveX control contains a vulnerability that may allow a remote attacker to execute code on a vulnerable system. The attacker may take advantage of the vulnerability via a call to the ActiveX control from Internet Explorer. This vulnerability requires no user interaction and is being actively exploited.

Previously released rules to detect attacks targeting this vulnerability are included in this release with updated references, and are identified with GID 1, SIDs 15588 through 15677.

Advisory is available here: http://www.snort.org/vrt/advisories/2009/07/14/vrt-rules-2009-07-14.html

Monday, July 13, 2009

Sourcefire VRT firebreathing pig

Here's our video of the firebreathing pig. We made this in December of 2007. Now that we have a good camera, maybe we should reshoot the video.

Ask the VRT a question

We are extending the opportunity for you, the reader, to ask us questions. We will select the best question(s) each week and publish them, along with the answers we give, here.

"What kind of questions can I ask?"

Well, thanks for asking, you can ask us anything. It can be Snort related, Snort rule related, vulnerability related, exploit related, you can seek advice on dating or what to do with your annoying co-worker should you desire. We are open to all kinds of queries. When we don't have an opinion, we'll get one.

"Ok, so how do I ask a question?"

To ask your question, send us an email to research at sourcefire dot com with "Ask the VRT" as the subject, alternatively ask your question as a comment to this blog post.

"When will I get my answer?"

That depends. If we select your question, we will most likely publish the answer on the following Friday (or thereabouts), we might need some time to formulate an answer, then again, we might not.

"What if I don't like the answer?"

You don't have to like it, but at least you got one, right?

"Can I really ask anything at all?"

Yes. Really.

Friday, July 10, 2009

Following us at tumblr

We now have an additional feed of our blog, our twittering and our upcoming video channel all rolled into one at tumblr. Check it out at http://vrt-sourcefire.tumblr.com/.

We aren't going to publish other content at that blog that doesn't appear here, rather it is meant as a place where everything is consolidated for those folks who like one stop shopping.

Wednesday, July 8, 2009

Rule Performance Part One: Content Matches

One of the many things that occupy the time of the VRT is reviewing rule performance data, whether that data is internally generated from one of our test environments or received from customer reports. In the “Rule Performance” series of blog posts, we’ll look at the set of issues that encompass the problematic rule constructs that we’ve found most significantly impact the performance of Snort sensors. Hopefully you can use this information to add additional detection capability customized to your environment without adding undue processing load.

The first and perhaps most important common error is a lack of a long, unique content match. As discussed in the “Writing Effective Rules, Part 1” webcast (http://www.sourcefire.com/resources/snort-webcast-access?sfext=snorthome1) Snort takes the first, longest content match in a rule, and places it in the appropriate fast-pattern matcher. Here is an example of how it works:
alert tcp $EXTERNAL_NET $HTTP_PORTS -> $HOME_NET any (msg:"WEB-CLIENT VML fill method overflow attempt";
flow:from_server,established; content:"|3A|fill"; nocase;
pcre:"/<\w+\x3afill\s[^>]*method\s*=\s*(\x27[^\x27]{32}|\x22[^\x22]{32}|[^\s>]{32})/smi";
metadata:policy balanced-ips drop, policy connectivity-ips drop, policy security-ips drop;
reference:bugtraq,20096; reference:cve,2006-4868;
reference:url,www.microsoft.com/technet/security/bulletin/ms06-055.mspx;
classtype:attempted-user; sid:8416; rev:5;)

This rule detects a 2006 vulnerability in Microsoft’s Vector Graphics Rendering engine. Notice that there is a content match for “|3A|fill”, but that string also appears in the PCRE that carries the actual detection methodology. The reason for this is to support the fast-pattern matcher and to reduce entry into the PCRE engine. When Snort loads, it will place the content “|3A|fill” into the fast pattern tree that runs on the TCP ports that in HTTP_PORTS. What this means is that only packets on one of the HTTP_PORTS that contain the pattern “|3A|fill” will enter into the rule chain to evaluate SID:8416. If the packet doesn’t contain this content, and thus can never alert, it will never evaluate against the rule.

Once the fast pattern matcher passes the packet to the detection engine, which executes the rule detection in the order the rule is written. So, after ensuring that the packet is part of an established stream, and that data is being passed to the client, the detection engine checks for “|3A|fill” (regardless of case), and then enters into the PCRE detection.

If we didn’t have the content match, what would happen? With no content match in the pattern engine, the rule would fall into an all-packet buffer where every packet that was on the HTTP_PORTS set would be evaluated against it. Without the content match to ensure that the packet had to have the “|3A|fill” pattern, every packet on the HTTP_PORTS set that was part of an established session would enter the PCRE detection engine. The PCRE engine is very useful, but we don’t want to pay the penalty of its use without ensuring we have a chance to detect.

One recent addition to Snort was the “fast_pattern” keyword. By default, the fast pattern matcher would use the first, longest content match in a rule. But sometimes that isn’t the most useful match. Consider the following fictional rule:
alert tcp $HOME_NET 300 -> $EXTERNAL_NET (msg:”SPECIFIC-THREAT Oh noes”;
flow: to_client, established;
content:”|00 00 00 00 00 00 00 00|”; content:”BISCUIT”; sid: 5;)

Because 8 nulls is longer than the phrase “BISCUIT!”, the Snort engine would take the NULLs and place them into the fast pattern matcher. But anyone who has done a stint as an analyst knows that a string of NULLs is not an uncommon occurrence in network traffic, and that “BISCUIT” is much more unique. We will enter this rules detection less often by forcing Snort to use the more unique of the content matches as the fast pattern entry:
alert tcp $HOME_NET 300 -> $EXTERNAL_NET (msg:”SPECIFIC-THREAT Oh noes”;
flow: to_client, established;
content:”|00 00 00 00 00 00 00 00|”; content:”BISCUIT”; fast_pattern; sid: 5;)

So, the lowly, basic content match has an enormous impact on the performance of a rule. When building custom detection for your environment, remember:

  1. Use a long, unique content match to ensure that your rule is only triggered when there is a chance it will fire.

  2. If you find a smaller content match that you feel is more unique and will cause the rule detection to be called less frequently, use the fast_pattern keyword to force that content match to be used in the fast pattern matcher.

  3. Ensure that you order your rule options so that faster operations are at the beginning. We’ll cover this more next time, but in general, run your content matches prior to your PCREs.


Hope that helps! If you have questions, leave a comment, and we’ll get back to you!

Tuesday, July 7, 2009

Microsoft Video ActiveX Control rule coverage

So, a bit of a problem with an ActiveX control that can be leveraged via a webpage, without any user interaction required. Who would've expected that?

Microsoft Security Advisory (972890):
The Microsoft Video ActiveX control contains a vulnerability that may allow a remote attacker to execute code on a vulnerable system. The attacker may take advantage of the vulnerability via a call to the ActiveX control from Internet Explorer. This vulnerability requires no user interaction and is being actively exploited.

Rules to detect attacks targeting this vulnerability are included in this release and are identified with GID 1, SIDs 15588 through 15677.

Detailed changelogs can be found here: http://www.snort.org/vrt/advisories/2009/07/07/vrt-rules-2009-07-07.html/

Wednesday, July 1, 2009

Rule release for today - July 1st 2009

Remember this post? http://vrt-sourcefire.blogspot.com/2009/04/rule-release-for-today-april-8th-2009.html

Well, we've continued the work on modifying netbios rules to take advantage of the new dcerpc preprocessor and changed a bunch of the shared object rules. Here's a mapping of modified and replaced rules:
Replacement Rule(s) (GID 3)Replaced Shared Object Rules (GID 3)
14725, 1472614727, 14728, 14729, 14730, 14731, 14732, 14733, 14734,14735, 14736
1466114662, 14663, 14664, 14665, 14666, 14667, 14668, 14669, 14670, 14671, 14672, 14673, 14674, 14675, 14676, 14677, 14678, 14679, 14680, 14681, 14682, 14683, 14684, 14685, 14686, 14687, 14688, 14689, 14690, 14691, 14692, 14693, 14694, 14695, 14696, 14697, 14698, 14699, 14700, 14701, 14702, 14703, 14704, 14705, 14706, 14707, 14708
1473714738, 14739, 14740
14782, 1478314784, 14785, 14786, 14787, 14788, 14789, 14790, 14791, 14792, 14793, 14794, 14795, 14796, 14797, 14798, 14799, 14800, 14801, 14802, 14803, 14804, 14805, 14806, 14807, 14808, 14809, 14810, 14811, 14812, 14813, 14814, 14815, 14816, 14817, 14818, 14819, 14820, 14821, 14822, 14823, 14824, 14825, 14826, 14827, 14828, 14829, 14830, 14831, 14832, 14833, 14834, 14835, 14836, 14837, 14838, 14839, 14840, 14841, 14842, 14843, 14844, 14845, 14846, 14847, 14848, 14849, 14850, 14851, 14852, 14853, 14854, 14855, 14856, 14857, 14858, 14859, 14860, 14861, 14862, 14863, 14864, 14865, 14866, 14867, 14868, 14869, 14870, 14871, 14872, 14873, 14874, 14875, 14876, 14877, 14878, 14879, 14880, 14881, 14882, 14883, 14884, 14885, 14886, 14887, 14888, 14889, 14890, 14891, 14892, 14893, 14894, 14895
1501515016, 15017, 15018, 15019, 15020, 15021, 15022, 15023, 15024, 15025, 15026, 15027, 15028, 15029, 15030, 15031, 15032, 15033, 15034, 15035, 15036, 15037, 15038, 15039, 15040, 15041, 15042, 15043, 15044, 15045, 15046, 15047, 15048, 15049, 15050, 15051, 15052, 15053, 15054, 15055, 15056, 15057, 15058, 15059, 15060, 15061, 15062, 15063, 15064, 15065, 15066, 15067, 15068


As always, you can find details here: http://www.snort.org/vrt/advisories/2009/07/01/vrt-rules-2009-07-01.html/