Site Network:

Feed aggregator

Decoding Domain Generation Algorithms (DGAs) - Part I

vrt rules - Wed, 02/12/2014 - 16:00
Part 1 - Unpacking the binary to properly view it in IDA Pro

Recently, I came across an executable(MD5: 3D5060066056369B3449606F3E87F777) that was expected to be malicious in nature, but its network behavior was what was really interesting. So the first thing I did was throw it into a Virtual Machine. Running Wireshark, I immediately noticed several DNS queries per second to what appeared to be "random" domain names (I have modified my DNS settings so all domains are giving a response):


If you are familiar with malware, this is typical of a piece that uses an algorithm to generate domain names to call out to. If we want to block these domains in the future, we must reverse the process of generating these names and implement our own version.
But how does this work? What process is doing it? Is it using the WS2_32 library? WinINet? Maybe RPC functions in other executables? I use a great tool called API Monitor to quickly tell what libraries are being used within an unknown binary. For this case, I'm using it specifically to learn what functions the malware uses to call out or receive data. Shortly after using API Monitor, it becomes clear that it is actually Explorer.exe calling out to the internet using WinINet functions:




So we must figure out how these likely malicious instructions are injected into Explorer and then what the algorithm it uses to generate domains is. I will try to be brief about the other functionality of the malware so that I can focus more finding and decoding the DGA algorithm itself.
Unpacking the Child Executable (general overview)(TLDR, just dump it with your favorite debugger/dumping program(s) and move to the next section if you want)
When the malware is executed, it drops another executable on disk with a “random” name and executes it. For example, mine was called:
C:\Documents and Settings\User\Application Data\Eqebu\eptixo.exe(MD5: 577A7717AFE10AA03B07C6433AEC1845)
To figure out what it does, we need to unpack it for analysis (assuming that it is packed).
 Though PEiD says it’s not packed:

Opening it in IDA shows us something different:



Look at all that tan (unexplored space) in the navigation band. No Bueno. This is a key indicator that this executable is packed. So let’s unpack this thing.
0 0 1 63 362 Cisco 3 1 424 14.0 Normal 0 false false false EN-US JA X-NONE /* Style Definitions */ table.MsoNormalTable {mso-style-name:"Table Normal"; mso-tstyle-rowband-size:0; mso-tstyle-colband-size:0; mso-style-noshow:yes; mso-style-priority:99; mso-style-parent:""; mso-padding-alt:0in 5.4pt 0in 5.4pt; mso-para-margin:0in; mso-para-margin-bottom:.0001pt; mso-pagination:widow-orphan; font-size:12.0pt; font-family:Cambria; mso-ascii-font-family:Cambria; mso-ascii-theme-font:minor-latin; mso-hansi-font-family:Cambria; mso-hansi-theme-font:minor-latin; mso-fareast-language:JA;}
If we open it in Ollydbg (I use Ollydbg 2 later, I only had the OllyDump plugin for version 1 at the time) or your favorite debugger/dumping program, we can just step until we see a ‘PUSHAD’ instruction. Looking around this instruction shows us the decoding loop:

If we enter the function called by:
004010D1   . FFD1            CALL ECX                                   ;  eptixo.0040770A
0 0 1 26 152 Cisco 1 1 177 14.0 Normal 0 false false false EN-US JA X-NONE /* Style Definitions */ table.MsoNormalTable {mso-style-name:"Table Normal"; mso-tstyle-rowband-size:0; mso-tstyle-colband-size:0; mso-style-noshow:yes; mso-style-priority:99; mso-style-parent:""; mso-padding-alt:0in 5.4pt 0in 5.4pt; mso-para-margin:0in; mso-para-margin-bottom:.0001pt; mso-pagination:widow-orphan; font-size:12.0pt; font-family:Cambria; mso-ascii-font-family:Cambria; mso-ascii-theme-font:minor-latin; mso-hansi-font-family:Cambria; mso-hansi-theme-font:minor-latin; mso-fareast-language:JA;} We see that memory is allocated at the call to 0x407DBE:
 and written to:
Memory map, item 16 Address=00370000 Size=00001000 (4096.) Owner=         00370000 (itself) Section= Type=Priv 00021040 Access=RWE Initial access=RWE
0 0 1 47 274 Cisco 2 1 320 14.0 Normal 0 false false false EN-US JA X-NONE /* Style Definitions */ table.MsoNormalTable {mso-style-name:"Table Normal"; mso-tstyle-rowband-size:0; mso-tstyle-colband-size:0; mso-style-noshow:yes; mso-style-priority:99; mso-style-parent:""; mso-padding-alt:0in 5.4pt 0in 5.4pt; mso-para-margin:0in; mso-para-margin-bottom:.0001pt; mso-pagination:widow-orphan; font-size:12.0pt; font-family:Cambria; mso-ascii-font-family:Cambria; mso-ascii-theme-font:minor-latin; mso-hansi-font-family:Cambria; mso-hansi-theme-font:minor-latin; mso-fareast-language:JA;} Data is then copied over to that newly allocated area of memory (another typical unpacking technique), and we actually end up returning to it:
0 0 1 21 124 Cisco 1 1 144 14.0 Normal 0 false false false EN-US JA X-NONE /* Style Definitions */ table.MsoNormalTable {mso-style-name:"Table Normal"; mso-tstyle-rowband-size:0; mso-tstyle-colband-size:0; mso-style-noshow:yes; mso-style-priority:99; mso-style-parent:""; mso-padding-alt:0in 5.4pt 0in 5.4pt; mso-para-margin:0in; mso-para-margin-bottom:.0001pt; mso-pagination:widow-orphan; font-size:12.0pt; font-family:Cambria; mso-ascii-font-family:Cambria; mso-ascii-theme-font:minor-latin; mso-hansi-font-family:Cambria; mso-hansi-theme-font:minor-latin; mso-fareast-language:JA;} The binary reads in more data from itself using ReadFile. Nothing will execute in the main memory segment until the file is finished unpacking.

0 0 1 64 369 Cisco 3 1 432 14.0 Normal 0 false false false EN-US JA X-NONE /* Style Definitions */ table.MsoNormalTable {mso-style-name:"Table Normal"; mso-tstyle-rowband-size:0; mso-tstyle-colband-size:0; mso-style-noshow:yes; mso-style-priority:99; mso-style-parent:""; mso-padding-alt:0in 5.4pt 0in 5.4pt; mso-para-margin:0in; mso-para-margin-bottom:.0001pt; mso-pagination:widow-orphan; font-size:12.0pt; font-family:Cambria; mso-ascii-font-family:Cambria; mso-ascii-theme-font:minor-latin; mso-hansi-font-family:Cambria; mso-hansi-theme-font:minor-latin; mso-fareast-language:JA;} A few instructions later, we see a call to VirtualProtect(), setting our main executables memory permissions to PAGE_READWRITE. Then, another REP MOV instruction is encountered (used to move bytes until ECXis 0), followed by another call to VirtualProtect() setting memory access back to PAGE_EXECUTE_READ. (Note: You can sometimes just set the main section to READONLY but DEP will cause an access violation if it gets executed)
  1. VirtualProtect() -> Set original memory segment to PAGE_READWRITE
  2. Move data from unpacked section to original memory segment
  3.  VirtualProtect() -> Set original memory segment back to PAGE_EXECUTE_READ
This usually means that we are going to be modifying our binary (unpack data into), so the binary needed to set permissions to write over these areas in memory, unpack itself, and then reset those permissions back.



We see this again a few more steps later. Note the PUSHAD/POPAD instructions surrounded by a loopd instruction, this is yet another signature of code being packed/unpacked. Usually an unpacker will save all of the registers before unpacking and then restore them to their original state afterwards.


Still further down we see:


This instruction is placing the value 0x000253C3 into ESI then adding it to EDI, which points to the base address of our current executable (0x400000). ESI will then contain 0x004253C3. This address is eventually placed on the stack and returned to. This is the first time an instruction has been executed in the original memory address since entering the allocated range. This is the "OEP" (Original Entry Point). This executable is now unpacked. But now you have to somehow write it to disk.
To dump it, there is a useful OllyDbg plugin called:OllyDump (http://www.openrce.org/downloads/details/108/OllyDump) and a tool called:ImpRec (http://www.woodmann.com/collaborative/tools/index.php/ImpREC).
Just make sure EIP is pointed to OEP 0x004253C3.
1.     Go to Plugins -> OllyDump -> Dump Debugged Process2.     Uncheck “Rebuild Import”3.     Click “Dump” and save it on disk somewhere



Now open ImpRec1.     Open the saved dump file in ImpRec2.     Under “Attach to an Active Process”, select the currently-debugged child process you just dumped this executable from.


3.     Enter 253C3 in the “OEP” field (Remember 004253C3?). This is the offset of the OEP from 400000 in the file.

4.     Click “IAT AutoSearch”. It should say that it may have found the Original IAT (Import Address Table).

5.     Click “Get Imports”

6.     Click “Fix Dump”, select the binary you are currently working on and click “Open”.

7.     It should save it as the same name as the selected binary with an underscore at the end. It is now dumped!


Check it out in IDA now… Much better!


Clearly, there is some more information in the tan area that will probably be used later. However, now that the executable is dumped, it is much easier to get an idea of what is going on with the use of this static data combined with dynamic analysis.
v\:* {behavior:url(#default#VML);} o\:* {behavior:url(#default#VML);} w\:* {behavior:url(#default#VML);} .shape {behavior:url(#default#VML);} 0 0 1 949 5410 Cisco 45 12 6347 14.0 Normal 0 false false false false EN-US JA X-NONE /* Style Definitions */ table.MsoNormalTable {mso-style-name:"Table Normal"; mso-tstyle-rowband-size:0; mso-tstyle-colband-size:0; mso-style-noshow:yes; mso-style-priority:99; mso-style-parent:""; mso-padding-alt:0in 5.4pt 0in 5.4pt; mso-para-margin:0in; mso-para-margin-bottom:.0001pt; mso-pagination:widow-orphan; font-size:12.0pt; font-family:Cambria; mso-ascii-font-family:Cambria; mso-ascii-theme-font:minor-latin; mso-hansi-font-family:Cambria; mso-hansi-theme-font:minor-latin; mso-fareast-language:JA;}
In the next post, I will go into catching the injection into the explorer process and landing at the entry point. Thanks for reading!

Microsoft Update Tuesday: February 2014, huge fix for Internet Explorer

vrt rules - Tue, 02/11/2014 - 19:32

Normal 0 false false false EN-US X-NONE X-NONE /* Style Definitions */ table.MsoNormalTable {mso-style-name:"Table Normal"; mso-tstyle-rowband-size:0; mso-tstyle-colband-size:0; mso-style-noshow:yes; mso-style-priority:99; mso-style-parent:""; mso-padding-alt:0cm 5.4pt 0cm 5.4pt; mso-para-margin-top:0cm; mso-para-margin-right:0cm; mso-para-margin-bottom:8.0pt; mso-para-margin-left:0cm; line-height:107%; mso-pagination:widow-orphan; font-size:11.0pt; font-family:"Calibri","sans-serif"; mso-ascii-font-family:Calibri; mso-ascii-theme-font:minor-latin; mso-hansi-font-family:Calibri; mso-hansi-theme-font:minor-latin;}
The Microsoft Updates are pretty significant this month. Internet Explorer, which was missing from the updates for the first time in a long time last month is back with a whopping 24 vulnerabilities. Besides the IE bulletin, there’s six more bulletins, 4 of which are rated critical and 3 of which are rated important. All-in-all, this Update Tuesday provides fixes for 32 CVEs. The list of bulletins below is ordered by rating rather than number (i.e., the same ordering as used here: https://technet.microsoft.com/en-us/security/bulletin/ms14-feb).
The first bulletin, MS14-010, deals with IE and is rated critical and provides fixes for 24 CVEs. As is usual, most of the vulnerabilities are the result of use-after-free vulnerabilities. Most of the vulnerabilities were reported privately to Microsoft, but there is also one fix for a publicly disclosed vulnerability (CVE-2014-0267), a use-after-free vulnerability. 
The second critical bulletin, MS14-011, provides an update for a vulnerability in VBScript that is shared with the IE bulletin (CVE-2014-0271), where a type confusion vulnerability could lead to arbitrary code execution.
  MS14-007 is also rated critical and it fixes a vulnerability in Direct2D (CVE-2014-0263) that could result in remote code execution. The vulnerability can be triggered if a user browses to a malicious website and is presented with a malicious SVG object.
The final critical bulletin this month is MS14-008.  This vulnerability occurs in Microsoft’s Forefront Protection 2010 which provides anti-malware and anti-spam protection for Exchange Server. The vulnerability occurs when a specifically crafted email is scanned by the server and could result in remote code execution (CVE-2014-0294). It is unclear if the vulnerability can be triggered and there are currently no known exploitation scenarios for this vulnerability. 
Microsoft’s next bulletin, MS14-009is rated as important and deals with the .NET framework. It is the only bulletin besides IE that compromises multiple CVEs: three in total. Two of these have been publicly disclosed. The first one is a denial of service in ASP.NET that can be triggered via an incomplete POST request (CVE-2014-0253). The second publicly disclosed vulnerability is an ASLR bypass (CVE-2014-0295) due to a lack of ASLR support in VSAVB7RT.DLL. Finally, the last vulnerability in this bulletin is an escalation of privilege vulnerability due to type traversal (CVE-2014-0257).
MS14-005 is also rated as important and provides a fix for a single vulnerability in XML Core Services that could result in a bypass of the same origin policy (CVE-2014-0266). This could allow information disclosure, where an attacker could read local files on disk via a malicious webpage. This information leak was previously used in conjunction with the IE 0-day “Watering hole” vulnerability (CVE-2013-3918), which was patched in a previous update cycle. The information disclosure vulnerability was used to retrieve thetimestamp from the PE headers of msvcrt.dll to allow the attacker to use a ROP chain specific to that version of the DLL.

The last bulletin of the month is MS14-006 and is rated as important. It provides an update for Microsoft’s IPV6 TCP/IP stack, where maliciously crafted IPV6 routing discovery packets sent on the same subnet as the vulnerable machine could result in a denial of service (CVE-2014-0254), which causes the machine to become unresponsive while processing these packets and could possibly crash.

The VRT is releasing the following rules SIDs 23178, 24926, 29655, 29667-29668, 29671-29722, 29727-29738 and 29741-29744 to address these issues.

Four vulnerabilities in Pidgin

vrt rules - Tue, 01/28/2014 - 16:31

Normal 0 false false false EN-US X-NONE X-NONE /* Style Definitions */ table.MsoNormalTable {mso-style-name:"Table Normal"; mso-tstyle-rowband-size:0; mso-tstyle-colband-size:0; mso-style-noshow:yes; mso-style-priority:99; mso-style-parent:""; mso-padding-alt:0cm 5.4pt 0cm 5.4pt; mso-para-margin-top:0cm; mso-para-margin-right:0cm; mso-para-margin-bottom:8.0pt; mso-para-margin-left:0cm; line-height:107%; mso-pagination:widow-orphan; font-size:11.0pt; font-family:"Calibri","sans-serif"; mso-ascii-font-family:Calibri; mso-ascii-theme-font:minor-latin; mso-hansi-font-family:Calibri; mso-hansi-theme-font:minor-latin;}
The VRT is announcing the discovery and patching of 4 CVE vulnerabilities in Pidgin. These vulnerabilities were discovered by the VRT VULNDEV team and reported to the Pidgin team. The VRT also created TRUFFLE rules that have been protecting Sourcefire customers for these vulnerabilities since October 1st 2013, while the Pidgin team was working on patching them. TRUFFLE rules provide a way for the VRT to release cutting edge coverage without exposing threats to the public through a plaintext rule. We are releasing these rules publicly as part of our update today, since the Pidgin team is releasing Pidgin 2.10.8 that addresses these issues. It is available for download here: http://www.pidgin.im/
Here is a summary of the vulnerabilities and the associated rules, with links to blog posts describing the vulnerabilities in detail:o   We had prior coverage for this vulnerability through an http_inspect alert GID 120, SID 8 as well as SID 2580.o   We are releasing SID 28088 to handle this vulnerability.
o   We are releasing SIDs 28089 and 28090 to cover this vulnerability.
o   We also had prior coverage for this vulnerability through SIP preprocessor alert, GID 140 SID 16.

VRT-2013-1002 (CVE-2013-6489): Buffer overflow in MXit emoticon parsing

vrt rules - Tue, 01/28/2014 - 16:30
Sourcefire Vulnerability Report VRT-2013-1002 (CVE-2013-6489): Buffer overflow in MXit emoticon parsingDescriptionAn exploitable remote code execution vulnerability exists in Pidgin's implementation of the Mxit protocol in the libpurple library. An attacker who can control the contents of an Emoticon downloaded through the Mxit protocol can cause an allocation to return NULL which can later be used to write into the lowest page of memory. An attack requires the ability to spoof messages from the mxit.com domain to exploit this vulnerability.
Tested Versions

Pidgin 2.10.7
Coverage SID 28088
Details  When downloading an emoticon via the mxit protocol, it is possible to cause a buffer overflow, by providing an invalid utf8 length. This occurs in the function asn_getUtf8() at line 216 of pidgin-2.10.7\libpurple\protocols\mxit\markup.c:

  204        static int asn_getUtf8( const gchar* data, gchar type, char** utf8 )
  205         {
  206             int        len;
  207
  208             /* validate the field type [1 byte] */
  209             if ( data[0] != type ) {
  210                 /* this is not a utf-8 string! */
  211                 purple_debug_error( MXIT_PLUGIN_ID, "Invalid UTF-8 encoded string in ASN data (got 0x%02X, expected 0x%02X)\n", data[0], type );
  212                 return -1;
  213             }
 
Here len will be read in as a 1 byte value from data[]. However, because len is a signed integer, a length of 0xFF will be interpreted as a len of -1.

  215             len = data[1];                        /* length field [1 bytes] */

The memory allocation at the next line will then result in an integer overflow, resulting in a buffer overflow at line 217.

  216             *utf8 = g_malloc( len + 1 );
  217             memcpy( *utf8, &data[2], len );        /* data field */
  218             (*utf8)[len] = '\0';
  219
  220             return ( len + 2 );
  221         }    

Unlike libc's memory allocator, gmalloc returns NULL when it is called with a size of zero. As a result of that behavior, this ends up being a a write to the NULL page rather than the typical heap overflow. Writes to the zero page are exploitable if an attacker can cause enough allocations and exhaust enough of the memory address range to make the system map the low page.

VRT-2013-1001 (CVE-2013-6487): Buffer overflow in Gadu-Gadu HTTP parsing

vrt rules - Tue, 01/28/2014 - 16:30
Sourcefire Vulnerability Report VRT-2013-1001 (CVE-2013-6487): Buffer overflow in Gadu-Gadu HTTP parsing DescriptionAn exploitable remote code execution vulnerability exists in Pidgin's implementation of the Gadu Gadu protocol in the libpurple library. An attacker who can control the Content-Length of a HTTP request can cause an undersized allocation which can later be used to overflow into the heap. An attack requires the ability to spoof messages from the gadu-gadu.pl domain to exploit this vulnerability.
Tested VersionsPidgin 2.10.7
CoveragePrior coverage through an http_inspect alert GID 120, SID 8 as well as SID 2580.
DetailsIn gg_http_watch_fd() in file pidgin-2.10.7\libpurple\protocols\gg\lib\http.c at line 353 content-length will be read from the HTTP server:

  353     while (line) {
  354         if (!strncasecmp(line, "Content-length: ", 16)) {
  355             h->body_size = atoi(line + 16);
  356         }
  357         line = strchr(line, '\n');
  358         if (line)
  359             line++;
  360     }

It then checks if h->bodysize is less than or equal to 0, however h->body_size is an unsigned integer so a negative value will return a large positive size, meaning the check for less than zero will never be true:

  362     if (h->body_size <= 0) {
  363         gg_debug(GG_DEBUG_MISC, "=> http, content-length not found\n");
  364         h->body_size = left;
  365     }

This check will also pass because left will not be larger than a negative body_size:

  367     if (left > h->body_size) {
  368         gg_debug(GG_DEBUG_MISC, "=> http, oversized reply (%d bytes needed, %d bytes left)\n", h->body_size, left);
  369         h->body_size = left;
  370     }

if h->body_size is 4294967295 (or -1) then the below will result in a malloc(0):

  374     if (!(h->body = malloc(h->body_size + 1))) {

Finally we reach our out of bounds write into the heap here:

  381     if (left) {
  382         memcpy(h->body, tmp + sep_len, left);
  383         h->body_done = left;
  384     }

The client will keep copying data as long as there's data in the http response body and will then free the original heap chunk.

DDoS Gone...

Emergingthreats - Wed, 11/03/2010 - 13:44

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 

Daily Update Summary 10/31/2010

Emergingthreats - Sun, 10/31/2010 - 22:12
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.

The Emerging Threats Update Summary

Emergingthreats - Sat, 10/30/2010 - 00:16

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

New Platforms Available!

Emergingthreats - Fri, 10/29/2010 - 22:39

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 

The New Rulesets are Ready!!!!

Emergingthreats - Sat, 10/09/2010 - 17:36

 

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!!

 

Emerging Threats Sells Out!!

Emergingthreats - Mon, 09/27/2010 - 15:07

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. 

NVIDIA Partners with the OISF

Emergingthreats - Thu, 09/09/2010 - 14:41

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!