Thursday, October 31, 2013

Exploit kits, they sure do like to change ports

Since the arrest of Paunch, (the author of the Blackhole and Cool exploit kits, that I talked about in my last post), exploit kits are clamoring for who will be number one.  So I come with a status update of sorts, as of the writing of this blog post, Magnitude, aka, Popads seems to be winning.

This particular kit received a bunch of press recently since the hack took place (read about some of it here), in which an embedded iframe was inserted onto, pointing people to an instance of the Magnitude/Popads exploit kit.

Magnitude/Popads shares many characteristics with other exploit kit's patterns. How Blackhole at one time performed downloads, how Nuclear throws certain exploits, how HiMan delivers the IE vulnerability... but one thing that Magnitude does, and quite often, is switch the ports it runs on.

Over the past week, we've seen Magnitude/Popads run over ports:

(In case you want to search your outbound proxy or firewall logs).

So, with that in mind, I give you this:

Monday, October 21, 2013

Sweet Orange Exploit Kit was the new king of the hill, until it went away.

Here in the VRT, we keep a pretty close eye on Exploit Kits, their trends, their pattern shifts, and how we can protect our customers against these exploit kits in the real world.

Recent headlines from various news agencies stated that the author of the Blackhole and Cool exploit kits, who goes by the nickname of "paunch" was arrested a couple weeks ago.  Several articles document a decline in the number of Blackhole and Cool exploit kits now being seen in the wild.  We were also observing this trend.

However, it was a decline, not a complete falloff.  (So remain vigilant) (the site used to encrypt the Blackhole exploit kit) is now completely offline, and that's pretty telling.  The exploits included in the Blackhole kit are about a week and a half old at this point.  (They shifted faster prior to the arrest).   The last date we observed significantly high numbers was on the 9th of October, since then Blackhole prevalence has declined to almost zero.  We've seen Blackhole in the wild since, but as I said before, with older content.

Exploit kits such as Neutrino, Styx, and Nuclear's detection rate has stayed about the same, X2O looks like it has a spurt of activity periodically, some exploit kits such as Fiesta and Whitehole barely make a dent in the numbers.

However, Sweet Orange increased drastically shortly after "Paunch"'s arrest. An increase of about 214%.  We observed the port that hosted the landing page and exploits move at least three times during its surge.  However, since October 17th or so, Sweet Orange has also disappeared.

Also, for some color, 98% of compromises were done through Java.  The other 2 percent are all other exploit methods (Adobe Reader, Flash, Browser, etc) combined, according to our desktop antivirus products FireAMP and Immunet.

Recommendation?  Turn off Java in the browser.  It's at least a start!

Tuesday, October 8, 2013

Microsoft Update Tuesday October 2013: Another IE 0-day release

This month's Microsoft Tuesday Update brings us 8 bulletins for a total of 26 CVEs. Four of these bulletins are marked as critical, while the rest are marked as important.

First, let's take a look at the 4 critical bulletins:

The most important update this month is a cumulative update for IE (MS13-080), which fixes 10 CVE issues, 2 of which have already been exploited by attackers. The first 0-day that's being fixed was widely reported and exploited (CVE-2013-3893). The second one (CVE-2013-3897) was also exploited on the web, but in a more targeted manner. We have a blog post concerning this vulnerability here.  Most of the issues fixed in this bulletin are the result of use-after-free vulnerabilities.

The second bulletin (MS13-081) covers Windows Kernel Mode Drivers. One particularly interesting vulnerability (CVE-2013-3200) this month is in the way that Windows parses USB descriptors, resulting in a vulnerability that could allow an attacker to gain code execution at system level by simply inserting a USB key in a machine.

The next bulletin (MS13-082) shares a CVE (CVE-2013-3128) with MS13-081 and is the result of an issue with handling OpenType fonts, which could allow an attacker to not only gain remote code execution by embedding a malicious font in a webpage, it can also result in system level code execution, because the vulnerability also exists in the way kernel mode drivers handle these fonts.

The final critical bulletin (MS13-083) is for the ComCtl32 library and is the result of an integer overflow (CVE-2013-3195) when calling the library function. This could allow an attacker to execute remote code by exploiting an application that calls this library function.

Now for the important bulletins:

MS13-084 which addresses SharePoint and MS13-085 which addresses Excel also share 1 CVE (CVE-2013-3889), where an attacker can gain remote code execution by passing in a malicious office document.

The bulletins each also have 1 vulnerability each that they do not share. The separate Excel vulnerability (CVE-2013-3890) is similar to CVE-2013-3889. The second SharePoint vulnerability (CVE-2013-3895) however is a reflective XSS. An attacker may be able to perform a XSS on POST data that is not filtered before it is returned to the user.

Word has a bulletin (MS13-086) that covers 2 CVEs. One of these (CVE-2013-3891) is particularly interesting because it's the result of a stack-based buffer overflow. The buffer overflow can be triggered by an attacker by specifying a large macro as part of a malicious Word document, potentially resulting in remote code execution.

Finally, the last bulletin (MS13-087) covers an information disclosure vulnerability (CVE-2013-3896) in Silverlight, where an attacker might be able to perform a buffer overread: reading past the bounds of an object. This information could then be used by an attacker to bypass ASLR when exploiting another vulnerability.

Rules SID 27943-27944, 28151, 28158-28163, 28191, 28202-28206 are being released to address these issues.

IE Zero Day CVE-2013-3897 -- You've been protected for more than a week.

A little over a week ago the VRT discovered a very interesting bit of javascript on a popular JS unpacker site. Several things immediately piqued our interest in this sample. First of all, we found multiple calls to Math.atan2() with curious parameters:

This is a popular technique used in debugging exploits.
A breakpoint can be set in the following way:

So that later on when the exploit is ran, windbg will print out the second parameter of Math.atan2 calls, in the case above "after gc". Further inspection of the sample revealed that it checks the systemLanguage of the browser and deactivates itself if it doesn't find MSIE 8.0 in the User-Agent combined with either "ko" or "ja" system languages:

We suspect that the "ko" or "js" language packs were intended targets for ROP exploitation. After a quick run with windbg attached we are greeted with a crash:

Below you can see the constructor for CDisplayPointer which creates a 0x48 byte HeapAlloc which is freed and the subsequently used:

The VRT maintains a working exploit for this vulnerability which leverages a ROP chain from hxds.dll (MS Help Data Services Module) which is installed with Microsoft Office. Even before a MS advisory appeared for this use-after-free vulnerability the VRT released coverage in the form of a TRUFFLE rule. TRUFFLE rules provide a way for the VRT to release cutting edge coverage without exposing threats to the public through a plaintext rule. The SIDs for the TRUFFLE rules covering this vuln were 28091 & 28092. Now that the information is public our customers can find coverage for this vulnerability in SIDs 28207 & 28208.

Wednesday, October 2, 2013

Android Basic Block Signatures

Writing ClamAV signatures is a bit of an art. When matching bytes in a file, you need to make a selection that most, if not all of the malicious files will have, and hopefully, no clean files will have. Strings are an easy target. Often there are unique typos or a strange user-agent that you can match. However, when an application encrypts all of its strings you have to go looking elsewhere for bytes. The program's instructions are a great target for signatures.

In Android, the Java bytecode is contained in the file classes.dex. The code is just a series of instructions. The instruction unit is two bytes, so any instruction will be a multiple of two bytes. The first byte is the opcode which instructs the interpreter what to do. The rest of the bytes are additional information for each instruction. 

My initial idea for generating Android signatures was to take the bytes of a malicious function, parse the instructions and wild card any non-opcode byte, then use that for detection. There were some issues to this. The first is that, for obvious performance reasons, ClamAV doesn't parse signatures with only single byte content matches. Since the opcodes are single bytes, this causes clamscan to emit the error:

    Can't find a static subpattern of length 2

I worked with this while still pursuing this version of the idea. If you have one content match that is two bytes, you can then have other one byte content matches, like so:


This left a difficult decision. Which instruction should have the two byte match? While reviewing instructions, I noticed that the second byte stays mostly unchanged between different versions of the same function. This second byte is generally a register and the changes are often not significant enough to require the introduction of another register into the function. For this reason, I decided to keep the first two bytes of each instruction instead of just the opcodes. It would allow for stronger matching and detection was not significantly affected.

In testing, the functions changed a lot between versions of programs. Any code added to a function would break a signature. As well, signatures were pretty long. To get a finer granularity for selection, I parsed each function into its basic blocks. A basic block is a series of instructions that have only one entry point (the first instruction of the block) and one exit point (the last instruction of the block).

With each basic block, I saved the first two bytes of each instruction and changed the rest to wild cards. I can now take a set of related samples, parse their basic blocks out, push them into a database, and then query for blocks that are in the most samples. Once I have these blocks, I can string them together into a signature and cover a lot of samples only knowing which malicious class to select from.

That's the gist of basic block signatures. Android is a great test ground for a framework like this since Java bytecode is relatively simple to parse and the malware authors have not started employing dead code injection. This work also lays the foundation for control flow graph based signatures. This is an area of research I am pretty excited to look into.