snortattack

Another month brings us another Update Tuesday. This month is pretty light with respect to the updates that Microsoft is releasing. They're releasing a total of 5 bulletins, covering 23 CVEs.

First and foremost are the critical updates for Internet Explorer (MS13-047). They are releasing updates for 19 CVEs, some of which could allow for remote code execution. These issues cover all supported IE versions, ranging from IE6 to IE10. Unlike last month, these issues do not seem to have been exploited in the wild and were all reported through Microsoft's "Coordinated Vulnerability Disclosure" program. While most issues are triggerable in default configurations of IE, one issue (CVE-2013-3126) requires the user to have enabled script debugging and can only exploited when this mode is active. This is interesting because the target audience running in this mode are probably web developers, potentially exposing them to increased threat of attack.

There's also an update for the Windows Kernel (MS13-048) that fixes an information disclosure vulnerability, covering all currently supported versions of Windows Desktops, ranging from XP to 8 as well as all Windows Server versions.

Another interesting update is to fix a vulnerability in a Windows Kernel Driver (MS13-049) which can result in a Denial Of Service attack. The Denial Of Service attack is possible only after first triggering protection against another potential Denial Of Service: a SYN flood. Once the system detects that a SYN flood is occurring it goes into "SYN Attack Protection" mode, which will reduce the timeout for the system to wait for ACKs. Once the system enters this mode, it is possible to trigger a Denial Of Service that requires a reboot to correct by sending a maliciously crafted packet.

An update is also being issued for a vulnerability in the Windows Print Spooler (MS13-050), that can allow an authenticated user to gain increased privileges.

Finally, the last update this month is for an issue in both Office 2003 and Office for Mac 2011 (MS13-051), that has been exploited in the wild. The vulnerability allows an attacker to gain remote code execution through a maliciously crafted file.

We have detection for many of these vulnerabilities through SIDs 6700, 26843-26849, 26851-26853, 26867-26878, and 26882-26890.

Late last month, Immunity published a blog post concerning a new way to escape the Java security warnings using a novel and simple method, by using the convenient Java Web Start framework. The Immunity team discovered a parameter called __applet_ssv_validated that sets whether you can run older versions of jre without user validation (Secure Static Versioning). Setting this parameter to true in the applet itself did nothing.

This brings us to Java Web Start.  As a framework meant to facilitate running applets, JWS uses a custom XML document with a special tag, jnlp. When you call an applet you can pass along parameters to the applet you want to run in your browser, including __applet_ssv_validated, like so: "<param name="__applet_ssv_validated" value="true" />".  This is one of the simplest Java exploits to come out in the last year or so, and it was jumped on immediately by exploit kit builders, most notably Blackhole.

The good news is that since it's so simple it can easily be detected, ClamAV signature Java.Trojan.Agent-26 detects it and Snort rules 26524 and 26525 have been out since the beginning of this month and have caught many potential attacks, such as the one below:


Since those rules have been released, exploit kit writers have been busy trying to obfuscate this exploit. A new variant caught by another exploit kit rule, 26535, now uses a jnlp_embedded which is used to pass along supplemental applet data parameter to paste the entire exploit in it's value field, using base 64 encoding thusly:


Detecting the jnlp_embedded parameter we can set snort to decode base 64 data and look for the same exploit conditions. Those rules are 26646 and 26647 and clam sig Java.Trojan.Agent-29.

Today is Update Tuesday and Microsoft is releasing updates for 33 CVEs across 10 bulletins. We'll be discussing some of the highlights here.

One of the most important updates (MS13-038) that is being released is for the recent 0-day in Internet Explorer, which was used in a watering hole attack on a Department of Labor internal website targeting Department of Energy employees. This vulnerability, CVE-2013-1347, affects IE8 and can allow an attacker to perform remote code execution via a use-after-free vulnerability. While it's currently not being exploited in any of the exploit kits that we monitor, Metasploit released an exploit for the vulnerability early last week. Sourcefire has detection for this vulnerability through SIDs 26569-26572.

Microsoft is also releasing a cumulative update for 11 other browser issues, including use-after-free vulnerabilities that could allow for remote code execution (MS13-037). These issues cover all supported IE versions, ranging from IE6 to IE10.

Publisher will also get updates for 11 issues that could allow for remote code execution (MS13-042). One slightly mitigating factor for these vulnerabilities is that they require a user to open the files in Publisher to be able to exploit them, so some user interaction is required as opposed to being exploitable by simply visiting a webpage. Two other products in the Office suite are also getting updates today: Word (MS13-043) is getting a fix for potential remote code execution vulnerability and Visio (MS13-044) is getting a fix for an information disclosure vulnerability. Both issues have similar mitigating factors to the Publisher vulnerability, requiring the user to load a maliciously crafted file. 

Another interesting update fixes a DirectX Graphics Kernel Subsystem Double Fetch Vulnerability (CVE-2013-1332, MS13-046) in a kernel mode driver discovered by Mateusz Jurczyk and Gynvael Coldwind using their tool bochspown, which they presented 3 weeks ago at SysScan '13. The vulnerabilities are basically the result of race conditions that are typical Time of Check to Time of Use (TOCTOU) vulnerabilities. More specifically the vulnerabilities are a result of a double-fetch, where the kernel retrieves a value from user mode, checks it and then retrieves the value from user mode again rather than using a cached copy. An attacker can modify the user-mode value between the time it is retrieved the first time and when it is retrieved again. If any checks occurred on the first fetch, they can no longer be considered valid on the second fetch. A typical example of an exploitable version of this vulnerability would be if a size for a copying function is retrieved from user-mode: it is checked to make sure the size is smaller than the destination memory's size, but during the call to the copy function the value is fetched again, resulting in an unchecked size being used. This can result in a buffer overflow if the attacker can change the value between the check and the use. Their tool found 89 potentially exploitable issues, 33 of which were not deemed exploitable, and 36 of which have already been fixed in various earlier Microsoft bulletins (MS13-016, MS13-017, MS13-031, MS13-036). Another 13 are considered local denial of services only. Today 1 more is being patched, leaving only 6 issues open according to Mateusz and Gynvael's SysScan slides.

Further updates cover an authentication bypass and an XML spoofing vulnerability in .NET (MS13-040). An important mitigating factor for the authentication bypass is that it requires non-standard configuration to be vulnerable. Another issue that is being updated is a vulnerability in Lync (MS13-041) that could allow an attacker to gain remote code execution during a session where the attacker shares content with a user. A mitigating factor for this vulnerability is that the user must accept an invitation from the attacker and must then view the content the attacker has shared.

The company is also releasing a fix for a denial of service vulnerability in HTTP.sys (MS13-039), Microsoft's kernel mode driver that handles the HTTP protocol stack for IIS since IIS6 and an update  for an information disclosure vulnerability in Windows Live essentials (MS13-045).

As always, we are releasing rules today that detect many of these vulnerabilities through SIDs 26622-26642.

PincerI was having a look at the Pincer family of Android malware and came across some code designed to hinder analysis.

From the decompilation of com/security/cert/a/a/c.class:

    String str1 = com.security.cert.b.b.b(paramContext);
    String str2 = com.security.cert.b.b.c(paramContext);
    String str3 = com.security.cert.b.b.d(paramContext);

    if(str3.toLowerCase().equals("android") || 
       str1.equals("000000000000000") || 
       str1.equals("012345678912345") || 
       str2.equals("15555215554") || 
       Build.MODEL.toLowerCase().equals("sdk") || 
       Build.MODEL.toLowerCase().equals("generic"))

At first glance, the application seems to be checking for generic values. The check against str2 is recognizable. It is the default phone number for the Android emulator. It is clear that the sample is also checking the model against the values sdk and generic. Having a look at com/security/cert/b/b.class to see what str1 and str3 are:

    public static String b(Context paramContext) {
        return ((TelephonyManager)paramContext.getSystemService("phone")).getDeviceId();
    } 

    public static String c(Context paramContext) { 
        return  ((TelephonyManager)paramContext.getSystemService("phone")).getLine1Number(); 
    } 

    public static String d(Context paramContext) {
        return ((TelephonyManager)paramContext.getSystemService("phone")).getNetworkOperatorName(); 
    }

The IMEI, phone number, network provider, and phone model are being checked against default emulator values. Crafty. I was running a generic AVD (Android Virtual Device) at the time and unfortunately got caught on all of these checks. Since compiling other people's large projects is something I avoid at all costs, I set out to patch these values in a hex editor. Here's how to change each one.

Before editing any file, please make a backup!
IMEIDoing a quick grep of the android-sdk-linux/ folder reveals that, among a handful of other files, the two emulator binaries each contain only one occurrence of the default IMEI.

    /home/vrt/android-sdk-linux/tools/emulator-arm:1
    /home/vrt/android-sdk-linux/tools/emulator-x86:1

These seem like a logical place to store the IMEI and since there is only one occurrence in each, it should be easy enough to edit and check the feedback. In any hex editor (GHex pictured) this value can be found between the strings  +CGSN and +CUSD:




Editing this value will change the AVD's IMEI on reboot. This process is detailed for Windows on the blogspot blooglog, which helped reassure me I was on the right track.

Network ProviderSince the IMEI is in the emulator-arm binary, I tried blasting some of the other values in there as well. I began by adding the digits 0-9 into the first ten occurrences of the default network provider, Android. Luckily enough, the first occurrence of Android (at the time, Andr0id) is what is pulled as the network provider. You can see it edited to SrcFire in the following screenshot, sitting between 0.10.50 and info:


ModelSince the model can change between AVD images, it is likely somewhere other than the binary.  The Cobra Den's post on making changes to the Android emulator got me on the right track for finding it (as well as some other fields worth changing). The model name follows the label ro.product.model= in android-sdk-linux/platforms/[target platform]/images/system.img, making it very easy to spot:


Note though, if you are loading from a snapshot, you will need to reload the AVD in order for these changes to take place. As well, if you are loading with a different system image (indicated by the -system option on emulator start), you will need to edit that image.

Phone NumberThe last four digits of the device's phone number are the port number that the emulator's console is running on. Since Pincer checks for an entire phone number (default prefix 1555521 + default console port number 5554), this was enough to circumvent the anti-analysis techniques encountered. Attempting to start up the emulator with the option -port 4141 provided this helpful tidbit:

    ERROR: option -port must be followed by an even integer number between 5554 and 5584

This gives a range of 16 phone numbers to work with. While allowing evasion of the anti-analysis in Pincer, a more intelligent malware author would write a check for 1555521. After some mass replacements with sed, I realized my normal trial and error approach would yield only error for changing the phone number.

It turns out that the phone number is stored on the SIM card. Since there is no actual SIM card, one is emulated. This emulated SIM is hard coded in the emulator-arm binary. The reason replacements for 1555521 failed is because SIM cards have a specification that does not store the MSISDN (Mobile Subscriber Integrated Services Digital Network-Number, AKA phone number) in plain text. Instead, each set of digits is swapped in some reverse nibbled endianness nightmare.

At this point I feel it's necessary to again give acknowledgment to The Cobra Den, which has a method for making a lot of these fields configurable by patching the Java getter methods, and to the CodePainters blog which has a post on editing the SIM card serial number. I had come across the source file external/qemu/telephony/sim_card.c in the Android source code, but the CodePainters post is really what made it click that the MSISDN  number would be in there, and that all of that would also be in the binary. As these things go, I found multiple very helpful things at the same time that all led me to the answer.

A quick way to find the MSISDN is to search for %d%df%d in the binary (highlighted in red below). The corresponding source code is in external/qemu/telephony/sim_card.c on line 436 in the current repo. The following is the format string portion of that sprintf:

    "+CRSM:144,0,ffffffffffffffffffffffffffffffffffff0781515525%d1%d%df%dffffffffffff"

The interesting part is 515525%d1 (highlighted in blue). Swapping each set of two digits produces 1555521%d (thanks again CodePainters). That looks like the prefix to our mobile number. Edited in ghex:



The edit in the previous screenshot will yield a phone number 1-876-543-[port number]. That gives (mostly) full control over the phone number. The first 7 digits are entirely configurable, and the last four can be any even number in the range 5554 and 5584 inclusive.

A malware author could still block based on the last four digits of the phone number. If that starts happening though, I know what the last four digits of my next phone number will be. :)

ConclusionThe biggest drawback to this method is that you must keep the length of each value the same, unless you wish to do some serious binary patching. As well,  I have not tested these for stability. I will update this blog post with any issues that come to my attention. The following is a before and after screenshot of the target values:

GG

We here at the VRT are all about backing up opinions with facts, and there are a lot of opinions about the nature of the vulnerability landscape out there. That in mind, we decided recently to study the numbers, and put conventional wisdom to the test.

At a high level, the numbers show that while vendors are putting increasing amounts of effort into security, critical vulnerabilities such as the recent Java, PDF, and Internet Explorer 0-days are on the upswing again of late. Combined with the clear upward trend in the amount of malware being dropped via these vulnerabilities - the Sourcefire VRT now sees an average of over 200,000 unique new malware samples per day - it is clear that users need to be vigilant as ever dealing with the modern threat landscape.

Here are some further highlights from the report:

• Total vulnerabilities and highly critical vulnerabilities were up in 2012 after a significant downswing over the previous few years; 2012 was a record-breaking year for the number of most critical vulnerabilities, those with a CVSS score of 10.
• Buffer overflows continue to be the most important type of vulnerability, with 35% of the total share of critical vulnerabilities over the last 25 years.
• For the first time since 1998, Microsoft did not lead vendors in terms of vulnerabilities reported in 2012; that dubious distinction went to Oracle, whose 2010 acquisition of Sun's Java programming language, a favorite of attackers, contributed to that trend.
• Firefox had more critical vulnerabilities than Internet Explorer over the time period studied, casting doubt on the conventional wisdom that IE is the least secure browser.
• Microsoft released 13% of their patches after the CVE was published, meaning that vulnerability information was publicly available and potentially exploited before a patch was released (0-day).

You can download the full report here. We hope you enjoy our quick dive into the world of vulnerability statistics; if there's any statistics you'd like us to look into in a follow-up post, let us know in the comments.

We at the VRT are always interested in vulnerabilities and information about vulnerabilities. To this end we recently dug into the NVD database and examined data for the last 25 years and used it to map out trends and general information on vulnerabilities in software.

Some of the questions we asked ourselves were:

• What are the most popular vulnerabilities?
• Which had the most impact?
• Which vendors and products suffered from the most issues?
• Which browser is the best in terms of vulnerabilities found?
• How many 0-days are found in products?

While the answers to some of these questions are predictable, others are surprising.
We will be presenting the answers to these questions in a talk at RSA Conference San Francisco 2013. If you're attending RSA and are interested in the answers to these questions, please join us on March 1st at 9.00 AM. A report delving into the details will be released after the conference, you can pre-register here and you will receive a link to the report once it's been published.

UPDATE: the full report has now been released, download it here

Exploit kits may not be as hot a topic as the recently released Mandiant Report, but they're still an important part of today's threat landscape. As the success of the Cool Exploit Kit lets its author buy vulnerabilities, for example, these kits are not only one of the more prevalent ways of dropping malware on end-users, they're actually pushing defenders towards a time with more and more 0-days to worry about.

Those of you who would like to understand more about how these kits work, check out my recent presentation on the subject. The presentation assumes no prior knowledge, so it's a perfect starting point even for management types who might not quite understand the threat landscape.

For those of you running Sourcefire/Snort boxes who are looking for exploit kit coverage, be sure to review how many rules from our new Exploit-Kit category you have enabled - while 200 of the 222 in that category are in the balanced policy by default, if you're not running a current SEU, you're missing a lot of powerful detection.