Detections for MS Office Packaged CVE-2013-3906 Before 0-Day?

I know, you’re waiting anxiously to read the next part of the “Advanced Enterprise Detection Capabilities” mini series... This post is going to be a quick deviation (although somewhat related as the topic is about a specific detection capability) as timing is semi relevant. Don’t worry though, I will continue the exciting series after this quick post.

This post is going to be a quick and dirty “Did You Know” [you had detections for the MS Office XML format packaged TIFF exploit before the exploit ever left the authors mailbox]? Very few, if any, antivirus solutions (at least that I know of) had detections for the MS Office XML format (Office version 2007 and newer formatted files) packaged exploit. I have a couple of variants that were all ‘detected’ with this tool. So you ask, “How did I already have detections?” Well, there is this tool called OfficeMalScanner written by Frank Boldewin. This tool was initially written to parse MS Office OLE format (Office version 2003 and older formatted files) files to scan for malicious traces, like shellcode heuristics, PE files or embedded OLE streams. One of the lesser known or used capabilities of this tool is the signature detection capabilities of binary and PE files. So let's learn a little bit about it.

Below are the quick steps I went through that allowed me to detect or identify a file that (after additional in depth analysis) was malicious (realizing that AV software did not detect this file as malicious). It’s important to note that I am not going to analyze the shellcode or the exploit details, but instead, identify the detection that OfficeMalScanner alerted on with this file.

The file that we will analyze with OfficeMalScanner is a Microsoft Office XML (.docx) formatted document exploiting CVE-2013-3906. The filename is "IMEI.docx" with an MD5 hash of b44359628d7b03b68b41b4536314083.

The first command you run when looking at an MS Office file:

$ wine OfficeMalScanner.exe IMEI.docx scan

Next, lets inflate (unzip) the file:

$ wine OfficeMalScanner.exe IMEI.docx inflate

Notice that the tool identified at least 1 “.bin” file. Lets run the tool against this binary file (which in our case is in the activeX folder) by running the below command:

$ wine OfficeMalScanner.exe activex.bin scan brute

       

Notice that all of the found signatures start with “FS:[30] (Method 4) ...” This is a code signature that attempts to locate EIP (a technique that shellcode attempts to use to figure out the effective address when loaded into memory). OfficeMalScanner doesn’t detect the actual vulnerability that exists with the rendering of the TIFF file.  It actually detects the heap-spray shellcode embedded in the ActiveX file. So in a non-direct way, OfficeMalScanner would have identified this document as malicious.

A useful built in capability of OfficeMalScanner is that it provides a malicious index rating. This is based off of the types of detections that the tool alerted on. The higher the number, the higher probability that the file is malicious. I want you to realize that I am using this tool as a detection capability, not an analysis capability. The fact that the tool displays that the file seems to be malicious should be identified as an “indicator” that the file “could” be malicious. When an index threshold is met (you need to do some testing to see what makes sense in your environment), the analyst should then know that the file requires additional in depth analysis. This method could be used as an alerting mechanism that attempts to weed out possibly malicious files from non malicious files. For purposes of this post, I am not going to provide my analysis of this shellcode or the entire staged exploit process. [I promise to have future posts that provide this type detail.]

OfficeMalScanner is a very effective tool at identifying malicious data within the older OLE Office format and also, as we’ve just learned, at detecting malicious traces within binary or activeX files. As an added capability to your enterprise, I would recommend that you automate the scanning of all MS Office email attachments with OfficeMalScanner (at the very least). To do this, there are two potential tasks that would need to be engineered. The first task would involve identifying a way of getting all MS Office files in a place to be scanned by OfficeMalScanner (in an automated fashion). (Note from the author: OfficeMalScanner is written in C and could potentially be exploited: Run this tool in a secure/safe environment.) The second task that would be required includes creating a “wrapper” for OfficeMalScanner that would allow you to perform all of the above commands that I manually typed out to be executed automatically against every MS Office file (XML and OLE formats) and all embedded binary or office files within.

Advanced Enterprise Detection Capabilities (a multipart series)

I'd like to introduce a few concepts that can and *should* be used to augment your current enterprise detection capabilities. This series will not go over standard concepts that enterprises commonly deploy such as firewalls, IDS, proxies, host based AV, etc. These new concepts aren’t anything ground breaking, but they are, however, not too commonly thought of or implemented in the enterprise security stack.

“Part 1: Enterprise Wide Multi-AV Scanning? Well, Kind Of…"

The first concept that I am going to talk about is meant to augment your enterprises’ simple anti-virus (AV) products. In most enterprises, AV scanning technology may be implemented by network devices (web proxy or next generation firewall) and clients/endpoints (think Forefront Endpoint Protection, McAfee Endpoint Protection Suite, ClamAV, etc.). Lets not forget that AV software can also live on servers that offer network services, such as (and not limited to) mail servers (scanning all email attachments), sharepoint servers (scanning all files uploaded to sharepoint), etc.

In simplistic terms, most AV solutions work by either identifying known bad data (a sequence of bytes or code blocks) within a file or by using some form of heuristics on/against a file. The actual file (data) is needed to be scanned and sometimes not even the whole file needs to be scanned by the AV software. The concept that I am about to explain doesn’t actually scan any data within any file (at least not at this moment in time).

The concept is rather simple: Obtain a hash of a file and use that hash to identify other files (presumably malicious) of the same hash. There are online sources, such as Virustotal (VT), that allows you to submit/upload a suspected malicious file and have 40+ different AV packages scan that file for you. Quick note: VT also provides other useful analysis capabilities outside of just simple AV scanning, but most of these other capabilities will be out of scope for this concept. However, a VT capability that is in scope for this concept provides the ability to perform simple searches of the VT database (for free with limitations). This ability allows you to search the VT database with a hash of a file (MD5, SHA1, or 256) and outputs scan results of a previously scanned file with the same hash (see picture below). Keep in mind that for results to be displayed, a file with the same hash had to be uploaded to VT for scanning prior to your search.

I must speak real quickly to the effectiveness of AV in general. All AV solutions will not detect the same malicious files. To provide additional details on this, I recommend reading a report such as (http://www.mcafee.com/us/resources/reports/rp-nss-labs-corporate-exploit-protection.pdf) or you could even just reference the above picture as you'll notice some AV products detected a specific file as malicious while others did not. Another controversy regarding AV is that it is a failing detection capability (http://www.imperva.com/docs/HII_Assessing_the_Effectiveness_of_Antivirus_Solutions.pdf). I will have to agree to an extent in regards to AV's overall effectiveness, but use cases exist (such as the one I am currently speaking to) that encourage us to use the "collective" of AV products as an additional effective source of detection data. Most enterprises will use 1 or 2, maybe even 3 separate AV solutions within their enterprise. The old adage of “two heads are better than one” holds true with having more than one AV solution (to an extent). Having 40+ AV products scan a file raises the odds of a malicious file being detected.

I need to [re]iterate that this isn't an "end all be all" solution as you will only be submitting the hash of a file. If the file is modified in any way, and I mean *any* way, the hash will be different, thus the results may not be favorable. Again, this isn’t an absolute solution, its a gap filler to augment your current enterprise detection capabilities.

Below is a limited set of data points to keep in mind when utilizing a concept that only uses the hash of a file as a detection mechanism.

• A file with the same hash had to have been uploaded to VT for analysis.
• Hash lookups are much faster than uploading the actual file for full scanning.
• The full file being uploaded provides a more accurate analysis.
• No proprietary, personal, or sensitive data is ever sent to VT.
• Subscribing to VT Intelligence allows users to download files that have been uploaded for analysis.
• Using ONLY the hash as a piece of data to perform a lookup against does not help to  contribute to the security community.
• Free VT service has a limited for uses (searches/uploads) per IP per minute. An expansive pay service is available.

To finalize on this concept, you would want to automate this solution to reap all the possible benefits of this concept. As a recommendation, I would first target automating email attachment hash lookups as there will be many obstacles to overcome (ex. identifying types of files that you want hashed, how to obtain the hashes, writing custom software to perform the lookup, etc.). For brevity, I won’t go into detail on how this entire process could be architected from start to finish, but I will finish this post by mentioning some tools that could enable this concept to take shape.

• VT API https://www.virustotal.com/en/documentation/public-api/ - Provides scripted access to searching the database by hash (among other things).
• Bro IDS can be used to obtain hashes of files in near real time.
• Most full packet capture solutions (ex. Solera, OpenFPC, Netwitness, etc.) provide API’s to allow packet data extraction, thus allowing a separate tool to perform data carving and hash calculations.
• Vortex IDS - Have pcap data sent directly to a Vortex IDS instance and hash the relevant streams (saved as files).

The Lesser Known 'Epoch'-ness Monster

Have you ever heard of or dealt with UNIX Epoch (also known as POSIX) time? Ok, so maybe I’m not talking about a monster, but an information technology system for describing time. I’m not planning to retype what UNIX epoch represents, so I’ll send you to this wiki page Unix Epoch. (Here you can read a good explanation and history behind it.) However, I will speak to how you could encounter this time encoding/format in the incident response and digital forensics fields as well as providing a simple solution to a small nuisance that I recently came across.

Throughout an infosec professionals’ career, there are many situations in which one may come across an epoch timestamp. Here’s a couple examples:

• Viewing packet capture files using tools such as tcpdump and tshark. By default, tcpdump and tshark will display the UNIX epoch time when capturing packets (on non-Windows machines)
• MySql database analysis. MySql supports UNIX epoch time.
• Squid proxy logs can be displayed in UNIX epoch time.
• A lot of software running on a *NIX operating system will internally log time in UNIX epoch time, although some may display the time in a converted form by default. Essentially, analyzing data sourced from a linux, UNIX, or Mac OS X platform may be subject to displaying this time format to the analyst.

Recently, I was provided a csv log file to analyze. Below is a file I generated to provide a quick example.

Notice the first column… It contains a 32 bit integer that represents UNIX epoch time. This time representation is the amount of seconds since 01/01/1970 UTC/GMT. I don’t know about you, but there’s no way that I’m going to convert this time into a format that makes sense to me in my head. Back to the log file… There were thousands of lines in this log file so using an online utility such as http://www.onlineconversion.com/unix_time.htm to convert each timestamp manually would not be practical. Three initial solutions came to mind during the brainstorming process.

Possible Solution #1

The first possible solution deals with doing the calculations to determine how many seconds/hrs/days/years the 32 bit integer represents. I most likely would need to determine how many days/hours/seconds existed in each year, while realizing caveats such as leap seconds not being counted, etc. This could be done, but it would require a lot of time to write and then thoroughly test. After the calculations portion is vetted, I would need to append this timestamp to the original log file. This option will be a last resort if I can’t leverage and existing way of performing this action.

Possible Solution #2

The second possible solution includes writing a bash script that would grab the value of the first column of every line, post it to an online website that has already invested the time into performing the calculations, read and parse the results from the web page, and then copy that to a temp file to be appended to the original file. I realized that if I were to pursue this route, I could potentially DoS the website, especially if the log file had thousands of lines in it (I would need to create a single request for each line in repetition). This is not ideal and I would most likely not choose this option for such large conversions.

Possible Solution #3

The third solution that came to mind includes writing a script to convert each epoch date per line and then writing this to a new file. This solution would use a cool feature of the “coreutils” suite of tools. Specifically, the little known use of the “@” switch within the coreutils “date” command. Note that the version of coreutils that this was tested on was ‘GNU coreutils v8.13’. Another note: To determine the version of coreutils that your *NIX system is running, just execute any of the coreutils applications with the switch “--version”.

$ date --version

date (GNU coreutils) 8.13.

…

Needless to say, this is the solution that I chose to pursue.

Below is the command that performs the conversion from UNIX epoch time to an output that is easily understood by analysts.

$ date -d @1382406394

Mon Oct 21 21:46:34 EDT 2013

Here’s the nifty little bash script that takes the first column from each line in the file, converts the UNIX epoch time to your systems current locale (utilizing the date command) and writes the new line to standard out, allowing you to save the output to a new file if desired. A little awk foo was leveraged as well...

This short article was written to provide an infosec analyst with a simple understanding of UNIX epoch time and it was also written to show a quick solution to a problem that I encountered. You never know what type of problems you will run into, so having an experienced set of problem solving skills is essential to an infosec professional.

Try Not to Always be 'Tool Dependent'

I was challenged to write a script in a higher level language to discover live hosts on the network with as little traffic as possible and to write it in as little time as possible. Here’s my solution that took about 25-30 minutes to complete 'as is'. I need to mention that I did not attempt to add any type of evasion techniques (ex. time delays, etc.) and yes, I know there are many other varieties of 'ping' scans (tcp syn, tcp ack, udp syn, arp ping, etc.) that could provide more reliable results.

Disclaimer: This is by no means perfect and could definitely be done with off the shelf tools in a more efficient manner. The idea was to create a semi-automated solution from scratch and not be tool dependent.

Solution

#!/usr/bin/python

# Check a range of IPs to see if any hosts respond to 1 echo request packet

# Created/tested with Python 2.7.3 on Ubuntu 12.04 i686

import sys

import subprocess

import re

ip_sub = "10.0.2."

ip = ""

if len(sys.argv) != 1:

   sys.exit('Usage: %s' % sys.argv[0])

def packetLoss():

   ip = ip_sub + str(r)

   p = subprocess.Popen(['ping -c 1 ' + ip], shell=True, stdout=subprocess.PIPE)

   for line in p.stdout.readlines():

       searchStr1 = re.search( r'packet loss', line, re.M|re.I)

       if searchStr1:

           searchStr2 = re.search( r'100\% packet loss', line, re.M|re.I)

           if searchStr2:

               print " [*] " +ip+ " - Did not respond"

           else:

               print " [*] " +ip+ " - Responded"

   retval = p.wait()

   return;

for r in range(10, 17):

   packetLoss()

Here's output of the script:
$ python check_subnet.py
 [*] 10.0.2.10 - Did not respond
 [*] 10.0.2.11 - Did not respond
 [*] 10.0.2.12 - Did not respond
 [*] 10.0.2.13 - Did not respond
 [*] 10.0.2.14 - Did not respond
 [*] 10.0.2.15 - Responded
 [*] 10.0.2.16 - Did not respond
 
The main takeaway from this post is to emphasize the need to understand how your tools work. Anybody can use a tool, but an analyst that knows what the tools are doing "under the hood" have a higher probability of success when stressful and inopportune situations arise.

"Typical Intro Title"

>>> print "\nHello World!\n"

Hello World!

My name is Jeff Lafferty and I am an Information Security Professional by trade and hobby. I have a college education (BS) and hold/have held various industry recognized  certifications (CISSP-ISSAP, GCIH, GCFA, etc).

My plan is to write about anything related to information security that I feel may be beneficial in some way to the community. Topics surrounding enterprise security architecture, incident response, *NIX, scripting, digital forensics, malware analysis, code, threat intelligence analysis, (insert more buzz words here) etc, will be discussed and shared.  Pretty much anything that I learn about through research (original and unoriginal), I will share.

I am a big proponent of knowledge sharing, so I plan to share what I know and learn with a larger group of folks, rather than just a handful of friends. I encourage discussions and debates.

Happy reading!