Thursday, July 22, 2010

Sourcefire VRT DI is Hiring

Here's your chance to become part of the Intelligence unit that powers the Vulnerability Research Team. We know all, we see all and we say almost nothing to anyone about anything. Kinda. Alright, not really. We get the data, we manage the data, we mine the data, we give out information and actionable intelligence. In short, we separate the intel from the noise.

You may have seen our previous post regarding our expansion plans. This position is part of that grand scheme. As such, the following 10 things from the previous post still apply. If they appeal to you and describe the qualities you want in your co-workers and your workplace, then the VRT is interested in talking with you. Please submit your resume on Sourcefire's website or send us a message at

Submit Resume here

Passion (for the work) - Very few people are trained academically for vulnerability analysis, malware analysis, network engineering, or hacking. It is something that is learned by experience and experimentation. If you have dedicated your free time and lost countless days and nights perfecting some portion of it then you have the passion I'm talking about.

Good people - If you enjoy an environment where everyone around you is better than you at something and is willing to teach you their skill in exchange for your own, then the VRT might be the right place for you.

Goals - Clear definitions of strategic goals to the best of my ability and my managers' abilities. If we can't clearly explain the "why" then we won't ask you to waste your time on it.

Belief - A group of people that share an intrinsic belief that it is possible to accomplish difficult, if not "currently" impossible, goals. More importantly, this belief is present not because of arrogance, but because of our experience proving that we actually can accomplish these goals.

Drive - A personal drive that exceeds the average. If you've worked on a problem for many months, still haven't solved it, but truly believe you will shortly, you are either hard headed or have a lot of drive. Whether you're pushing yourself by hitting your head on a wall, or just plain never giving up, you will most likely create a positive outcome.

Latitude - If you hate rules but understand personal responsibility, this might be the environment for you. You'll get just enough rope to hang yourself, as long as you take responsibility for your own demise.

Trust - An environment were you can trust the people you work with to actually do what they say, do it to the best of their ability, and trust you to do the same.

Responsibility - For your actions and your words. If you broke it, you fix it. If you said you would do it, do it.

Risk - An environment where you are allowed to take risks in the pursuit of goals. Risk is the potential to fail and without failure there is no opportunity to learn. You will be able to take risks as long as you sign up for the responsibility of failing.

Leadership - You expect the people above you to actually lead, and trust them enough to actually follow them.

If these ten things fit your personality, and describe the place you want to work, please see the job description below. When submitting your resume please include either a comment or something in your actual resume that references the fact that you read this post.

Title: Research Systems Engineer

Basic Purpose

This role is primarily responsible for developing database applications, supporting the Vulnerability Database that is part of Sourcefire RNA, research to support current detection systems, research into new detection systems and methods, research into data mining and internal tool development.

Essential Duties and Responsibilities
  • Administration of various backend systems.
  • Support Vulnerability database building and administration
  • Conduct research into new detection mechanisms
  • Conduct research into existing detection mechanisms and improve them
  • Script like a maniac
  • Develop cool tools
Essential Education, Skill, and Environment Education and Work Experience
  • Experience is probably your biggest asset
  • Bachelors degree (or higher) will at least show us you can achieve a long term goal
  • Ability to apply Ohms law under duress is an advantage
  • Must believe that Leibniz stole Newton's ideas for Calculus
  • The desire to gain knowledge is key
  • Experience designing user interfaces for web, scripts, cli etc. is a plus
Required Knowledge and Skills
  • Experience with SQL databases, MySQL, PostGRES etc.
  • Experience designing SQL databse schemas
  • Experience configuring Windows and Linux/UNIX applications
  • Strong analytical and troubleshooting skills
  • Experience with TCP/IP, IPv6 and IPv4 networking in general
  • Be able to script in PERL, Python, and/or Ruby
  • Ability to learn new skills and apply them in a rapidly changing, high-pressure environment
  • Can solve complex technical problems in a non-Rube Goldberg fashion
  • Desire to perform research activities, stretch some boundaries, kick down doors, take names and conquer
Preferred Knowledge and Skills
  • Highly motivated and creative
  • Experience with Snort & other network security tools
  • Experience with network configuration and deployment
  • Experience with PCRE or equivalent regular expression library
Work Conditions
  • Moderate to high levels of stress will occur at times
  • Fast paced and rapidly changing environment
  • Extremely talented and experienced team members and mentors
  • No special physical requirements
  • Constant internal training, drinking games, and heated discussions

Rule Release for Today, Thursday July 22nd, 2010

Two main vulnerabilities covered in this release. Microsoft Windows Shell shortcut vulnerability (CVE-2010-2568) and the Siemens Simatic WinCC and PCS 7 SCADA vuln (CVE-2010-2772). Both of these are being actively used by the Stuxnet worm.

More details are available here:

Tuesday, July 20, 2010

Innovation -- You Keep Using That Word...

So, this week, the OISF has been on a media blitz about Suricata, their open-source Intrusion Detection System.  As always, my preference is for you to review the information yourself, so before I give you my thoughts about the state of Suricata, here are some links:

When I talked to Matt Jonkman about Suricata this past December, I was excited.  He talks a good game and his pitch of Suricata as a "Next Generation Intrusion Detection and Prevention Engine" was catching.  It is always good to step outside the box and take a good hard look at how any industry is approaching things and innovation is always welcome.  The fact that Suricata is Open Source and driven by government money meant that the innovation would be available and easily ported to Snort, helping not just Suricata users, but Snort users as well.  To me, it looked win-win all the way.

I was so impressed by the tack that Suricata appeared to be taking that I gave my best wishes to them on their first release, back in December:
"Congrats to Matt Jonkman and the team at OISF.  It's a big step, and I look forward to seeing your work (after then new year :))

Matt". -- [Snort-users] Suricata IDS Available for Download!, 12/31/09

But at this point, having worked with Suricata and looked at what the OISF has actually delivered, I'm just disappointed with where they've ended up and what they've delivered.

Suricata's developers harp on a lot of different issues, some of which are valid, and some are simply wrong.  More than anything else, they beat the multi-threaded drum:

".For example, Suricata's multi-threaded architecture can support high performance multi-core and multiprocesser systems, Jonkman said." -- (Computerworld, above)

 "This is 2010 and not a single IDS supports multi-threading"
"The flaw in every IDS is that it is single threaded"
"Multi threading alone is worth moving over to Suricata for".
-- (Suricata team, various)

We've talked about this before, with an extensive, technical discussion on multi-threading and IDS from Marty (  Go there and check out what Marty has to say.  The essence of his post is that there are sound architecture reasons why traditional multi-threading is not the appropriate approach for IDS implementations.  Certainly, as commodity hardware evolves (we do work very closely with Intel), we'll continue to evaluate the technology.  In addition to the long technical brief, I'd point out this simple fact of life:  IDS vendors are judged on both detection accuracy and speed.  No report about an IDS engine comes out that doesn't identify how many GB/s throughput the engine was capable of sustaining.  Trust me, if multi-threading were the answer, the industry would have moved there in short order.

Of course, there is no third-party review of Suricata's performance.  I'm going to give you some numbers, but I don't expect you to put any special weight on them, they are more to show that we have looked at the engine and haven't found anything that we would take from it.  I asked Chris McBee, one of the researchers here on the VRT to install Snort and Suricata on the same box.  I told him to make it run, take all the steps necessary to maximize performance.  He even changed out the network card to support the pf_ring buffer.  We did not, however install a CUDA-capable network video card (edited after publish, my bad -- molney), since, in the words of one Suricata developer (it should be noted that the 1.0.0 release notes indicated an increase in performance):

"Currently on my desktop CUDA actually slows things down"

So the key to the test is that they were on the same, commodity hardware.  We ran Snort first, then Suricata on the same box.  In each test, Snort and Suricata were loaded with the latest default open source ruleset from the VRT.  In the case of Suricata, some rules that used unsupported options failed to load, and there is no .SO rule support, so none of those rules ran either.  This means that Snort was running a larger ruleset than Suricata.

Test Set 1:  The same packet set sent at between 200 and 5200 MB/s (30 runs total)
       Total Packets sent:  30,000,000 (Across all 30 tests)
       Total Packets dropped, Snort:  61264  (0.0204%)
       Total Packets dropped, Suricata:  17,438,542 (58%)

Test Set 2: The same packet set sent at between 200 and 5200 MB/s (30 runs total) (Hyperthreading Disabled)
       Total Packets sent:  30,000,000 (Across all 30 tests)
       Total Packets dropped, Snort: 511 (0.0017%)
       Total Packets dropped, Suricata: 15,714,211 (52%)

Now, we did rerun the tests when Suricata 1.0 was released, briefly:

"Suricata peaked at about 300 Mb/s without dropping packets, provided no rules are loaded.
With rules loaded, Suricata runs up to about 200Mb/s.
Snort, with rules, hits 894Mb/s with no drops" -- Internal VRT Report on Suricata Performance

Suricata's performance isn't just bad; it's hideously, unforgivably bad.  This is especially true for a project that is hawking the performance issue.  There are other issues I have with Suricata, but I think the one that is most concerning is the following statement:

"We made a conscious decision last year that we're not going to go with an obfuscated rule set, we're not going to pick up an SO rule format" -- Matt Jonkman

This decision is going to limit any detection capability to the rule language provided by Suricata.  In today's incredibly complex environment, this is an unacceptable limitation.  Sourcefire developed the C capability to give the VRT and high-end response organizations the ability to build detection with all of the power of C available to them and not lock them into our the Snort rules language.  The loss of this capability dramatically reduces the usefulness of Suricata.  As an administrative issue, for organizations working in a TS/SCI environment, rules often need to be provided in an obfuscated format to protect against unnecessary disclosure of data.  This isn't available without .so rules.

All of this came up in a discussion of how to engage vendors to get data to write rules.  It should be noted that Sourcefire is a partner with several large vendors, including the most targeted:  Microsoft.  In agreement with these vendors, we protect our rule set for vulnerabilities that are not being exploited in the wild to help protect against exploit development.  We do this by obfuscating the rules associated with data we receive from them into .so rules.  There is no impact to performance by doing this, but it does pose a hurdle to potential attackers looking to glean information about potential vulnerabilities from how we go about detecting them.

Matt Jonkman specifically said: "We're hoping to get enough market share to say to vendors if they want to use our product if they want to feel safe, we're going to have to be transparent enough that rules can be written".  This is simply not going to happen, and trying to adjust reality to justify your philosophical approach will simply result in a product that is not usable.

Look, I generally work very hard to avoid looking like a corporate shill, I try to keep to purely technical information.  But in this case, I have to call a spade a spade, even if it leaves you thinking I'm just a mouth piece.  But know that I honestly believe this:

The OISF has spent nearly a million dollars to fulfill their obligation to the DHS to deliver the next generation in IDS engines.  They have since engaged in all manner of wishful thinking, self-aggrandizement and Snort bashing.  They've failed, utterly, to deliver on their promises.  This is forgivable on the performance front, that problem is non-trivial.  But in the end, what they've built is a poorly functioning Snort-clone, missing the most powerful detection capability that Snort has.  There isn't anything in the way of innovation; they are taking the same approach as everyone else from a detection standpoint.  Simply put, rehashing isn't innovation.

If you want to see what innovation looks like, come to Vegas and let the VRT show you the Razorback system.  It isn't Snort, it isn't ClamAV, and it isn't Suricata.  It's a new approach to the detection problem, and was built from the ground up in close collaboration with groups that are facing APT-level threats.  It may not be perfect, it may not even be the right answer (but we think it is), but it is truly innovative.  

And we didn't even cost you a million dollars.

Monday, July 19, 2010

The Power of Scapy

There is a special place in my heart for someone who accidentally causes all the Macs in the office to repeatably crash at the Grey Screen of Death. If you too like fun "accidents" or need to craft up some packets check out Judy Novak's SANS class on Scapy. This is an in-depth start to finish class on the Scapy API, and will take you from just knowing about Scapy to building complex packet crafting scripts for all your testing, verification, and hacking needs.

If you ever needed to:
1. Test your Snort rules with real traffic
2. Verify your packet munging devices actually support your special protocol needs
3. Need to build a PoC for that new NAT vulnerability
4. Pen-test the robustness of that new communication channel

Then this class is for you. Next class is in Las Vegas on September 19th.

Check it out here:

Wednesday, July 14, 2010

New Rule Categories

Three new rule categories were introduced yesterday (Tuesday, 13th July 2010) in SEU 348 and into the VRT Certified Rule packages. I'd like to take a moment to explain what's in these categories, where the data behind them is coming from, and what you should do if you turn them on and they start firing.

The initial set of rules for these categories was pulled from the specific-threats and spyware-put categories, as these categories already contained numerous botnet command and control, and dns based detection rules. We felt that by breaking these categories out it was easier to find the rules end users were looking for, and that doing this gives people a simpler way to enable a whole type of detection in a single unified category. These categories are augmented by our automated malware analysis systems, spam traps, honeynets, and additional external data feeds. We'll be putting out some additional information about how these systems works and what type of data they capture; we'll also be publishing some raw data lists. Anyone will be able to get the raw lists, which contain IP addresses, URLs, and DNS names that were collected from these systems so you can use this data in other security or security releated tools, like SMTP RBLS, or DNS Blockhole systems.

  • botnet-cnc.rules: A large portion of the world's malware connects the infected machine into a botnet, to serve at the whim of whomever unleashed the initial infection; this software uses command and control channels to communicate with master servers and take instructions on what to do next. These rules are aimed at detecting communication over those channels, by looking for portions of URLs that remain constant across domains used by control servers, chunks of the communications channels themselves, or other criteria that have been observed repeatedly across a broad range of related pieces of malware. A number of rules in this category were previously listed in the Specific-Threats category and in the Spyware-Put category, since these rules focused specifically on command and control traffic they have been moved here.
  • blocklist.rules: These rules look for DNS queries for known-malicious domains and common URL patterns observed inside of our malware sandbox, not necessarily associated with a command and control channel. These could be domains serving up exploits, URLs used in click-fraud schemes, update servers for malware, or any number of other things that were consistent across a large number of malware
  • phishing-spam.rules: Phishing attacks and spam are the bane of the modern inbox. These rules seek to supplement your existing spam filtering system (you do have a good spam filter, right?) by looking for domains being advertised in malicious emails.

So, what happens if you turn these rules on and you start getting alerts? For the phishing/spam rules, you may wish to consider enabling them in blocking mode, to help prevent these malicious emails from coming into your network in the first place. For the blocklist and botnet/C&C rules, you've got a larger problem on your hands, since you're looking at outbound communications from an existing infection.

We've done our best to help you identify the particular piece of malware generating the traffic being detected by these rules. For most of the malicious domains in our blocklist rules, we've cross-referenced with other malware analysts and given you the name of at least one virus known to be associated with the domain in question.

Additionally, the references included in rules based on our malware sandbox data give you a list of md5sums of binaries that generated the traffic used to create the rule - which can help you cross-reference anything suspicious you may find on the system in question with tools like Virus Total and ThreatExpert.

Since these rule categories will be under active development, we welcome your suggestions on ways to improve them, and your feedback on how you've integrated them into your security process in the wild. Feel free to comment below, or reach us on IRC or email at research at sourcefire dot com.

Tuesday, July 13, 2010

Rule Release for Today, Tuesday July 13th, 2010

Microsoft Security Advisory MS10-042:

Microsoft Help and Support Center contains a programming error that may  allow a remote attacker to bypass security restrictions on an affected system. The error occurs when invalid hex-encoded characters are used as a parameter to a search query using the hcp:// URI schema.

Microsoft Security Advisory MS10-043:

The Microsoft Canonical Display Driver (cdd.dll) contains a programming error that may allow a remote attacker to execute code on a vulnerable system.

Microsoft Security Advisory MS10-044:

Microsoft Access contains mulitple vulnerabilities that may allow a remote attacker to execute code on an affected system.

Microsoft Security Advisory MS10-045:

Microsoft Outlook contains a programming error that may allow a remote attacker to execute code on an affected system.

Additionally, this release introduces three new rule groups, botnet-cnc.rules, blocklist.rules and phishing-spam.rules. These rule groups represent a decentralization of existing coverage from spyware-put.rules and specific-threats.rules. The rules themselves are gleaned from honeypot and malware data collected by the Sourcefire VRT.

As always, details are available here:

Thursday, July 8, 2010

Fundamentals of Exploit Development Class in VEGAS!

Need some more exploit fun? Want to stay in Vegas a little longer? Need some face time with the VRT? We are holding the fundamentals of exploit development class right after DefCon this year. August 2nd, 3rd and 4th in Las Vegas, NV.

For more details and to book your place, take a look at

Wednesday, July 7, 2010

Increase in attacks on CVE-2010-1885

Microsoft is warning that there has been an increase of attacks against a zero-day vulnerability in Microsoft Help and Support Center. The vulnerability is due to an error when using invalid hexadecimal characters in the search topic parameter of a URI. It can be used to bypass restrictions normally imposed by a command-line argument to load arbitrary help documents. Proof-of-concept code has been available since at least mid-June and has been proven to work with Windows XP, and Windows Server 2003, other versions may also be affected. While a patch is still not available, you should plan on patching as soon as one is. In the meantime, be careful or better, unregister the HCP protocol (manually, or by using this tool provided by Microsoft). However, doing so will break all local links that use hcp:// such as links in the Control Panel.

Snort coverage for CVE-2010-1885 is provided by sid 16665 while ClamAV signature BC.Exploit.CVE_2010_0815 will detect attacks leveraging this vulnerability.

Yes, Virginia, There is Cyberwar


I have been in security for 8 years.  Some of my friends say there is no such thing as cyberwar.  My manager says, "If you see it on the VRT Blog then it's so"  Please tell me the truth; is there cyberwar?

Virginia O'Hanlon.
115 West Ninety-Fifth Street.


Your friends are wrong.  They have been affected by the skepticism of a skeptical age.  They do not believe except what they see.  They think that nothing can be which is not comprehensible by their minds.  All minds, Virginia, are closed.

Yes, Virginia, there is cyberwar.  It exists as certainly as espionage, defacing and cybercrime exist, and you know that they abound and are a threat.  Alas!  Whenever there is a means for man to do ill to  his fellow man, that capability will be developed.

Not believe in Cyberwar!  You might as well not believe in enemies!  You might get your manager to hire people to watch all the inbound connections every day to catch the enemy, but even if they did not see them, what would that prove?  When they are at their best, nobody sees the enemy.  The most real and dangerous thing in the world are those that no one can see.  Did you ever see a keystroke logger on your system?  Probably not, but that's no proof that it is not there.  Nobody can conceive or imagine all the threats that are unseen and unseeable in the world.

Cyberwar is many things, Virginia, and sometimes we need to connect the dots to understand what is possible.  Have we ever been denied electricity by a foreign power?  No (we think).  But we know that networks can be penetrated, servers can be compromised and we even know that generators can be destroyed simply by instructions from control servers.  We also know that there are those who would seek to harm us.  So yes, Virginia, there is cyberwar.

But Virginia, an understanding that something is possible is not a license to let that thing dictate your life.  We need to recognize the threat, however unlikely, that cyberwar presents.  But not so that we can panic, cry and beg our leaders to give themselves more power.  Instead we need to understand the threat so we can improve our defenses and ensure that, if it were to occur, we would have a plan in place to deal with it.

We are right to look with skepticism when our leaders show us a problem and then present a solution that empowers them further.  We must never (again) allow our fear to weaken us to the point that we transfer all responsibility to our government.  A people without responsibility are a people without freedom.  Instead we must ensure that we all do our part, because if it comes to pass that a substantial cyber-attack does occur, we will all be responsible for helping to mitigate it.  But we must also hold our leaders in check; we must hold them accountable and ensure that they are prepared.  Yes, Virginia, it is a difficult balance, but it is one we must strike.

No cyberwar!  God, were that that was true.  It exists, and most likely will exist for as long as we are online.  A thousand years from now, Virginia, nay ten times ten thousand years from now, cyberwar will continue to be a threat.  But it is not a threat without checks and it is not an excuse for weakness and panic.

Thursday, July 1, 2010

Rule Release for Today, Thursday July 1st, 2010

Remote code execution in Adobe Acrobat and Reader. Some folks are claiming it's a denial of service, heh, right. RCE is possible, get your rules here: