snortattack

Late last month, Immunity published a blog post concerning a new way to escape the Java security warnings using a novel and simple method, by using the convenient Java Web Start framework. The Immunity team discovered a parameter called __applet_ssv_validated that sets whether you can run older versions of jre without user validation (Secure Static Versioning). Setting this parameter to true in the applet itself did nothing.

This brings us to Java Web Start.  As a framework meant to facilitate running applets, JWS uses a custom XML document with a special tag, jnlp. When you call an applet you can pass along parameters to the applet you want to run in your browser, including __applet_ssv_validated, like so: "<param name="__applet_ssv_validated" value="true" />".  This is one of the simplest Java exploits to come out in the last year or so, and it was jumped on immediately by exploit kit builders, most notably Blackhole.

The good news is that since it's so simple it can easily be detected, ClamAV signature Java.Trojan.Agent-26 detects it and Snort rules 26524 and 26525 have been out since the beginning of this month and have caught many potential attacks, such as the one below:


Since those rules have been released, exploit kit writers have been busy trying to obfuscate this exploit. A new variant caught by another exploit kit rule, 26535, now uses a jnlp_embedded which is used to pass along supplemental applet data parameter to paste the entire exploit in it's value field, using base 64 encoding thusly:


Detecting the jnlp_embedded parameter we can set snort to decode base 64 data and look for the same exploit conditions. Those rules are 26646 and 26647 and clam sig Java.Trojan.Agent-29.

Today is Update Tuesday and Microsoft is releasing updates for 33 CVEs across 10 bulletins. We'll be discussing some of the highlights here.

One of the most important updates (MS13-038) that is being released is for the recent 0-day in Internet Explorer, which was used in a watering hole attack on a Department of Labor internal website targeting Department of Energy employees. This vulnerability, CVE-2013-1347, affects IE8 and can allow an attacker to perform remote code execution via a use-after-free vulnerability. While it's currently not being exploited in any of the exploit kits that we monitor, Metasploit released an exploit for the vulnerability early last week. Sourcefire has detection for this vulnerability through SIDs 26569-26572.

Microsoft is also releasing a cumulative update for 11 other browser issues, including use-after-free vulnerabilities that could allow for remote code execution (MS13-037). These issues cover all supported IE versions, ranging from IE6 to IE10.

Publisher will also get updates for 11 issues that could allow for remote code execution (MS13-042). One slightly mitigating factor for these vulnerabilities is that they require a user to open the files in Publisher to be able to exploit them, so some user interaction is required as opposed to being exploitable by simply visiting a webpage. Two other products in the Office suite are also getting updates today: Word (MS13-043) is getting a fix for potential remote code execution vulnerability and Visio (MS13-044) is getting a fix for an information disclosure vulnerability. Both issues have similar mitigating factors to the Publisher vulnerability, requiring the user to load a maliciously crafted file. 

Another interesting update fixes a DirectX Graphics Kernel Subsystem Double Fetch Vulnerability (CVE-2013-1332, MS13-046) in a kernel mode driver discovered by Mateusz Jurczyk and Gynvael Coldwind using their tool bochspown, which they presented 3 weeks ago at SysScan '13. The vulnerabilities are basically the result of race conditions that are typical Time of Check to Time of Use (TOCTOU) vulnerabilities. More specifically the vulnerabilities are a result of a double-fetch, where the kernel retrieves a value from user mode, checks it and then retrieves the value from user mode again rather than using a cached copy. An attacker can modify the user-mode value between the time it is retrieved the first time and when it is retrieved again. If any checks occurred on the first fetch, they can no longer be considered valid on the second fetch. A typical example of an exploitable version of this vulnerability would be if a size for a copying function is retrieved from user-mode: it is checked to make sure the size is smaller than the destination memory's size, but during the call to the copy function the value is fetched again, resulting in an unchecked size being used. This can result in a buffer overflow if the attacker can change the value between the check and the use. Their tool found 89 potentially exploitable issues, 33 of which were not deemed exploitable, and 36 of which have already been fixed in various earlier Microsoft bulletins (MS13-016, MS13-017, MS13-031, MS13-036). Another 13 are considered local denial of services only. Today 1 more is being patched, leaving only 6 issues open according to Mateusz and Gynvael's SysScan slides.

Further updates cover an authentication bypass and an XML spoofing vulnerability in .NET (MS13-040). An important mitigating factor for the authentication bypass is that it requires non-standard configuration to be vulnerable. Another issue that is being updated is a vulnerability in Lync (MS13-041) that could allow an attacker to gain remote code execution during a session where the attacker shares content with a user. A mitigating factor for this vulnerability is that the user must accept an invitation from the attacker and must then view the content the attacker has shared.

The company is also releasing a fix for a denial of service vulnerability in HTTP.sys (MS13-039), Microsoft's kernel mode driver that handles the HTTP protocol stack for IIS since IIS6 and an update  for an information disclosure vulnerability in Windows Live essentials (MS13-045).

As always, we are releasing rules today that detect many of these vulnerabilities through SIDs 26622-26642.

PincerI was having a look at the Pincer family of Android malware and came across some code designed to hinder analysis.

From the decompilation of com/security/cert/a/a/c.class:

    String str1 = com.security.cert.b.b.b(paramContext);
    String str2 = com.security.cert.b.b.c(paramContext);
    String str3 = com.security.cert.b.b.d(paramContext);

    if(str3.toLowerCase().equals("android") || 
       str1.equals("000000000000000") || 
       str1.equals("012345678912345") || 
       str2.equals("15555215554") || 
       Build.MODEL.toLowerCase().equals("sdk") || 
       Build.MODEL.toLowerCase().equals("generic"))

At first glance, the application seems to be checking for generic values. The check against str2 is recognizable. It is the default phone number for the Android emulator. It is clear that the sample is also checking the model against the values sdk and generic. Having a look at com/security/cert/b/b.class to see what str1 and str3 are:

    public static String b(Context paramContext) {
        return ((TelephonyManager)paramContext.getSystemService("phone")).getDeviceId();
    } 

    public static String c(Context paramContext) { 
        return  ((TelephonyManager)paramContext.getSystemService("phone")).getLine1Number(); 
    } 

    public static String d(Context paramContext) {
        return ((TelephonyManager)paramContext.getSystemService("phone")).getNetworkOperatorName(); 
    }

The IMEI, phone number, network provider, and phone model are being checked against default emulator values. Crafty. I was running a generic AVD (Android Virtual Device) at the time and unfortunately got caught on all of these checks. Since compiling other people's large projects is something I avoid at all costs, I set out to patch these values in a hex editor. Here's how to change each one.

Before editing any file, please make a backup!
IMEIDoing a quick grep of the android-sdk-linux/ folder reveals that, among a handful of other files, the two emulator binaries each contain only one occurrence of the default IMEI.

    /home/vrt/android-sdk-linux/tools/emulator-arm:1
    /home/vrt/android-sdk-linux/tools/emulator-x86:1

These seem like a logical place to store the IMEI and since there is only one occurrence in each, it should be easy enough to edit and check the feedback. In any hex editor (GHex pictured) this value can be found between the strings  +CGSN and +CUSD:




Editing this value will change the AVD's IMEI on reboot. This process is detailed for Windows on the blogspot blooglog, which helped reassure me I was on the right track.

Network ProviderSince the IMEI is in the emulator-arm binary, I tried blasting some of the other values in there as well. I began by adding the digits 0-9 into the first ten occurrences of the default network provider, Android. Luckily enough, the first occurrence of Android (at the time, Andr0id) is what is pulled as the network provider. You can see it edited to SrcFire in the following screenshot, sitting between 0.10.50 and info:


ModelSince the model can change between AVD images, it is likely somewhere other than the binary.  The Cobra Den's post on making changes to the Android emulator got me on the right track for finding it (as well as some other fields worth changing). The model name follows the label ro.product.model= in android-sdk-linux/platforms/[target platform]/images/system.img, making it very easy to spot:


Note though, if you are loading from a snapshot, you will need to reload the AVD in order for these changes to take place. As well, if you are loading with a different system image (indicated by the -system option on emulator start), you will need to edit that image.

Phone NumberThe last four digits of the device's phone number are the port number that the emulator's console is running on. Since Pincer checks for an entire phone number (default prefix 1555521 + default console port number 5554), this was enough to circumvent the anti-analysis techniques encountered. Attempting to start up the emulator with the option -port 4141 provided this helpful tidbit:

    ERROR: option -port must be followed by an even integer number between 5554 and 5584

This gives a range of 16 phone numbers to work with. While allowing evasion of the anti-analysis in Pincer, a more intelligent malware author would write a check for 1555521. After some mass replacements with sed, I realized my normal trial and error approach would yield only error for changing the phone number.

It turns out that the phone number is stored on the SIM card. Since there is no actual SIM card, one is emulated. This emulated SIM is hard coded in the emulator-arm binary. The reason replacements for 1555521 failed is because SIM cards have a specification that does not store the MSISDN (Mobile Subscriber Integrated Services Digital Network-Number, AKA phone number) in plain text. Instead, each set of digits is swapped in some reverse nibbled endianness nightmare.

At this point I feel it's necessary to again give acknowledgment to The Cobra Den, which has a method for making a lot of these fields configurable by patching the Java getter methods, and to the CodePainters blog which has a post on editing the SIM card serial number. I had come across the source file external/qemu/telephony/sim_card.c in the Android source code, but the CodePainters post is really what made it click that the MSISDN  number would be in there, and that all of that would also be in the binary. As these things go, I found multiple very helpful things at the same time that all led me to the answer.

A quick way to find the MSISDN is to search for %d%df%d in the binary (highlighted in red below). The corresponding source code is in external/qemu/telephony/sim_card.c on line 436 in the current repo. The following is the format string portion of that sprintf:

    "+CRSM:144,0,ffffffffffffffffffffffffffffffffffff0781515525%d1%d%df%dffffffffffff"

The interesting part is 515525%d1 (highlighted in blue). Swapping each set of two digits produces 1555521%d (thanks again CodePainters). That looks like the prefix to our mobile number. Edited in ghex:



The edit in the previous screenshot will yield a phone number 1-876-543-[port number]. That gives (mostly) full control over the phone number. The first 7 digits are entirely configurable, and the last four can be any even number in the range 5554 and 5584 inclusive.

A malware author could still block based on the last four digits of the phone number. If that starts happening though, I know what the last four digits of my next phone number will be. :)

ConclusionThe biggest drawback to this method is that you must keep the length of each value the same, unless you wish to do some serious binary patching. As well,  I have not tested these for stability. I will update this blog post with any issues that come to my attention. The following is a before and after screenshot of the target values:

GG

We here at the VRT are all about backing up opinions with facts, and there are a lot of opinions about the nature of the vulnerability landscape out there. That in mind, we decided recently to study the numbers, and put conventional wisdom to the test.

At a high level, the numbers show that while vendors are putting increasing amounts of effort into security, critical vulnerabilities such as the recent Java, PDF, and Internet Explorer 0-days are on the upswing again of late. Combined with the clear upward trend in the amount of malware being dropped via these vulnerabilities - the Sourcefire VRT now sees an average of over 200,000 unique new malware samples per day - it is clear that users need to be vigilant as ever dealing with the modern threat landscape.

Here are some further highlights from the report:

• Total vulnerabilities and highly critical vulnerabilities were up in 2012 after a significant downswing over the previous few years; 2012 was a record-breaking year for the number of most critical vulnerabilities, those with a CVSS score of 10.
• Buffer overflows continue to be the most important type of vulnerability, with 35% of the total share of critical vulnerabilities over the last 25 years.
• For the first time since 1998, Microsoft did not lead vendors in terms of vulnerabilities reported in 2012; that dubious distinction went to Oracle, whose 2010 acquisition of Sun's Java programming language, a favorite of attackers, contributed to that trend.
• Firefox had more critical vulnerabilities than Internet Explorer over the time period studied, casting doubt on the conventional wisdom that IE is the least secure browser.
• Microsoft released 13% of their patches after the CVE was published, meaning that vulnerability information was publicly available and potentially exploited before a patch was released (0-day).

You can download the full report here. We hope you enjoy our quick dive into the world of vulnerability statistics; if there's any statistics you'd like us to look into in a follow-up post, let us know in the comments.

We at the VRT are always interested in vulnerabilities and information about vulnerabilities. To this end we recently dug into the NVD database and examined data for the last 25 years and used it to map out trends and general information on vulnerabilities in software.

Some of the questions we asked ourselves were:

• What are the most popular vulnerabilities?
• Which had the most impact?
• Which vendors and products suffered from the most issues?
• Which browser is the best in terms of vulnerabilities found?
• How many 0-days are found in products?

While the answers to some of these questions are predictable, others are surprising.
We will be presenting the answers to these questions in a talk at RSA Conference San Francisco 2013. If you're attending RSA and are interested in the answers to these questions, please join us on March 1st at 9.00 AM. A report delving into the details will be released after the conference, you can pre-register here and you will receive a link to the report once it's been published.

UPDATE: the full report has now been released, download it here

Exploit kits may not be as hot a topic as the recently released Mandiant Report, but they're still an important part of today's threat landscape. As the success of the Cool Exploit Kit lets its author buy vulnerabilities, for example, these kits are not only one of the more prevalent ways of dropping malware on end-users, they're actually pushing defenders towards a time with more and more 0-days to worry about.

Those of you who would like to understand more about how these kits work, check out my recent presentation on the subject. The presentation assumes no prior knowledge, so it's a perfect starting point even for management types who might not quite understand the threat landscape.

For those of you running Sourcefire/Snort boxes who are looking for exploit kit coverage, be sure to review how many rules from our new Exploit-Kit category you have enabled - while 200 of the 222 in that category are in the balanced policy by default, if you're not running a current SEU, you're missing a lot of powerful detection.

Much like other vendors in the security space, the VRT spent yesterday scrambling to address the latest Adobe/PDF vulnerability. The attack - which works across multiple operating systems, bypasses Adobe's sandbox, and which has been used in recent targeted campaigns - is still without a patch, as Adobe mobilizes their response organization to address the matter.

Upon first opening the sample, it was blatantly obvious that something fishy was going on, as the first content in the file was a ~400K+ block of highly obfuscated JavaScript:

/JS (\n0 >> 0 >> 0 >> 0 >> 0 >> 0;\nfunction sHOGG\(c,d,e\){\n    var idx = d % c.length;\n    var s = "";\n    while \(s.length < c.length\){\n        s += c[idx];\n        idx = \(idx + e\) % c.length;\n    }\n    return s;\n}\n0 >> 0 >> 0 >> 0 >> 0 >> 0;\nfunction oTHERWISE\(pRENDENDO,t\){\n if\(pRENDENDO == sHOGG\('014.031.4.',3571,9173\)\){\n var r="";\nr+=ue\(t+2*2*2*3+11*3\);\nr+=ue\(t+11*5+2\);r+=ue\(t+19*3\);r+=ue\(t+3*19\);r+=ue\(t+19*3\);r+=ue\(t+43+7*2\);r+=ue\(t+11*2+5*7\);r+=ue\(t+19*3\);r+=ue\(t+3*3*2*2+7*3\);r+=ue\(t+11*3+2*2*3*2\);r+=ue\(t+2*7+43\);r+=ue\(t+19*3\);r+=ue\(t+3*19\);r+=ue\(t+19*3\);\nr+=ue\(t+19*3\);r+=ue\(t+3*19\);r+=ue\(t+31+13*2\);\nr+=ue\(t+19*3\);r+=ue\(t+5+2*2*13\);

We're currently testing signatures that would detect files like these on a generic level - while JavaScript in PDFs is nothing new, typically that script is small, well-defined, and represents a much smaller portion of the overall file size. In the meantime, we are releasing today SIDs 25818 and 25819 to counter this particular threat, and 25817 to detect command and control traffic associated with this campaign.

The DDoS has gone, thanks to everyone that helped with intel and takedowns. We are extremely lucky to have such good friends!

Back to normal business. Rule distribution wasn't ever disrupted, but our documentation site was out for the duration of the ddos. We're going to look at moving more of the infrastructure to ddos-proof facilities as we get the revenue flowing through ET Pro. More on that as it develops!

And again, a huge thanks to all who saved our bacon. You know who you are, and we all owe you one.

Matt 

2007765 - ET POLICY Logmein.com Host List Download (policy.rules)
2007766 - ET POLICY Logmein.com Update Activity (policy.rules)
Pulled these out of DELETED. It appears they may still be applicable.

2011886 - ET WEB_SPECIFIC_APPS Webspell wCMS-Clanscript staticID Parameter SQL Injection Attempt (web_specific_apps.rules)
by dave richards

2011887 - ET SCAN Medusa User-Agent (scan.rules)
by will metcalf. Definitely hostile if seen. Blockable.

2800847 - ETPRO POLICY Logmein.com SSL Remote Control Access (policy.rules)
2800848 - ETPRO POLICY Logmein.com SSL Client Communication wt.logmein.com (policy.rules)
2800849 - ETPRO POLICY Logmein.com SSL Client Communication secure.logmein.com (policy.rules)
New sigs written at a Pro client's request. Not perfect as logmein.com does everything by SSL, but we can see their cert and detect beaconing clients at least.

A brief summary of what we've covered today. 

 

2011872 - ET USER_AGENTS Suspicious Gbot UA Detected (user_agents.rules)

New for Gbot, uses a unique user-agent like gbot/2.1. Very nice of them to make that easy for us. 

 

2011873 - ET CURRENT_EVENTS Suspicious HTTP GET to JPG with query string (current_events.rules)

Also Gbot related, please report falses on this. As was noted on the list this is related to hostile ad serving activity and may false on real ads.

 

2011874 - ET POLICY NSPlayer User-Agent Windows Media Player streaming detected (policy.rules)

New policy sig to know when someone is streaming using WMP.

 

2011875 - ET WEB_SPECIFIC_APPS DBHcms editmenu Parameter SELECT FROM SQL Injection Attempt (web_specific_apps.rules)

2011876 - ET WEB_SPECIFIC_APPS DBHcms editmenu Parameter DELETE FROM SQL Injection Attempt (web_specific_apps.rules)

2011877 - ET WEB_SPECIFIC_APPS DBHcms editmenu Parameter UNION SELECT SQL Injection Attempt (web_specific_apps.rules)

2011878 - ET WEB_SPECIFIC_APPS DBHcms editmenu Parameter INSERT INTO SQL Injection Attempt (web_specific_apps.rules)

2011879 - ET WEB_SPECIFIC_APPS DBHcms editmenu Parameter UPDATE SET SQL Injection Attempt (web_specific_apps.rules)

2011880 - ET WEB_SPECIFIC_APPS phpBazar picturelib.php Remote File inclusion Attempt (web_specific_apps.rules)

2011881 - ET WEB_SPECIFIC_APPS Open Web Analytics mw_plugin.php IP Parameter Remote File inclusion Attempt (web_specific_apps.rules)

2011882 - ET WEB_SPECIFIC_APPS Open Web Analytics owa_action Parameter Local File inclusion Attempt (web_specific_apps.rules)

2011883 - ET WEB_SPECIFIC_APPS Open Web Analytics owa_do Parameter Local File inclusion Attempt (web_specific_apps.rules)

2011884 - ET WEB_SPECIFIC_APPS iGaming CMS loadplugin.php load Parameter Local File inclusion Attempt (web_specific_apps.rules)

New specific apps stuff rom Stillsecure, thanks guys!

 

2800837 - ETPRO WEB_CLIENT Adobe Shockwave Director tSAC Chunk Parsing Memory Corruption (web_client.rules)

2800838 - ETPRO WEB_CLIENT Adobe Shockwave Director tSAC Chunk Parsing Memory Corruption (web_client.rules)

2800840 - ETPRO WEB_CLIENT Adobe Shockwave Director dcr access (web_client.rules)

2800841 - ETPRO WEB_CLIENT Adobe Shockwave Director pamm Chunk Memory Corruption (web_client.rules)

For the latest Adobe 0-days of the... day. We'll have another one tomorrow I'm sure. 

 

2800839 - ETPRO EXPLOIT HP Data Protector Express DtbClsLogin Stack Buffer Overflow (exploit.rules)

CVE 2010-3007, significant local threat. 

 

2800842 - ETPRO EXPLOIT IBM Rational Quality Manager and Test Lab Manager Policy Bypass (exploit.rules)

Bugtraq 44172. Not sure how much this one will be exploitable, but still worth seeing. 

 

2800843 - ETPRO WEB_CLIENT RealNetworks RealPlayer CDDA Access (web_client.rules)

2800844 - ETPRO WEB_CLIENT RealNetworks RealPlayer CDDA Access 2 (web_client.rules)

2800845 - ETPRO WEB_CLIENT RealNetworks RealPlayer CDDA URI Uninitialized Pointer Code Execution (web_client.rules)

These may produce some load, so we'll keep an eye on it. They shouldn't be too prone to falsing as far as web-client style signatures go. If you see these it'll be worth checking out. 

 

2800846 - ETPRO TROJAN Worm.Win32.Faketube Activity (update request) (trojan.rules)

This worm's CnC channel is very good at looking like normal traffic. Could be some falses here, and we'll try to adjust if so. 

 

More tomorrow!! We'll try to do these updates each day, Please send in suggestions for what to cover and discuss here. The ET Pro research team is up to speed and covering everything new that we find, or comes across the wire. IT'S ON!!! These guys are good!

 

Matt

We now officially have support for Snort 2.4.0 and higher, and Snort 2.9.0 current available in both the et Open, open-nogpl, and ET Pro rulesets!

Appreciate everyone's patience in getting these final 2 platform's qa'd and out the door. Please give them a run and let us know how they fare!

You can find the rules at:

http://rules.emergingthreatspro.com/

Choose your version and platform and you're all set!

Thanks!

The ET Pro Team 

 

Thanks to all for your patience, and to everyone who's chipped in to help do this work. It's been about 4 months of converting and testing, but we FINALLY have the open ruleset all ready to re-launch. 

 

The updated rules can be found at:

 

http://rules.emergingthreats.net

 

For this conversion to 2.8.4, 2.8.6, and suricata we've ingested the old Snort GPL rules (sid 3464 and prior) to convert as well as some of the valuable community sigs in order to keep complete coverage on older platforms. They'll no longer be available from VRT in 2.8.6 and prior, so we're doing so here.

 

All have been converted and tweaked to provide a more complete ruleset. But of course if you're staying with VRT as your primary ruleset and want to add the ET Open rules you'll have GPL sid duplication. So to make it possible for you to choose to stay with VRT we have provided a version of the ruleset that does NOT contain the GPL or community rules that would overlap. We will support this for the long term, so if you do choose to stay with VRT please continue to use the free ET rules! 

 

Some notes:

1. The rules.emergingthreats.net dns name is a round robin to a couple of servers now, and we'll be adding a few more over time. So we won't have the bandwidth crush issues when we would publish on the old systems.

 

2. The old ruleset at www.emergingthreats.net/emerging.rules.tar.gz / zip will remain there, but they WILL NOT BE UPDATED ANY FURTHER. In a couple of weeks, based on feedback, we may set up a redirect to the snort-2.8.4 tarball so we don't lose a lot of automated sensors out there updating on their own. The problem is though that the filenames inside the tarball have changed to reflect our full use of categories. 

 

3. The open rulesets retain the file naming convention emerging-<category>.rules. (The et pro rules do not have emerging- to avoid confusion) We have added a lot of categories though, so check the included emerging.conf to make sure you're including all you want to run.

 

4. You must choose your platform. 2.8.4 is where the rulesets USED to be. No http_*, file_data, fast_pattern, etc. While 2.8.4 did support some of the http_* functions, the 2.8.6 version of the ruleset is the first that we've brought all of this together. 

 

5. Snort 2.4 support will be available soon, as will snort 2.9.0. Keep an eye out for both in the open and pro rulesets! 

 

6. The version file at http://rules.emergingthreats.net/version.txt will continue to be updated and picks up from where we were, no rollback. We encourage you to use that file to sense when your scripts need to pull an update! The old files that were for the compromised list, rbn list, and dshield rev won't be continued. They all incremented at the same time, and will continue to, so we're just going to rely on the master version counter if no one objects. 

 

I'll get the backlog of sigs sent to the list committed. We will continue to update the ruleset as often as possible. Likely we'll settle into a once a day update cycle. No less than that for sure!

 

Thanks again to everyone for your patience. Please grab the new tarball, beat it up. I am CERTAIN we have mistakes in there because my hands have been in it, so please let me know!!

 

We are adding a full coverage premium subscription ruleset. So not really selling out I suppose, it's just us still. No outsiders... so we're kind of selling out to ourselves. If you have to sell out that's the way to do it I think!

We are building a new ruleset, one that has full vulnerability coverage. We have a professional research team on full time now, and we've bought the Telus Security Labs feed (the guys that supply the entire industry with research, rules, and intel, the big brains!). This has allowed us to fill in the historical gaps in coverage of the open ET ruleset, and will assist us in keeping completely up to date with new vulnerabilities and new exploits as they happen.  http://www.emergingthreatspro.com

But wait, there's more!!!

What's the biggest security threat on your network, and every network these days? (besides your users) 

It's malware. I don't think there's any argument there, and that's why the ET ruleset has been so useful, because we all focus on malware. You don't get the malware coverage in the existing commercial rulesets because it just moves too quickly. And all the commercial rulesets are built for an appliance the same company sells, so adding more rules day after day doesn't make the appliance they also sell look good as it slows down. So the result: we have commercial rulesets with only minimal malware coverage, so we all use the ET ruleset to augment.

So we're changing that, we're making THIS the one ruleset you need, not the one you add on to the others. We have the full time research team, we have the intelligence feeds, and we have enough coffee to keep the state of Washington awake for a year straight. We're on it! We've hired most of our researchers from the Emerging Threats Community (and we're still hiring, shoot me a resume if you want to play with us!). So it's the people you already know and trust. We've been doing this for 10 years now. 

We're JUST doing rules, not hardware. This is a major difference. You now have a CHOICE in what ruleset you use just like you choose the hardware that fits your needs.

We're rebuilding and expanding the ET Sandnet that's been feeding us so much good intel over the years, and we're partnering with all the names you already know in the industry to share intel, samples, and more.

But wait, there's more!!!

We're publishing in many engine formats. One of the drivers to do this was to get a full coverage ruleset out there that could take advantage of the new capabilities of Suricata. It's pretty clear no one else is going to do that, so we're going to make it happen. 

At launch we are covering Snort 2.8.4 era, 2.8-CURRENT, and Suricata. We'll have a Snort 2.4 ruleset out shortly to support those of you using an older engine. And here's the big thing.... We'll support 2.4, and all of our platforms, until no one needs it anymore! If you can't upgrade, fine. Not everyone needs to, can, or wants to upgrade. As long as people need it we'll keep putting out a 2.4. 

The Existing and future ET ruleset will also be published in these formats! 

We'll be introducing new platforms and languages later this year as well, so keep an eye out.

But wait, there's more!!!!

Emerging Threats Pro exists because of the community, ET *is* the community, it's been my honor to be the moderator all these years. We will stay part of that community. So here's my personal commitment, and the commitment of the new company Emerging Threats Pro, to the community. Write this down, frame it whatever. (I'm hanging it on my office wall)

1. ET Pro will support the Emerging Threats open project as long as needed. Hosting, infrastructure, manpower, everything. 

2. The Emerging Threats Ruleset will remain FREE, BSD licensed as it always has been. That will not change unless we all agree we need to change it.

3. Every rule that comes from the community will immediately go through the ET Pro QA and load testing rig, and be converted to all the platforms we support as a company, and be IMMEDIATELY distributed to the community in ALL of those formats. All rules, in all formats, QA'd and converted, IMMEDIATELY. We'll do the grunt work. 

4. I will turn over control of the project to a board of five community members to make the decisions, those board members will be elected. (I will stand for election as well. VOTE JONKMAN! :) )

 

We'll set up that board for ET soon and get an election going. The reason I want to do that is we've seen things go bad in many other open source projects over the years when money and company interests come before keeping the community the project came from happy. I believe I will do a good job taking care of both projects for the long term, but I'm human like everyone else. I don't think anyone that's gone through this process of building a business behind an open project and ended up alienating a community went into it intending to do so. I would regret it forever if that happened to us. So to make SURE that doesn't happen I am going to give full control of the open project to the community. 

That means you still have a stake in the project, and you have to step up and help govern it. You have to nominate responsible board members, and these board members have to put a little work into it now and then. And if you don't like how things are going you have to speak up, offer solutions, or get yourself elected to the board and make changes. If the you or the board really don't like how I and the ET Pro team are taking care of things then you may take over and manage the project. You'll have full power to do so at any time.

It of course worries me to give up full control of Emerging Threats. It's been my baby for many years now (8, 9?). But I have faith in this community. I KNOW we will take care of this thing we've built, and I KNOW it will last a very long time and continue to do good things. Because of that faith I think I can get over having sole control and let this thing live it's own life. (Maybe this is what it'll be like when my daughters go to college...)

So, more details coming soon on the technical changes. Your download url won't change if you want the 2.8.4 ruleset as it is now. I'll get the charter for this board out soon and we can get some nominations and election going.

Bottom line:

1. ET Pro will offer a complete ruleset based on and expanding the ET open ruleset

2. ET Pro will support the open project in all it needs

3. You are going to have a say in how we run the open project from here out

4. You have a choice where to get your rules now!

 

Comments welcome as always. 

The OISF is proud to announce that NVIDIA has joined the foundation as a technology partner to help develop and enhance CUDA GPU based acceleration within Suricata. This exciting development gives the foundation access and assistance from NVIDIA engineers and designers to bring you Suricata IDS/IPS GPU acceleration on standard hardware.

Watch for new developments with GPU acceleration to hit the streets very soon!