Tuesday, September 18, 2012

Internet Explorer use-after-free 0-Day vulnerability

A new vulnerability has been discovered that affects Internet Explorer 6, 7, 8 and 9 on Windows XP, Vista, 7, Windows Server 2003 and 2008 . It is still unpatched at the time of this blog post.

Late Sunday Eric Romang reported that the Nitro cybercrimal gang, which just a few weeks ago was responsible  for a series of attacks that was taking advantage of  the "Java 0-day" (CVE-2012-4681) , was hosting some suspicious files on their servers. Upon further investigation, Eric found that running one of the said files led to code execution in the context of the logged in user on his fully patched Windows system.

Dr. Zulfikar Ramzan, Chief Scientist of Sourcefire's Cloud Technology Group, describes the recent Internet Explorer Zero Day vulnerability in this video:

The vulnerability is a "use-after-free" and exploiting it starts with the creation of an array with a large number of DOM objects:

In the public exploit (see screen shot above), a for loop is used to created a large number of image objects in the array. An image element is used in this case, but any type of object could have worked.

Later in the script, the use of the "selectall" execCommand is made to select all the DOM objects created, thus creating a reference to all the objects in the array. After all the objects have been selected, a function needs to rewrite the objects stored in the array to an address on the heap (could be obfuscated). The references are no longer properly resolved once the objects are rewritten, which allows for improper address dereference.

Snort rules 24210 and 24212 detect the execCommand use-after-free attempt. On the ClamAV side, the signature JS.Exploit.CVE_2012_4969.gen provides coverage.

As information related to this vulnerability is widely available, and given that a module has been released for the Metasploit framework,  we encourage users to use Microsoft's Enhanced Mitagation Experience Toolkit or even better, consider not using Internet Explorer (or applications that make use of Internet Explorer) on the affected platforms until a patch is released.

Late yesterday, Microsoft released a security advisory to address reports that attacks are being leveraged against this 0-day vulnerability.

Thursday, September 13, 2012

Using negative distance to create detection windows

A common method for delivering malicious pages to clients is with the use of hidden iframes. Before I get started I want to say that I have seen hidden iframes used legitimately and the rule discussed will not be in any policies by default, due to the risk of false positives.

The hidden iframe is typically created with something like this
<iframe width=1 height=1 style=visibility:hidden

This creates an iframe that the user doesn't see and loads whatever the attacker wants in the victim browser. HTML doesn't require that the parameters of the iframe be in any order so the example below produces identical behavior.

<iframe height=1 width=1 style=visibility:hidden

A rule could be written for each possible combination of the parameters, or a single rule could use PCRE to detect each combination, or ... distance and within can be used to create "windows" for each content match.

We know this will start with <iframe 

file_data; content:"<iframe "; nocase;

The remaining items can be in any order but the width, height and style parameters total up to 41 bytes. Next we look for the width parameter.

content:"width=1"; nocase; distance:0; within:50;

The next content match will look for height but we want to find it before or after width. The distance modifier can take a negative value to move the cursor back and within can be used to limit how far forward it searches.

content:"height=1"; nocase; distance:-40; within:80;
content:"style=visibility|3a|hidden"; nocase; distance:-40; within:80;

This combination of distance and within will find the height parameter 40 bytes before or after the width parameter. Then it will find the style parameter 40 bytes before or after the height. Since our entire string was 41 bytes this will detect the height, width and style parameters in any order. This is much less expensive than entering the PCRE engine, particularly since you'd need to check for all possible permutations of the three elements each time you entered. Worse yet, a PCRE rule to detect this would enter very often since there is not a unique string for fast_pattern to use.

The full rule looks like this:

 alert tcp $EXTERNAL_NET $HTTP_PORTS -> $HOME_NET any (msg:"INDICATOR-OBFUSCATION hidden iframe - potential include of malicious content"; flow:to_client, established; file_data; content:"<iframe "; nocase; content:"width=1"; nocase; distance:0; within:50; content:"height=1"; nocase; distance:-40; within:80; content:"style=visibility|3a|hidden"; nocase; distance:-40; within:80; classtype:bad-unknown;)

Like I said at the beginning of the post, I have seen hidden iframes used for legitimate things so this runs a risk of false-positive. It makes an excellent example of negative distance to create detection "windows".

Another, very important, note: if the negative distance moves the cursor further back than the beginning of the current buffer, Snort will stop evaluating the rule and there will be no alert. Using the above example, if the width parameter is only 10 bytes into the buffer the negative distance applied to the height parameter would move the cursor 30 bytes before the beginning of the buffer. Snort will stop evaluating the rule and no alert will be generated. While this is not a concern for this particular piece of detection - which is in today's SEU as SID 24168 - since standard HTML tags to start a page will ensure that an iframe will not fall within the first 40 bytes of any given page, it's worth keeping in mind if you're developing your own rules using this technique.

Dorifel (aka Quervar, XDocCrypt)

Dorifel (aka Quervar, XDocCrypt) is a worm that is allegedly related to the Citadel trojan. Although it's been found worldwide, the Netherlands have been particularly affected by this piece of malware for the past several weeks.

Why is this noteworthy? Once executed, Dorifel will search for all Microsoft Word documents on your system, including network shares. The Word documents found are encrypted using the following hexadecimal RC4 key:

0d 0a 05 0f 59 7b 38 5a 5b 36 31 69 7e 0d 0d 09

Moreover, the virus body is prepended to the encrypted document and the two are separated by the string:


The initial infector has references to the TV series "Breaking Bad" and the movie "Scarface", as seen below (both in plaintext in the first screenshot, and in ROT13 in the second):

We've had ClamAV coverage for this destructive piece of malware in ClamAV as WIN.Worm.Dorifel for the last couple of weeks. Snort SIDs 24144 and 24145 will detect the binary coming in over standard file delivery mechanisms such as HTTP/SMTP/etc., and SIDs 24143 and 24146 look for post-compromise behavior.

Wednesday, September 12, 2012

The Best Defense is a Good Defense

As things stand, Snort is at version and is constantly being developed to integrate new and more powerful features and detection. The VRT fairly regularly receives inquiries from folks on how to get our current rule packages to seamlessly integrate with their existing versions of Snort, which are beyond their end of life (EOL). These versions currently include anything older than Snort, as found here: http://www.snort.org/vrt/rules/eol_policy with set to ride off into the sunset on 2012-10-17. (http://blog.snort.org/2012/07/2921-eol-notice.html)

The Sourcefire VRT is focused on providing the best protection possible. In order to do this, we need to make sure that our open source users upgrade to the newest version of Snort and pay heed to the EOL schedules. Simply put, the newer features that have been added, as well as most of the rules developed to combat present day threats, will not work with older versions of Snort. This always leads us to recommend that you should perform a simple upgrade.

Remember, your Intrusion Prevention System (IPS) is not an archaic performance machine that can be nurtured and tweaked with aftermarket parts, WD40, and duct tape with the hope it’ll be the best it can be. Your IPS is meant to be the most advanced and up-to-date defensive technology you can put between you and the bad guys. Threats evolve every day. The VRT writes detection content as the Snort team writes code features, both of which evolve Snort to help you defeat these threats. Why would you not upgrade to the best possible chance of protection that your IPS is capable of providing?

Let us know if you need help by writing the Snort-users mailing list found below.


Monday, September 10, 2012

Anomaly Detection Rules & The Success of Open-Source Rule Testing: Don't Do That, Part 2

Last November, the VRT established an open-source rule testing group, composed of a number of Snort users from around the planet in industries as diverse as defense contracting and education. To date, we've tested well over a hundred rules with this group, and have had a great deal of useful feedback in the process - which has led to both killing rules that didn't perform as well as expected in the field, and the release of rules that we would have never previously dared to put in public after seeing them function well with the test group. I wanted to take a moment today to publicly thank the members of the group for all of their efforts, and to highlight some of the cool work that's come out of this project.

Rules worth highlighting include:

* SID 21941, "INDICATOR-COMPROMISE Wordpress Request for php file in fgallery directory". The fgallery plug-in for WordPress is a common target for remote file inclusion attacks; automated scanners are roving the Internet at this very moment looking for vulnerable installations. Since the directory the rule looks for in the URI should only ever have image files in it, looking for PHP files in that directory is a great generic indicator that a compromise has taken place.

* SIDs 21544-21546, "MALWARE-CNC Possible host infection - excessive DNS queries for .cn/.ru/.eu". We had observed several pieces of malware which cycled through a large number of domains on these TLDs in an attempt to find that day's algorithmically generated command and control location, and wanted to ensure that the rate at which we chose to alert on these queries was high enough to avoid problems in the field. These signatures have proven very useful as generic infection indicators since their release; we're happy to expand them to any other TLD where the false positive rate is low enough to be useful.

* SIDs 22033, 22034, "MALWARE-CNC Apple OSX Flashback malware outbound connection". The User-Agent strings used by the Flashback malware, while only one piece of the overall detection puzzle, were a perfect example of why this group was put together - they looked likely to cause false positives, but would be an ironclad indicator of infection if they were not standard slices of normal, in-field User-Agent strings.

* SID 21860 "EXPLOIT-KIT Phoenix exploit kit post-compromise behavior". This rule looks for a User-Agent string that appears perfectly normal, but for the inclusion of "Windows 98" (which we felt was likely to be exceptionally rare on networks protected by Snort, given the age of that operating system). Since we're continually surprised by the age of systems we're protecting, however, we wanted to check this before release.

* SIDs 23481, 23482 "INDICATOR-OBFUSCATION hex escaped characters in setTimeout/AddEventListener call". See this previous VRT post for details.

* SID 23621, "INDICATOR-OBFUSCATION known packer routine with secondary obfuscation". This rule takes advantage of the fact that one of the most widely-used JavaScript packers on the Internet (Dean Edwards' "function(p,a,c,k,e,d)" routine) gives the original names of the functions used in the code that's being obfuscated. Since certain calls such as fromCharCode(), charCodeAt(), parseInt(), and eval() are much more common in malicious JavaScript than normal JavaScript, the rule looks for three of them that were involved in an exploit kit observed in the wild by a Sourcefire customer.

* SID 23798, "MALWARE-OTHER Malvertising redirection page". A common technique for embedding malware on otherwise innocuous pages is to use hidden Iframes; this rule looks for these tags with height and width values of 0. Since we were uncertain as to the frequency of such elements in legitimate pages, testing this rule prior to release was crucial to ensure we didn't trigger an avalance of false positives.

* SIDs 23831, 23832, "WEB-CLIENT non-alphanumeric javascript detected". Put together in response to a new JavaScript obfuscation routine, these rules rely on strings which could have easily occurred in legitimate pages. Testing proved that our signatures were specific enough to catch only this encoding routine, and not legitimate activity.

* 24103-24110, "INDICATOR-COMPROMISE HTTP POST request to a JPG/JPEG/GIF/PNG/BMP/RAR/ZIP/MP3 file". This group of signatures detects HTTP POST transactions being sent towards files which generally do no process POST data. While our testing revealed some false positives, the rate was low enough that these rules were published anyway, outside of default policies an with appropriate documentation on how to check whether a hit was in fact a false positive.

* Several of our less-specifc signatures for the Blackhole exploit kit have either been released or put into the balanced policy after testing through this group revealed that they were free of false positives.

Current members of the group who have consented to being publicly named include:

* James Lay, Winco Foods

* Peter Bates, University College London

* Ralf Spennenberg, OpenSource Training

* Christian Teutenberg/Sandra Sucevic, Telstra

Thanks to them and the others whose management/policies have dictated keeping their contributions private. We wouldn't be as awesome as we are without you!

For those who may be interested in joining this group going forward, please drop me a line at akirk < at > sourcefire < dot > com. Also, if you missed out first "Don't Do That" rules post, it's worth a read, as it highlights several  anomaly detection rules that are still useful over two years later.

Tuesday, September 4, 2012

Matryoshka packets

I have heard many people talk about ICMP and UDP tunnels but very rarely observed them in the wild. We recently had the opportunity to examine a sample that uses this technique for C&C. It communicates by either an ICMP echo with a data section that includes a full TCP SYN packet, or a UDP packet destined for port 53 with a payload that also includes a full TCP SYN packet.

Both methods have a data section with an Ethernet frame, IP header, and TCP header. Many of the fields associated with these headers are fixed length and a few of them will remain fairly consistent across connections. Using these fixed lengths and consistent values we can start building a Snort rule that inspects the payload of these packets for a TCP SYN. The ICMP and UDP packets are also arranged so that the embedded packet in the payload starts at the same point.

The first header within the payload is the destination MAC, source MAC and type. The type will typically be IPv4 so the Snort rule will start there. The offset and depth combination make sure detection is at the correct position in the packet.

content:"|08 00 45|"; offset:12; depth:15;

The next reliable fields we look for are the IP fragment and offset. The distance and within will skip over a few more dynamic fields while ensuring it does not go beyond the fragment and offset fields.

content:"|00 00|"; distance:5; within:7;

The IP header also contains a type field, in this case the type is TCP.

content:"|06|"; distance:1; within:1;

Finally the acknowledgement number for an initial SYN will be null.

content:"|00 00 00 00|"; distance:18; within:22; 

This all results in SIDs 24087 and 24088, which will alert on each packet tunneled in this manner. ClamAV coverage can be found under the name Trojan.Win32.Bledoor.

Different methods of creating these tunnels might require an adjustment of the depth/offset on the first match but the rest are relative to the first match, though searching through the last several months worth of traffic from our malware sandbox showed no other samples using this type of technique. If you come across a tunnel similar to this, and want help creating detection for it, drop us a line at vrt < at > sourcefire < dot > com, and we'll be happy to help.