Friday, November 18, 2011

Malware Mythbusting

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.

Tuesday, November 8, 2011

Microsoft Security Advisory 2639658

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.

Thursday, November 3, 2011

Android Malware Analysis: A How-To

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.

Wednesday, November 2, 2011

Say Hello to the file-identify category

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.