Tuesday, December 10, 2013

Microsoft Update Tuesday: December 2013, some 0-day fixes

Microsoft’s final update for the year brings us 11 bulletins covering 24 CVE issues.

As is customary, there is the critical IE bulletin, MS13-097. This time it covers 7 CVE issues.  As in other months, this includes a number of use-after-free issues that we’ve come to expect in IE. However this month we also get 2 escalation of privilege vulnerabilities (CVE-2013-5045 and CVE-2013-5046), where an attacker could break out of the low integrity sandbox. This assumes of course that the attacker has first gained remote code execution through another vulnerability and then uses one of these vulnerabilities to execute arbitrary programs.

There is also a critical update for GDI+, MS13-096. This one fixes the 0-day vulnerability (CVE-2013-3906) that is being exploited in the wild. The vulnerability exists in the way that TIFF files are handled. To trigger the vulnerability, current exploits embed a malicious TIFF file into a Word file, which triggers an integer overflow in the GDI+ library. Of course, any application which uses GDI+ to display TIFF files is vulnerable to this attack.

The next vulnerability (CVE-2013-3900) exists in the way that signatures are verified in executables. It is classified as remote code execution. However to exploit the vulnerability, user cooperation is required: the user was already planning to execute the file, but it could have been modified by an attacker, even though the signatures has remained intact. MS13-098 changes the way that signatures are handled to prevent this type of attack. A more in-depth description is available on Microsoft's SRD blog.

MS13-099 covers a use-after-free vulnerability (CVE-2013-5056) in Microsoft’s Scripting Runtime Object Library, which could lead to remote code execution. While the vulnerability is in the scripting runtime, it can also be triggered through IE.

Our last critical bulletin for 2013 is MS13-105, where vulnerabilities in Oracle’s Outside In (CVE-2013-5763 and CVE-2013-5791) could allow for remote code execution in Exchange. This update provides downstream patches for the fixes that Oracle has released to address these issues. The bulletin also covers 2 more vulnerabilities though:
  • A new fix for CVE-2013-1330, which was already addressed in MS13-067. The vulnerability allows an attacker to potentially execute remote code by passing in a malicious serialized viewstate (which is used to save state in a webpage), when message authentication code (MAC) checking for viewstates is disabled.
  • A cross-site-scripting vulnerability in Office Web Applications (CVE-2013-5072)
There are also 6 more bulletins marked as important:

MS13-100, which covers 1 vulnerability (CVE-2013-5059) in Sharepoint, where an authenticated user could gain remote code execution on a SharePoint Server.

The next bulletin, MS13-101, is for Windows Kernel Mode Drivers and provides an update for 5 CVE issues that could allow an attacker to gain an escalation in privileges using various vulnerabilities, including integer overflows and a use-after-free in Win32k, another issue with TrueType font parsing and another double fetch vulnerability. What’s important to note is that this update does NOT address CVE-2013-5065, the 0-day vulnerability that is being exploited in the wild in tandem with the previously discovered (and patched) Adobe Reader vulnerability (CVE-2013-3346). This issue will be fixed in a future update.

There’s also an update (MS13-102) that fixes a buffer overflow (CVE-2013-3878) in Windows Local RPC that could allow escalation of privileges. Followed by a bulletin (MS13-103) for ASP.NET, where an XSS vulnerability exists in its SignalR library.

Finally there’s 2 bulletins that deal with Microsoft Office and cover 1 CVE each:
  •  MS13-104, which provides a fix for an information disclosure vulnerability in Office 365 (CVE-2013-5054) that is currently being exploited in phishing attacks. This vulnerability allows an attacker to retrieve a user’s authentication token for Office 365 by sending a malicious link.
  •   MS13-106 provides a fix for an ASLR bypass that is commonly performed via HXDS.dll (CVE-2013-5057), because it hasn't been compiled with DYNAMICBASE (i.e., no ASLR support). Microsoft has a blog post describing the fix here

The VRT has rules SID 27823, 28464-28473, 28487-28488, 28525-28526, 28862-28863, 28865-28878, 28880-28882 to address these issues.

Monday, December 9, 2013

When an exploit kit is VERY simple

Ran across this "exploit kit" today.  I'm holding up my hands with air quotes:

Not really sure if it is an exploit kit, as so far, it is just a landing page with applet redirection to a jar file.

The GoogleDocs.jar file that is mentioned above is a simple generated jar exploit straight out of Metasploit with no obfuscation.

In fact there is no obfuscated landing page, no javascript, no tricky redirection.  Just... that.

ClamAV already detects this with Java.Trojan.Agent-31.  Just a Java archive with an embedded executable.

Tuesday, December 3, 2013

A quick tutorial on ClamAV detection: Win.Adware.Bprotector

Bprotector is a fairly popular yet unexceptional family of adware. The thing that distinguishes it from other families is its prevalence. A specific sample, first seen in October 2013, has consistently been on top for detection rates on our FireAMP and Immunet products. The following is the simple strategy that I used for creating the ClamAV signature.

For ClamAV coverage I targeted strings that were shared commonly between the samples that I had on hand. The goal is always to choose content that is generic enough to cover variants but unique enough to not false positive. Targeting the strings is extremely effective in this case because these samples are not obfuscated. This detection, based off of 4 samples, ended up covering more than 90.

The LDB signature can be seen here:


Decoded with sigtool --decode-sigs:

VIRUS NAME: Win.Adware.BProtector
TDB: Engine:51-255,Target:1

For the obligatory MD5 dump, here are the majority of samples that the signature alerted on:


Friday, November 22, 2013

I'm calling this Goon Exploit Kit, for now

We started seeing this exploit kit in our systems on November 21st.  It has some similarities to Redkit and the Dotcache exploit kit.

Cookiebomb redirection to: 1044 80 GET /cnt.php?id=786629 Mozilla/4.0 (compatible; MSIE 8.0; Windows NT 5.1; Trident/4.0; .NET CLR 2.0.50727; .NET CLR 3.0.04506.648; .NET CLR 3.5.21022) 80 1044 301 text/html

Which bounces you over to:

Landing: 1046 80 GET vinnypedulla.com /2013/11/11/21/2013/downloader.php?page_seed=xhtml Mozilla/4.0 (compatible; MSIE 8.0; Windows NT 5.1; Trident/4.0; .NET CLR 2.0.50727; .NET CLR 3.0.04506.648; .NET CLR 3.5.21022) 80 1046 200 text/html

This is the JNLP bypass in an xml. 1048 80 GET vinnypedulla.com /5/201311/browser.xml Mozilla/4.0 (Windows XP 5.1) Java/1.6.0_16 80 1048 200 text/xml

Cve: 2012-0507 1048 80 GET application/x-java-archive vinnypedulla.com /5/201311/browser.jar Mozilla/4.0 (Windows XP 5.1) Java/1.6.0_16 80 1048 200 application/java-archive

Payload 1049 80 GET vinnypedulla.com /5/201311/014146.mp3 Java/1.6.0_16 80 1049 404 text/html

At the time of this investigation, the Payload 404'ed.

I'll update this blog post as more information becomes available.

Update:  After further research, it appears the structure for the URLs doing the download of the jar and jnlp files is dynamic in some way.  However, we are seeing this exploit kit now drop a XOR'd binary of Zeroaccess.  Please ensure you have VRT rule 26524 enabled, as that will detect the JWS bypass section of this exploit kit. If in IPS mode, it should stop this kit from working.  

Update-2: Added some clarification around the Cookiebomb bump.  Detected 60 installs of this yesterday.

Tuesday, November 12, 2013

Microsoft Update Tuesday November 2013: HyperV vulnerability and fix for 0day

We have a relatively light Update Tuesday this month: 8 bulletins covering 19 CVEs, 3 of which are marked critical. The most interesting vulnerability this month is actually in the non-critical ones: a vulnerability in Hyper-V (MS13-092). We’re also getting a fix for a 0-day vulnerability in ActiveX (MS13-090).

As always there’s the requisite critical IE bulletin (MS13-088), this time covering ten CVEs. The vulnerabilities span the range of IE releases from 6-11 and cover the usual suspects of use-after-free and information disclosure vulnerabilities.

The next critical bulletin (MS13-089) is for the Windows Graphical Device Interface (GDI), where a malicious embedded BMP can result in remote code execution (CVE-2013-3940). The likely attack vector for this vulnerability would be a WordPad file with the BMP embedded, which will cause a buffer overflow when opened.

MS13-090, the final critical bulletin, provides a fix for a 0-day vulnerability (CVE-2013-3918) that’s seeing limited exploitation in the wild.  The vulnerability exists in the “InformationCardSigninHelper” ActiveX control, where an out of bounds access can occur on a deleted array, potentially allowing an attacker to execute arbitrary code. Microsoft has a short discussion on this vulnerability and a second information disclosure vulnerability in a blog post.

There are three vulnerabilities in Office (MS13-091), related to the handling of WordPerfect documents that can result in remote code execution when exploited. The vulnerabilities result in stack-based buffer overflows when Word tries to convert WordPerfect documents containing an invalid number of CSTYL elements.

The next bulletin (MS13-092) covers a vulnerability (CVE-2013-3898) in Hyper-V, Microsoft’s hypervisor. The vulnerability can result in an escalation of privilege because it can allow an attacker to run code from one virtual machine in the context of another. A failed attack can result in a denial of service.

An information disclosure vulnerability (CVE-2013-3887) exists in the Windows Ancillary Function Driver (MS13-093), where an attacker could use a guest account to run a malicious binary that would disclose information from other accounts.

Outlook (MS13-094) has an interesting information disclosure vulnerability (CVE-2013-3905), where an attacker can send a user an S/MIME email that will send back information on the internal network back to the attacker when the email is parsed by Outlook.

MS13-095 covers a single vulnerability (CVE-2013-3869) when parsing XML digital signatures in .NET.  This occurs when passing in a malicious PFX file as X509 certificate, causing a denial of service.

We are releasing rules SID 28489-28492, 28494-28524 to address these issues.

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 php.net hack took place (read about some of it here), in which an embedded iframe was inserted onto php.net, 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)

Crypt.am (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.

Thursday, September 26, 2013

Delivering an executable without an executable

The VRT looks at a massive amount of exploit kits a day, but this one caught our eye so we thought we'd share.  While this technique isn't new, it is very interesting and further illustrates what we all believe to be true in the security world, you can't trust anything.

With any exploit kit, the end goal is to drop malware on the victim host but unlike the majority of exploit kits we see, this one does it in a unique manner.  Instead of exploiting the victim through Java, Adobe Reader, or the browser, and using that foothold to fetch and run and executable; this attacker uses VBScript to write the executable to disk.  The end result is an executable on the victim machine without using an exploit to download the executable.

The link is still active at this time and is still serving malware.
VirusTotal results


Let's take a look at the VBScript.  First it declares the variable "DropFileName" with the string "svchost.exe". That's a nice descriptive variable name and it's not obfuscated. The next variable is "WriteData" and is a relatively large string.

Take a look at those first four characters: "4D5A" (in hex) or "MZ" (in ascii), the first two characters of an everyday Portable Executable or PE file.  Finally, another string is assembled called "DropPath". It uses the GetSpecialFolder method with a folderspec argument of 2, this holds the value of the "TMP" environment variable.  The file is created with CreateTextFile with the overwrite argument set to true.  The "WriteData" is then written out in hex and executed without an actual executable being downloaded or an exploit being used.

I tested this on Windows XP with IE 8 and Windows 7 IE 9. The user is presented with a warning on both systems. The name and publisher information presented in the warning shows that the add-on that was blocked is from Microsoft.  Any unsuspecting user may just click "Allow" on these.

The XP IE 8 and Win7 IE 9 warnings:

The malware itself is detected as Win.Trojan.Ircnite-27 with ClamAV and additional rules will be released to cover this method of executable delivery in the form of SIDs 28053 and 28054.

We are always interested in hearing about new and interesting methods used by attackers, so feel free to drop us a line if you'd like to share what you are seeing at:  research@sourcefire.com.

Thursday, September 12, 2013

Inquiring Minds: Exploratory road trips, malware, and cool tools and services

While browsing interesting sandbox reports, we here in the VRT uncovered a sample that dropped three files.  VirusTotal had no record of two of them, and the third was a DLL that was well covered.

The original sample from the report was MD5 7f431295bd212b9ec45241457bee58c9, which dropped these files:
  • MD5 216a5052900d40fee35763088bdfc88f    : C:\Windows\Tasks\wopqhhb.job
  • MD5 58a6e4f3375907295bb1070e9dac839c  : C:\Documents and Settings\All Users\Application Data\Mozilla\gtbcolk.exe
  • MD5 1f3a4ac5aafe5b4db0b72d1026615827  : C:\Documents and Settings\All Users\Application Data\Mozilla\vzsleki.dll

I had been wanting to test out some tools and ideas/approaches for investigating malware, so I packed up for a trip down exploratory lane.  The first two stops on the trip:

  1. Original sample from the report: 7f431295bd212b9ec45241457bee58c9
  2. The executable it dropped: 58a6e4f3375907295bb1070e9dac839c

I've got to PE

First, I compared the PE sections (using pedump) from both the original and the dropped PE executables and noticed they were the same:

  $ pedump --sections 7f431295bd212b9ec45241457bee58c9.exe

   === SECTIONS ===


    .text        1000     1110     1200      400     0        0     0        0  60300020  R-X CODE
    .data        3000    1e7f6    1ea00     1600     0        0     0        0  c0300040  RW- IDATA
    .bss        22000        c        0        0     0        0     0        0  c0300080  RW- UDATA
    .edata      23000       36      200    20000     0        0     0        0  40300040  R-- IDATA
    .idata      24000      48c      600    20200     0        0     0        0  c0300040  RW- IDATA

   $ pedump --sections 58a6e4f3375907295bb1070e9dac839c.exe

   === SECTIONS ===


    .text        1000     1110     1200      400     0        0     0        0  60300020  R-X CODE
    .data        3000    1e7f6    1ea00     1600     0        0     0        0  c0300040  RW- IDATA
    .bss        22000        c        0        0     0        0     0        0  c0300080  RW- UDATA
    .edata      23000       36      200    20000     0        0     0        0  40300040  R-- IDATA
    .idata      24000      48c      600    20200     0        0     0        0  c0300040  RW- IDATA

On a whim, I decided to compare the SHA1 sum of a full run of pedump on each sample.  This output includes:

  • MZ Header
  • PE Header

As you can see, the output from these two different samples were exactly the same:

$ pedump 7f431295bd212b9ec45241457bee58c9.exe | shasum
7d32da086a656917ab923604e7f4724fe131359d  -
$ pedump 58a6e4f3375907295bb1070e9dac839c.exe | shasum
7d32da086a656917ab923604e7f4724fe131359d  -

From there I decided to look at the exports:

  $ pedump -E 7f431295bd212b9ec45241457bee58c9.exe 58a6e4f3375907295bb1070e9dac839c.exe
  # -----------------------------------------------
  # 7f431295bd212b9ec45241457bee58c9.exe
  # -----------------------------------------------

  === EXPORTS ===

  # module "kgufcbuni.exe"
  # flags=0x0  ts="2013-05-19 21:19:52"  version=0.0  ord_base=1
  # nFuncs=0  nNames=0

  # -----------------------------------------------
  # 58a6e4f3375907295bb1070e9dac839c.exe
  # -----------------------------------------------

  === EXPORTS ===

  # module "kgufcbuni.exe"
  # flags=0x0  ts="2013-05-19 21:19:52"  version=0.0  ord_base=1
  # nFuncs=0  nNames=0

Now this got me wondering how similar the original sample and the dropped EXE were, so I fired up vbindiff to take a look:

It seemed the only difference was the dropped EXE had an extra 8 bytes at the end of the file.  So, to confirm this, I copied the first 235,376 (0x039770) bytes of the file and checked the MD5.

Sure enough, stripping off the last 8 bytes resulted in the MD5 of the dropped sample (58a6e4f3375907295bb1070e9dac839c) and the original sample (7f431295bd212b9ec45241457bee58c9) to match up:

$ dd if=58a6e4f3375907295bb1070e9dac839c.exe bs=1 count=0x039770 2> /dev/null | md5

We have a winner?  No, but I'm searching for dinner.

Now I'm interested, in a cat-with-a-laser-pointer kind of way, but I need more samples.  This was a perfect opportunity to try out some VirusTotal Intelligence searches to find some more samples to play with.

I decided to try two different approaches:
  1. PE section searching
  2. "Similar to" searching

PE section search

For the PE section searching, I got all of the PE section MD5s for the original sample and attempted a search for samples that had these same sections:

(sectionmd5:4f5944620a6fff416596982b2e6dec23 sectionmd5:d1c09bc7d834711d74aaf05770ba22cb sectionmd5:d41d8cd98f00b204e9800998ecf8427e sectionmd5:963a67c9ee55335c1fe3ee1322167430 sectionmd5:a1bbc87f2207a3aff4a78e65d64981b5) type:peexe 

As I held my breath, I tested the first sample returned, d5ccc595265f7706824b33c4729f3a9e.
$ pedump -E d5ccc595265f7706824b33c4729f3a9e 
=== EXPORTS === 
# module "kgufcbuni.exe"
# flags=0x0 ts="2013-05-19 21:19:52" version=0.0 ord_base=1
# nFuncs=0 nNames=0

IT'S A BINGO!  Sweet, we had an obvious match, so I downloaded the first 300 samples the PE section search gave me.

"Similar to" search

Because my two samples had no entries on VirusTotal, I used the first sample uncovered with the PE section search as the basis for my similar-to search:
I grabbed the second sample (8e9fe8499a2d7acaf1124ed20b101aee) because the first sample was the sample I used for my search.  So, I was confident that the similar-to search feature was good enough to search for itself, but I wasn't actually holding my breath on this one.

So, without expecting too much, I checked the exports of the selected sample:
$ pedump -E 8e9fe8499a2d7acaf1124ed20b101aee 
=== EXPORTS === 
# module "kgufcbuni.exe"
# flags=0x0 ts="2013-05-19 21:19:52" version=0.0 ord_base=1
# nFuncs=0 nNames=0

Two bingos in one day?  I'm putting on a wig and going to a blue hair convention bingo tournament.  After that, I downloaded the first 300 samples the search results gave me.

Merge all the things!

Each of the two VirusTotal intelligence searches left me with 300 samples each; that's 601 total samples.  I then merged all of those samples into a directory so any overlapping samples would be removed.

The merge then left me with 491 unique samples, all with different SHA256 checksums.  These are the poor samples that were the unwilling patients that I poked, prodded, and probed.

Probe all the things?!

First I was curious what the pedump output for all of the samples looked like.  Were they all the same?  Were they all different?  Was the price of tea in China impacted?  Inquiring minds want to know.
$ for sample in *; do pedump $sample | shasum; done | sort | uniq -c | sort -n
  12  8f153c3902471bfc4935d49064b371bfcbb6d79a -
479 7d32da086a656917ab923604e7f4724fe131359d -

It's a landslide victory!  7d32da086a656917ab923604e7f4724fe131359d has it by 467 votes!  I wondered about the exports, so that was next:
$ for sample in *; do pedump -E $sample | grep module; done | sort | uniq -c | sort -n
 491 # module "kgufcbuni.exe"

Let's go deep, ssdeep.

Even though we were working with 491 unique samples, there have been a lot of similarities (or exact matches).  This got me wondering about how useful ssdeep might be in this particular situation.

So, I used ssdeep on the original sample and the exe it dropped.  The ssdeep hashes seem to be identical for a single byte:

  $ ssdeep -b 7f431295bd212b9ec45241457bee58c9.exe | tee 7f431295bd212b9ec45241457bee58c9.ssd

  $ ssdeep -b 58a6e4f3375907295bb1070e9dac839c.exe | tee 58a6e4f3375907295bb1070e9dac839c.ssd

Then I ran the ssdeep hashes against all 491 samples.  This resulted in a 488/491 detection:

  $ ssdeep -m 7f431295bd212b9ec45241457bee58c9.ssd -br intelligencefiles/merged/ | wc -l

  $ ssdeep -m 58a6e4f3375907295bb1070e9dac839c.ssd -br intelligencefiles/merged/ | wc -l

If I added the -a option (shows all matches even if the score is 0), and all 491 were matched:

  $ ssdeep -a -m 7f431295bd212b9ec45241457bee58c9.ssd -br intelligencefiles/merged/ | wc -l
  $ ssdeep -a -m 58a6e4f3375907295bb1070e9dac839c.ssd -br intelligencefiles/merged/ | wc -l

A dream within a dream?  We need to go deeper Yara.

I wondered, what else I could do with these 491 samples?  I landed on extracting binary patterns from the samples and trying to do something cool with them using Yara.

Thankfully, all of the heavy lifting had already been done for me, so I went to work and copied 28 semi-randomly selected samples to a directory called yara-autosig-samples/.

Using the autorule Python script, I generated the Yara signature from the 28 samples:

  $ python autorule/tester.py yara-autosig-samples/ > yara-autosig.yar
  CFileDiffer: Diffing a total of 30 file(s)
  CFileDiffer: Diffing file 1 out of 30
  CFileDiffer: Diffing file 2 out of 30
  CFileDiffer: Diffing file 29 out of 30
  CFileDiffer: Diffing file 30 out of 30

Lo and behold, Yara detected all 491 samples:

  $ yara -r yara-autosig.yar intelligencefiles/merged > yara-autosig.log

  $ wc -l yara-autosig.log
  491 yara-autosig.log

  $ head -1 yara-autosig.log
  test   intelligencefiles/merged/0034d872dca89c5b05b4eb4cca532a470473fbd793ab52fb745e4d69a5577516

  $ tail -1 yara-autosig.log
  test intelligencefiles/merged/fcedaf314f26112aaba5e255cfa8235209521a77cb570e02ed4b16c37c137775

Back to the future?

So, after all of that I decided to look at the exports again and see if the location of "kgufcbuni.exe" was static:

  $ grep -aob kgufcbuni.exe intelligencefiles/merged/* | cut -f2- -d: | uniq -c | sort -n
   491 131112:kgufcbuni.exe

These samples all seem to drop the same DLL (1f3a4ac5aafe5b4db0b72d1026615827), so I decided to look at the exports for the offset of "ckdhgsuwa.dll":

  $ grep -aob ckdhgsuwa.dll 1f3a4ac5aafe5b4db0b72d1026615827.dll

Now that I was armed with these offsets, I decided to test my theory with a simple ClamAV LDB signature:

  $ cat local.ldb

Which decoded looks like this:

  $ cat local.ldb | sigtool --decode
  VIRUS NAME: Win.Trojan.Kryptik
  TDB: Engine:51-255,Target:1
   * SUBSIG ID 0
   +-> OFFSET: 17458
   * SUBSIG ID 1
   +-> OFFSET: 131112

For those of you who haven't gouged your eyeballs out, or taken up underwater basket weaving, here are the results of our LDB signature scan:

  $ clamscan -rid local.ldb 7f431295bd212b9ec45241457bee58c9   58a6e4f3375907295bb1070e9dac839c 1f3a4ac5aafe5b4db0b72d1026615827 intelligencefiles/merged/ | tail -10

  ----------- SCAN SUMMARY -----------
  Known viruses: 1
  Engine version: 0.97.8
  Scanned directories: 1
  Scanned files: 494
  Infected files: 494
  Data scanned: 97.44 MB
  Data read: 97.43 MB (ratio 1.00:1)
  Time: 2.549 sec (0 m 2 s)

So, there you have it.  A little bit of exploration and tinkering and who knows what you might uncover?

Thursday, August 22, 2013

Bytecode - Covering the Android Vulnerabilities Master Key and Extra Field

This post will walk through our coverage for the Master Key and Extra Field vulnerabilities. Both vulnerabilities allow arbitrary files to be added to signed APKs without breaking the digital signature. ClamAV bytecode signatures allow for flexible coverage when a vulnerability or malware family is too complex to detect with any of the other signature formats. The bytecode signature language is a subset of C with an API for interfacing with ClamAV.

The vulnerabilities have been written about exhaustively elsewhere online, the most comprehensive of which are from @saurik: Master Key and Extra Field.

Zip File Format

Zip files contain a central directory pointing to all of the files stored in the archive. The central directory is located at the end of the file. Each file stored within the Zip file has a header immediately before its stored bytes, as well, each file has a more verbose header stored in the central directory. You can see the specifics on Wikipedia.

Master Key Vulnerability

The Master Key vulnerability is exploited by having multiple files with the same name in an APK. Android's verifier and loader handle duplicate entries differently. The verifier will check only the last duplicate entry against the SHA1 digest stored in META-INF/MANIFEST.MF. The loader will load the first entry.

The fact that any file could be replaced is what led to the decision to use a bytecode signature to cover this vulnerability. The vulnerability creates a complex situation where the APK / Zip needs to be parsed and each file name checked against the others.

The bytecode signature first finds the last end_of_central_directory entry's file magic in the file. The end_of_central_directory section has information about the starting offset and size of the central_directory. This is the equivalent of scanning backward to find the end_of_central_directory entry.

        // find the last end_of_central_directory file magic
    while(end_central_dir_off != -1) {

        // keep track of the previous one
        last_end_off = end_central_dir_off;

        // seek past it
        if(seek(last_end_off+1, SEEK_SET) < 0)
            return 0;

        // keep doing this until the magic PK\x05\x06 is not found
        end_central_dir_off = file_find("\x50\x4b\x05\x06", 4);

    // set to the last one found
    end_central_dir_off = last_end_off;

After some seeks and reads the bytecode signature reaches the while loop for detecting duplicate file names. For security reasons there is no malloc in the ClamAV bytecode engine, because of this, an O(n2) comparison was used. There are two buffers used since each filename is tested against all those that follow it. Only when the file name lengths are equal are the names read in to their respective buffers. Then, the names are compared to each other looping backward in order to break as soon as possible on differences. This avoids iterating over similar paths. The read in and comparison can be seen below:

    // if the lengths are the same, do the comparison
    if(file_name_length == compare_name_length) {

        // seek to entry name
        if(seek(zip_entry_off + 46, SEEK_SET) < 0)
        // read name
        if(read(file_name_buffer, file_name_length) != file_name_length)
        // seek to the compare entry name
        if(seek(compare_entry_off + 46, SEEK_SET) < 0)
        // read name
        if(read(compare_buffer, file_name_length) != file_name_length)

        // compare names from end backward to avoid wasting time, ex:
        // /res/drawable-hdpi/btn_call_1.png
        // /res/drawable-hdpi/btn_call_2.png
        for(i=(file_name_length-1); i > -1; i--) {
            // if any character does not match, break
            if(file_name_buffer[i] != compare_buffer[i])
        // if reached the end of the loop (didn't break on any comparison)
        if(i == -1) {

Extra Field Vulnerability

The Extra Field vulnerability is exploited by a signed / unsigned handling error in the Android's verifier. A Zip file's central directory points to all of the files stored in the archive. Each file has a header which has extra space available, called the extra_field. The extra_field, when present, is between a file's header and the stored file. When its size is interpreted as a negative value, the verifier will try to skip past it to the file bytes by jumping backward. If you store the original file at the location the verifier jumps backward to, it will be verified. Then you can place some arbitrary file into the original file's position, causing the new file to be loaded.

The most popular way to exploit this is to store the classes.dex file uncompressed. Then the extra_field_length is set to 0xFFFD (65533 unsigned, -3 signed). This causes the original file's magic (example: dex\x0A035\x00) to overlap with the file name classes.dex. When the verifier jumps over the extra_field, it will jump backward 3 bytes into the file name, these bytes are shared with the start of the dex file. It will verify that the original dex file, which has been stored in the extra_field, is unchanged. When the loader goes to load the file, it will correctly treat the extra_field_length as unsigned short and jump forward to the new dex file.

I also realized that you could jump backward into another entry's extra_field. It would constrain your file sizes even more, but it would still be possible. Instead of only covering 0xFFFD, the bytecode was initially looking for any value that could be interpreted as negative in the dex entry's extra_field_length.

After reading @saurik's blog post on the Extra Field vulnerability I realized that this coverage needed to be expanded. My logic was, initially, that the file classes.dex (the executable code) was the only serious threat when replaced. In hindsight, this was a strange decision as I thought to cover any file for the Master Key vulnerability but only one file for Extra Field. There are a lot of files that could be dangerous when replaced.

The really mind blowing thing that @saurik demonstrated was an almost complete replacement of the central directory. The entries in the central directory also have an extra_field. When its size is large enough to be interpreted as negative, the verifier will instead interpret it as zero. The usage of this vulnerability in the central directory pivots off the first entry in order to split the paths of the verifier and the loader. Each is then just directed to every other file entry using valid, specially crafted extra_field and comment lengths. This allows a near total replacement of a signed application's contents. This paragraph by no means does this bug technical justice, if you are interested, I highly suggest you visit the post linked above.

What does all this mean for coverage? It means we should look at every file entry in the zip file, as well as every entry in the central directory. The safest way to reach every entry in a Zip file is by reading the central directory and getting the offset from there. For this reason, coverage has been integrated into the loop checking for the Master Key vulnerability.

    // get the offset of the file header for this central dir entry
    zip_entry_off = *(uint32_t *)&cd_header[42];
    zip_entry_off = le32_to_host(zip_entry_off);
    if(seek(zip_entry_off, SEEK_SET) < 0)

        return 0;
    if(read(zip_header, 30) != 30)
        return 0;
    // check the extra field size

    extra_field_size = *(uint16_t *)&zip_header[28];
    extra_field_size = le16_to_host(extra_field_size);
    if(extra_field_size > 0x7FFF)
    // go back to where we were previously
    if(seek(cd_entry_off + 46, SEEK_SET) < 0)
        return 0;
    // check extra field size for the central directory entry
    extra_field_size = *(uint16_t *)&cd_header[30];
    extra_field_size = le16_to_host(extra_field_size);
    if(extra_field_size > 0x7FFF)

Once the code has read in the central directory header to the variable cd_header, it then retrieves the offset of that file entry in the Zip file. It seeks to that location and reads in the local file header to the variable zip_header. It casts the extra_field_size safely using le16_to_host(). This function converts a 16bit little endian value to the equivalent in the host architecture's endianness. If the value is greater than 0x7FFF, that is, if it can be interpreted as a negative value, then we alert that the Extra Field vulnerability has been found. If not, we seek back to the central directory entry and do the same check for the negative extra_field value in the central directory.


Following are some examples of the two vulnerabilities on VirusTotal.

MD5: 04EEF623255A7CEBD943435ACF237456 - The first central directory entry at offset 0x7A5F4 has a negative extra_field value (0x8000). Alternate central directory entries have been inserted into that space.

MD5: C9F4C62521C04B8ADD796A1D5CEE08B0 - This sample was the first usage of the Extra Field vulnerability spotted in the wild. It was detailed in our blog post here. It is interesting to see the variety in names used by different vendors.

MD5: D816596A70A7117346A2DFB6F8850E39 - This example of the Master Key vulnerability triggers because the file /res/drawable-xhdpi/icon.png has been inserted twice. While this is not a malicious exploitation of the Master Key vulnerability, it demonstrates how thorough coverage needs to be for this vulnerability.

MD5: DAA9C49A4645CE109B1E36DC6233DB07 - For this Master Key sample, it looks like someone took an already malicious APK and added an extra classes.dex file and a second AndroidManifest.xml file.

Tuesday, August 13, 2013

Microsoft Update Tuesday August 2013: More font issues, some interesting DoSes

It's a pretty standard month for Update Tuesday this time around. There's a total of 8 bulletins, covering 23 CVE issues. This bulletin addresses the final 2 issues reported during CanSecWest's Pwn2Own.

As usual, there's the requisite IE bulletin (MS13-059), which covers 11 CVEs. This includes the 1 open IE Pwn2Own issue. The issues cover IE6-IE10 on all versions of Windows. All issues were privately reported to Microsoft, so they haven't been exploited in the wild yet. Several vulnerabilities are the result of a use-after-free, but there's also a stack-based buffer overflow when handling a specific font type (CVE-2013-3181).

This month we also have another font issue (MS13-060), this time in a Unicode font. The vulnerability is only present in XP SP3, XP Professional 64-bit and Windows Server 2003. It can be exploited by embedding a font in a document or a webpage.

There's also an update for Exchange (MS13-061), which is actually just a downstream Oracle Outside In update that Microsoft is applying. The issues were described in CVE-2013-2393, CVE-2012-3776 and CVE 2013-3781.

Bulletin MS13-062 covers an interesting vulnerability (CVE-2013-3175) in the handling of Remote Procedure Calls (RPC). The vulnerability can only be exploited post authentication though: an attacker needs an account and needs to log in before being able to exploit this vulnerability. As such, it's only a potential privilege escalation instead of remote compromise.

There are also a number of kernel vulnerabilities that are being fixed in bulletin MS13-063, affecting most supported Windows versions, including XP up to 8, and Server 2003 and 2008. This bulletin deals with 4 CVEs. Most vulnerabilities result in memory corruption that could allow an an escalation of privileges for the attacker (CVE-2013-3196, CVE-2013-3197, CVE-2013-3198). However, one of the issues being fixed is the final Pwn2Own issue that allowed VUPEN to bypass ASLR (CVE-2013-2556).

There are also 2 interesting denial of service vulnerabilities that are being addressed by MS13-064 and MS13-065. Both can result in a system crash and require a reboot when an attacker sends a maliciously crafted ICMP packet. The first vulnerability (CVE-2013-3182) occurs on servers with the Windows Nat Driver Service running (MS13-064). If the attacker sends a maliciously crafted ICMP packet that contains a truncated IPv6 header, this can cause read access violation, resulting in a system crash. The second vulnerability (CVE-2013-3183) is in the ICMPv6 implementation (MS13-065) and can also result in a system crash if an attacker send a maliciously crafted ICMPv6 Router Advertisement packet that contains an invalid prefix length field.

Finally MS13-066 deals with an information disclosure (CVE-2013-3185) in ADFS. The issue occurs when an attackers visits a specific URL associated with the ADFS service, resulting in a disclosure of account information.

We are releasing rules SID 27605-27616, 27618-27620 and 27624 to address these issues.

Tuesday, July 30, 2013

Android Extra Field Vulnerability Spotted in the Wild

It has been 20 days since the Extra Field vulnerability (also known as Chinese Master Keys) was first reported (translated link) by the Android Security Squad. It has now been spotted in the wild. The linked sample (MD5: C9F4C62521C04B8ADD796A1D5CEE08B0), which will be referred to as Arctic.apk, contains another APK named DoubleRainbow.apk (MD5: 1B14AD438375E6C25F645A855828D78F). DoubleRainbow.apk contains the Extra Field vulnerability. This APK is not malware. It is designed to root the Kobo Arc tablet.

A Brief Overview

The Extra Field vulnerability exists because of a signed / unsigned error when verifying the cryptographic signature of an APK's files. In a Zip file (APKs are Zip files) there is an entry Extra Field in each file's local header (see header structure here). When checking the signature of the file, the Extra Field Length is treated as a signed short. The verifier attempts to jump over the Extra Field to the file's bytes. When set to 0xFFFD (-3) the verifier will jump 3 bytes backward into the file name (classes.dex) which shares three bytes (dex) with the start of the Dex file. The loader treats the Extra Field length correctly, as an unsigned short. So the loader will jump forward, over the Extra Field, to load the file. If you place the original Dex file, overlapping the file name, into the Extra Field it will be verified. You may then place a different Dex file in  the original file's place. This injected Dex file (likely malicious) will be loaded and run without breaking the APK's signature.

The Sample

Checking the files inside of Arctic.apk, it is fairly obvious that it is up to something. Inside the /assets/ folder we see the following files:
The presence of Superuser.apk indicates that Arctic will likely be rooting the device. Artic is fairly simple, it installs and runs DoubleRainbow.apk, which was originally a system package for the Kobo Status Bar. Since it is a system package, it is granted elevated privileges on the device. The Extra Field exploit allowed the author to inject custom code to be run by this package. In order to match the size of the replaced classes.dex, the injected Dex file was padded out with a 2599 byte string, "LOLOLOL...". Once executed, the custom classes.dex executes wifiScript.sh, the contents of which can be seen here:
mount -o rw,remount /system
cat /data/data/com.android.innocomm.EngineerMode/su >/system/xbin/su
chmod 6755 /system/xbin/su
cat /data/data/com.android.innocomm.EngineerMode/Superuser.apk >/system/app/Superuser.apk
chmod 644 /system/app/Superuser.apk
pm uninstall com.kobo.statusbar
Since DoubleRainbow.apk is running in a privileged mode, all it needs to do is copy over su and Superuser.apk.


The APK was authored by @zhuowei and can be found on their Github. None of the source code was being returned by Google since it was posted so recently. The repository was found through the author's name on Arctic.apk's certificate. As we can see from the following, the Kobo Status Bar APK (DoubleRainbow.apk) still contains the certificate issued by Jason Gamblen from Kobo Inc.
Issuer: C=CA, ST=British Columbia, L=Vancouver, O=Unknown, OU=Unknown, CN=Zhuowei Zhang
Issuer: C=CA, ST=Ontario, L=Toronto, O=Kobo, OU=Android Team, CN=Android/emailAddress=jgamblen@kobobooks.com
While this APK is not malicious, it demonstrates how easy it is to gain root access using the Extra Field vulnerability. It is expected that this vulnerability and the Master Keys vulnerability will become common occurrences in Android malware.

Tuesday, July 16, 2013

Androrat - Android Remote Access Tool


Androrat is an appropriately named remote access tool (or RAT) for Android. In case you're unfamiliar, RATs provide backdoor functionality to an operator, giving access to your system and private data. Androrat recently fell into the spotlight thanks to this Webroot blog post that highlights a user-friendly Android trojan maker. According to the post, Androrat is the default malicious package provided with this software.

Androrat was the project of four university students from France. According to their README, it was completed in one month. It has since been removed from the Github account on which it was hosted, and for privacy reasons these students will not be named here.

A law enforcement agency provided us with a zip file that appears to be a dump of the Github repository. It contained two compiled debug versions of the Androrat APK, the source code for these, and some class files. Additionally, it contained all of the source code for the server as well as its dependencies.


To get the server running, I was able to simply drop all of the source files into an Eclipse project, add the dependencies, and fix up one import that didn't agree with my system. I was pleasantly surprised at how easy this was to get working.


To test that everything was working I ran the server from Eclipse and simply loaded up the debug APK. The debug APK conveniently allows the user to set the server's IP and port. Here we can see the debug apk and the server program:


Androrat covers the breadth of Android malware features. From the README:

    ### All the available functionalities are
    * Get contacts (and all theirs informations)
    * Get call logs
    * Get all messages
    * Location by GPS/Network
    * Monitoring received messages in live
    * Monitoring phone state in live (call received, call sent, call missed..)
    * Take a picture from the camera
    * Stream sound from microphone (or other sources..)
    * Streaming video (for activity based client only)
    * Do a toast
    * Send a text message
    * Give call
    * Open an URL in the default browser
    * Do vibrate the phone

After setting up a contact list, a few fake conversations, and a call log I went to test these out. A few of the functions gave errors, but most worked. As well, a few were not compatible with the Android emulator (for example, vibrate).


In the file inout/Protocol.java the request and response codes are listed. For requests the base number is 100, then a value ranging from 0 to 23 is added to it for the code. This is wrapped with the target channel (multiplexed) and arguments in CommandPacket. Then it is wrapped with other meta info in TransportPacket. The resulting packet data size for requests hovers around 21 bytes.

The APK gives an acknowledgment to requests received. The response message is packed into a custom packet via the following function call sequence (format: ClassName.function):
-> Client.sendInformation 
-> Connection.sendData 
-> Mux.send 
-> TransportPacket.build

This packet includes the acknowledgement data, total length, data length, the channel (multiplexed), as well as a short and bool for following the packet sequence.

The response codes have a base of 200 and add a value ranging from 0 to 15 to that base. Data being sent is generally built into an array or hash table, then the response is written using ObjectOutputStream.writeObject() and placed into a custom packet. The packet includes the type that was packed. For example, when dumping an SMS to the server, the object type java.util.ArrayList will be included in the packet to indicate what has been written. The fields used in these structures prior to packing are very verbose. As an example, PhoneNumber, SimOperator, and IMEI are used when dumping device information to the server.

The information is sent over TCP with this custom protocol. The default server port is 9999, however, this is configurable.


Since the source code was public, this project provides a significant starting point for new Android malware authors. However, it does not contain any root exploits, it does not attempt to obfuscate the code or communication, and it has not been refined to a point that I would call reliable.