Vulnerabilities « M86 Security Labs Blog

Archive for the ‘Vulnerabilities’ Category

M86 Security Threat Report for the Second Half of 2011 is Now Available

We are releasing today our bi-annual Threat Report for 2H 2011. The report relies on M86 Security Labs analysis of spam and malware activity, including the current use of exploit kits, fraudulent digital certificates and social networking schemes. Key points from the M86 Security Labs for the second half of 2011 are:
1. Targeted attacks became sophisticated and pursued a wider range of organizations, including commercial, national critical infrastructure and military targets.
2. Use of stolen or fraudulent digital certificates has become more common, especially as part of targeted attacks.
3. In several targeted attacks, malware was hidden by embedding itself in various file formats—with a few cases of multiple embedding layers. This method can evade security software that fails to scan deep enough.
4. Blackhole has become the most prevalent exploit kit in the second half of 2011 with a huge margin over other exploit kits. Some of the exploit kits which were active in the past are rarely used now or were practically abandoned.
5. Newer versions of Blackhole are being deployed first in Eastern Europe. Its authors increased its update frequency and added new exploits and tricks to evade detection, such as checking the software version on the client machine before attempting to exploit it.
6. Fake social media notifications are now a mainstream way for spammers to dupe users into clicking links.
7. Facebook continues to be a conduit for spam and malware, as many campaigns are spreading virally by enticing users to share posts that promise gift cards or other rewards.
8. Hacked, but otherwise legitimate, websites played a major role in distributing spam and malware by redirecting browsers to the ultimate destination.
9. Malicious Web content currently exploits more than 50 vulnerabilities in various software products. The most commonly exploited products are Microsoft Internet Explorer, Oracle Java, Adobe Acrobat Reader, Adobe Flash and Microsoft Office products.
10. The overall volume of spam continued to decline in 2011, reaching a four-year low in December 2011.
11. Eight spamming botnets were responsible for 90% of the spam monitored by M86 Security Labs. All of these botnets are familiar and have been established for some time.
12. The proportion of malicious spam rose in the second half of the year from less than 1% to 5%, including a massive spike in malicious attachments in August and September. Later in the year, the focus shifted from malicious attachments to malicious links that led to exploit kits, in particular, the Blackhole exploit kit.
13. Some noticeable wins by law enforcement authorities and researchers against cybercriminals, botnets and affiliate programs like fake AV and rogue online pharmacies, took place this year.
14. Malicious Web content hosted in China targets mostly older versions of Internet Explorer, which is popular in that country.
15. Almost half of the global malicious Web content is hosted in the U.S. The states hosting most malware are Florida, California, Texas and Washington.

The report provides statistics about the geographical distribution of web-based malware, about the most commonly used exploits and about the prevalence of exploit kits. Statistics about spam categories and spam botnets are also provided. In addition to these statistics, the report includes eleven featured articles about current cyber threats and ends with recommendations for administrators, Website owners and end users.
The M86 Security Labs Report can be downloaded from http://m86.it/2HSecReport.
We hope you find the information in this report useful.
M86 Security Labs

MIDI Files – Mid-Way to Infection

By Arseny Levin • January 31st, 2012 • Vulnerabilities

Microsoft’s January patch MS12-004 addressed a few vulnerabilities in Windows Media components. One particular issue, CVE-2012-0003, can be exploited via Windows Media Player ActiveX, as it leverages a heap overflow occurring in ‘midiOutPlayNextPolyEvent’ function within the Windows Multimedia Library, winmm.dll. The bad guys didn’t waste time and this vulnerability is now exploited in the wild as reported by Trend Micro. A Web page hosted on a South Korean site loads a maliciously crafted MIDI file and sprays the heap. The attacker utilizes the exploitation method presented in Nicolas Joly’s blog from VUPEN. The attack allocates an HTML element of a specific size and eventually overwrites some of its data, and thus achieves malicious code execution.

The author of this page used a Korean JavaScript obfuscator in order to obfuscate a large block of code which hides the shellcode, as can be seen in the following code snippet. In particular, the obfuscated code, generated by this tool, changes itself several times during execution.

The code also ensures that it is being executed only in Internet Explorer because that’s the only browser where this exploitation will be successful. After de-obfuscating the JavaScript code, we can analyze the shellcode itself. The author uses a common evading technique: XOR encryption, with a decrypting loop at the prologue. This technique is usually very effective against signature based detection engines.

Then the shellcode imports and calls URLDownloadToFileA to download the payload which is a packed executable, saving it with an ambiguous name such as “a.exe”.

The executable is a downloader which fetches additional malware with rootkit capabilities. The author of the attack did a decent job obfuscating the executable file, as can be seen by a Virustotal analysis:

All M86 Secure Web Gateway customers are protected from this attack by default without need to install any security update.

Prevalent Exploit Kits Updated with a New Java Exploit

By Daniel Chechik • December 16th, 2011 • Cybercrime Malware Vulnerabilities

Until recently, most of the vulnerabilities exploited by popular exploit kits were found last year or even earlier. Moreover, it would take authors at least a month to update their kits with the new exploits that had been discovered in the wild. However, in the past few weeks, authors released an updated version of their kits with a new recent exploit before a patch had been released.

First, a new version of the Blackhole exploit kit was released, version 1.2.1:

: Live Blackhole Exploit Kit control panel

The Blackhole exploit kit presented above was modified to exploit clients that have Java installed, using the recently discovered CVE-2011-3544 vulnerability. This is the only vulnerability that is actually being exploited.
A few days later, a new version of Phoenix exploit kit 3.0 was released, just a few weeks after the release of its predecessor, Phoenix 2.9.

Live Phoenix Exploit Kit 3.0 control panel

Notice the red boxes in the screen shots above: A new exploit was added to those exploit kits, which is the reason for the upgrade.

A few weeks ago Michael ‘mihi’ Schierl described a design error in Java. Basically this vulnerability is similar to other Java vulnerabilities where an untrusted code is executed in elevated privileges. Rhino is a Javascript engine that runs under the JVM and can interact with Java applets. An attacker can bypass the scripting engine protection by generating an error object, using Rhino script, which runs in elevated privileges and executing code that disables the Security Manager. Once the Security Manager is disabled, the attacker can execute code with full permissions.

Not long after the discovery, an exploit module was published in Metasploit. First, the code binds a Rhino object with the applet:

import javax.script.*;
…
ScriptEngine engine = new ScriptEngineManager().getEngineByName(“js”);
Bindings b = engine.createBindings();
b.put(“applet”, this);

The Java code executes a script that bypasses the Security Manager protection by using the “toString” method inside a script context:

Object proxy = (Object) engine.eval(
“this.toString = function() {” +
“                      java.lang.System.setSecurityManager(null);” +
“                      applet.callBack();” +
“                      return String.fromCharCode(97 + Math.round(Math.random() * 25));”+
“};” +
“e = new Error();” +
“e.message = this;” +
“e”, b);

The script throws an exception, and the rest of the code would be executed.

catch (ScriptException e) {
e.printStackTrace();
}

The vulnerability is cross-platform and doesn’t require heap spray or buffer overflow techniques. That makes it very effective and therefore authors of exploit kits rushed to add it to their kits. The concerning aspect is that the Blackhole exploit kit was updated even before a patch was released by the vendor.

Customers of all versions of M86 Secure Web Gateway are safe, as it provides zero-day protection against this vulnerability by default.

We highly encourage users to keep their Java updated, or remove it if it is not needed. A patch for this Java vulnerability is available by now: Look for Java 6 Update 29, or Java 7 Update 1.

A new Adobe 0-day In the Wild – – But No Worries, You are Already Protected with Our Secure Web Gateway!

By Anat Davidi • December 7th, 2011 • Vulnerabilities

Yesterday Adobe released an advisory for a vulnerability in the Adobe Reader and Adobe Acrobat products. The vulnerability, titled ‘U3D Memory Corruption Vulnerability’ was part of a targeted attack and discovered by Lockheed Martin’s Computer Incident Response Team. This is not the first time a targeted attack has been aimed at the US defense industry.

This attack involves embedding a maliciously crafted Universal 3D (U3D) stream in a PDF file, one of several examples of attacks on embedded streams within PDF files, and represents a growing attack vector due to its ability to deal with defense mechanisms among which DEP and ASLR (two techniques meant to help prevent unauthorized code execution) using known techniques such as JIT Spraying.

According to Adobe’s blog post released alongside the advisory, Adobe is planning to release an update for Adobe Reader 9, the version targeted by this vulnerability, “no later than the week of December 12, 2011″. The rest of its supported versions will receive updates as part of their quarterly updates in January 2012.

M86 Secure Web Gateway, version 9.2 and above, provides zero-day protection against this attack, without requiring any further updates. Customers who wish to monitor the attack in their organization may look for attacks that are tagged with the “Adobe Universal 3D streams” block message.

We’re proud that our proactive rules block this new zero-day exploit and we’ll continue to work hard to provide this level of protection to our customers in the future.

Tags: 0day | Acrobat Reader | Adobe | CVE-2011-2462 | exploit | PDF | SWG

TrueType but not Truly Safe: The New Zero-Day Event

By Ziv Mador • November 8th, 2011 • Vulnerabilities

A new vulnerability in Windows, CVE -2011-3402, has been
recently identified and is already exploited in the wild. For now, only a
handful of targeted attacks have been found. The vulnerability exists in
Windows TrueType Font Parsing Engine and affects most Windows versions,
including Windows 7. An attack involves a file which has a maliciously crafted
TrueType font file (TTF) embedded in it. There are several file formats that
use TrueType fonts, for example, file formats of Microsoft Office and Adobe
Acrobat Reader. In the currently known targeted attacks, a Microsoft Word
document was used. Once rendered on a vulnerable system, parsing the TTF file
may end up with execution of malicious code. Microsoft has released an advisory
for this issue and also released a FixIt tool as a workaround. It disables access
to the system file T2embed.dll in order to avoid TrueType font processing.
However, a word of caution: Applications that use these fonts may break after
this workaround is deployed.

In the known attacks, the installed malware is known as Duqu.
The Laboratory of Cryptography and System Security (CrySyS) at Budapest University
first reported these attacks and they were thoroughly investigated by that team
and by Symantec in the following article.

M86 Security Secure Web Gateway (SWG) can be deployed with
three possible antivirus scanners and they already released protection: Kaspersky,
McAfee and Sophos. No additional Security Update by M86 Security is required. In addition, we are
investigating adding more layers of protection in the future. Keep in mind,
these attacks currently are not delivered via web browser but that can obviously change
in the future.

We will continue to monitor the situation and update this blog post as necessary.

“Steve Jobs Alive!” Spam Campaign Leads To Exploit Page

By Rodel Mendrez • October 7th, 2011 • Spam Vulnerabilities

It was a sad day in the technology industry with the recent passing of Apple’s legendary leader, Steve Jobs. Unfortunately, the cyber-criminals see this as an opportunity. Today, we started seeing a Steve Jobs spam campaign, with the subject suggesting that he is still alive.

Steve Jobs Alive!

Steve Jobs Not Dead!

Steve Jobs: Not Dead Yet!

Is Steve Jobs Really Dead?

Sample of the Steve Jobs spam campaign

The URL links in the spam are many and varied. The websites that they point to all look to be hacked by the addition of obfuscated code that, after two layers of redirects, ultimately ends up at a BlackHole exploit kit landing page.

The HTML source code of the Blackhole Exploit kit landing page

The intermediary redirect URLs are random-looking domains, with a top level domain of .ms (Monserrat in case you didn’t know), here are some examples:

hxxp://xnyiinobfb[dot]ce[dot]ms/index.php
hxxp://derhvbq[dot]ce[dot]ms/index.php

The purpose of the exploit kit is to try and exploit vulnerabilities on the system and eventually download malicious executable files. At this stage, we are not sure what the ultimate payload is, as no files were actually downloaded on our test system.

Unfortunately, many people may find this spam campaign “click-worthy” given the icon that Steve Jobs was. The usual advice applies – avoid clicking links in unsolicited email. In this case, one simple click is all it takes to get compromised.

0-day exploit used in a targeted attack – CVE-2011-1255

By Avri Schneider • June 26th, 2011 • Cybercrime Malware Vulnerabilities

Time Element Memory Corruption – a remote code execution vulnerability, recently patched by Microsoft as part of MS11-050, bearing the Common Vulnerabilities and Exposures (CVE) number CVE-2011-1255 is being actively exploited in the wild.

M86 Security Labs team was contacted and asked to inspect the URL of a legitimate website of a large private company that was blocked by one of the proactive detection rules implemented in our Secure Web Gateway product.

We were asked to investigate if it was indeed a malicious page or a case of Over-Blocking.

The page looked benign, but inspecting each included JavaScript code, we saw that one of them:

Was injecting an iframe:

pointing to a malicious page that was very easilty classified as malicious due to shellcode patterns being part of the page’s DOM:

So, just another infected site – big deal right? But, after further inspection, we saw that it exploited an un-published security vulnerability in Internet Explorer. To verify this, we viewed the malicious page on the latest fully patched version of IE and saw a crash followed by execution of malicious code.

You can imagine the excitement on the team – finding a 0-day in the wild!

The excitement of finding a 0-day in the wild didn’t last that long, since soon after, Microsoft released details about this particular vulnerability.

Based on data we have reviewed from various sources, we can say with a high level of certainty, that the anonymous researcher who according to Microsoft’s security advisory, reported the vulnerability details to VeriSign iDefense, or at least one of his acquaintances, had used the vulnerability details for malicious purposes, as part of targeted attacks.

We decided that we should inspect the shellcode to see what the attacker was after. It used various anti-debugging tricks, but after decoding, it revealed a clear-text URL pointing to a malicious server already listed in our repository.

The attack sample stored in our repository was an attack for the well-known iepeers.dll vulnerability exploiting CVE-2010-0806.

It is interesting to note that the first saved sample of the attack was dated 21.3.10, while details of the vulnerability were reported and patched by Microsoft’s MS10-018 security patch for Internet Explorer on 30.3.10.

Two 0-day exploits served from the same server – impressive!

We wanted to find out where else he is serving his malicious code.

Remember the code snippet shown above, showing how the attacker hid the shellcode as part of the DOM?

Hiding data in the DOM of the page is a good obfuscation technique that bypasses security software that doesn’t act as an actual browser, and where their script engine does not have access to the actual DOM.

It turns out that one of the side-effects of hiding data inside DIV elements is that it makes the data indexable by search engines.

Google searching the pattern “TTu0d0f[...snip...]d0dLL1043416UU” revealed about 16 results and as of this writing, only a few were still alive.

Here is the list of the infected sites according to Google’s search result:

Not to mention the service of caching samples for us, it’s ironic that an attacker’s obfuscation technique can be used against him to find his infection servers using a simple Google search.

Tags: 0day | CVE-2011-1255 | exploit | Internet Explorer

McAfee, Secure Short URL Service… Or is it?

By Anonymous • December 6th, 2010 • Vulnerabilities

Recently, McAfee entered the already crowded URL Shortening business. The service is called mcaf.ee and is meant to provide a major ‘added value’ over its competitors; namely security.

Basically, every URL being shortened using the mcaf.ee service, is scanned and ensured to be safe for browsing. However, as when using any AntiVirus, it appears that not only safe URLs are shortened but malicious ones too. As a result this may hurt the security provided by other sites, which in turn might rely on the security provided by the mcaf.ee service.

For demonstration purposes, let’s have a look at a malicious URL, which was found in the wild, and was reported as safe by mcaf.ee.

Page source of a malicious "short" URL

Figure 1 shows a screenshot of the source code of a malicious URL (shown in the red frame). McAfee reported it as safe (as seen in the green frame).

Now, let’s see how the mcaf.ee service can be manipulated to overcome the security provided by Facebook, for example. We’ll choose a successfully blocked Facebook phishing URL:

Facebook phishing blocked successfully by Facebook

Facebook phishing site marked as safe by McAfee

When we used the shortened URL generated by mcaf.ee service: hxxp://mcaf.ee/139b4, the URL could be used on a Facebook wall or private message, without being blocked. Luckily, after a few minutes, we noticed that Facebook started blocking that URL as well.

Users should carefully check the links coming from emails, Facebook or any other social network, when the sender is unknown and the link is shortened, because there is no guarantee the URL is safe, almost in the case when it comes from “Secure URL Short Service”.

Post Authored By Daniel Chechik and Moshe Basanchig

Tags: Facebook | Phishing | Secure Short URL | URL Shortener

Who’s looking for eggs in your PDF?

By Avri Schneider • November 18th, 2010 • Vulnerabilities

At M86 Security Labs, we research various attacks on a daily basis. Some of these attacks originate from malicious PDF files.

One distinctive characteristic of malicious PDF files is a chunk of javascript code performing a heap-spray on the client browser, filling it with NOP (No OPeration) instructions (also acting as a valid heap memory address) – followed by the attacker’s shellcode; then triggering a bug in the PDF reader, which directs the flow of execution to a random memory location on the sprayed heap, executing the NOP sled followed by the shellcode.

While investigating the latest PDF 0day exploit [CVE-2010-4091, Extraexploit, VUPEN, Original Full-Disclosure post] that was published to the Full-Disclosure mailing list, we noticed something interesting – the shellcode part of the malicious javascript code was very tiny:

Here’s a disassembly view of the shellcode:

What we’re seeing is a known shellcode technique called Egghunting, where the shellcode itself is very small (usually free of Null bytes) and it’s sole purpose is to search the memory space of the process for the real shellcode, and on some more advanced versions for one or more parts of the reall shellcode – collect all the pieces together, then execute the found shellcode.

It’s used mainly in types of attack that prevent the attacker from placing a large amount of shellcode at the point where he is able to gain control of code execution, while being able to control data in the memory space of the process yet lacking the exact memory address location of the controllable data.

Notice how the egghunter shellcode uses int 0x2e to call the nt!NtDisplayString kernel function, passing it a pointer to the address to check on the stack (the edx register points to the user-land stack while eax is the System Service Code – an index to the nt!KiServiceTable pointer array, pointing to the nt!NtDisplayString function). You can read more about “How do windows NT system calls really work?” in this great article.

If the memory address is un-mapped in the address space of the process, an access violation will occur and the return value in the eax register will be 0xc0000005 (STATUS_ACCESS_VIOLATION).

The egghunter shellcode compares the low byte of eax to 5, indicating un-mapped memory and increments the address to check on each loop iteration.

Each mapped memory region is searched for the pattern \x90\x50\x90\x58 which translates to:

90 – NOP
50 – PUSH EAX
90 – NOP
58 – POP EAX

- A ‘non-intrusive’ marker (‘NOP’) indicating the beginning of the real shellcode.

Once found – the egghunter jumps to the address and continues execution from there.

As a side-note, this particular sample is not functional – i.e. when the vulnerability is triggered by executing the this.printSept() javascript code, the egghunter shellcode is never executed – crashing the browser.

It would nevertheless be interesting to see were egg-hunting exploits do decide to place the real shellcode in future PDF attacks.

Don’t Get Infected By Zombies

By Gavin Neale • October 15th, 2010 • Vulnerabilities

Today we had a peek inside an exploit kit known as the Zombie Infection Kit. This kit is not as widely used as some of the more popular kits such as Eleonore and Phoenix and compared to these other kits, Zombie is not really that sophisticated. However it does carry the usual range of exploits that have been effectively used in many other exploit tool kits. Potential victims are forced to visit Zombie’s exploit page when their browser loads an IFrame placed on a compromised website. All of the vulnerabilities exploited by this kit have been patched by the vendors concerned.

As well as exploiting an old vulnerability in IE 6 and the recent Windows help center vulnerability, the Zombie Infection Kit also uses exploits targeting two Java vulnerabilities, four vulnerabilities in Adobe PDF readers and two vulnerabilities in Adobe Flash.

Success rates for the various exploits use by the Zombie infection kit

According to the exploit statistics page in the admin control panel, the two most successful vulnerabilities are in Oracle’s Java, accounting for just over 60 percent of successful infections between them. Following closely behind the Java vulnerabilities is ‘PDF’ which is actually a PDF file containing exploits for four Adobe PDF vulnerabilities; the most recent of which (CVE-2009-4324) has been patched since December 2009.

Another stats page shows a breakdown of victims by browser type, showing the percentage of successful installs for each browser.

Victim browser statistics. The last column is the percentage of successfully infected victims.

This table isn’t really indicative of how secure each browser is, as only Internet Explorer is targeted for browser specific vulnerabilities whereas all browsers are used to target vulnerabilities in Adobe Flash and PDF readers, and Java.

What this does show is that 15 percent (15.39 in the top row of the browser stats image, above) of ‘visitors’ were successfully exploited by the Zombie Infection Kit and made to download a malicious executable. Because Java vulnerabilities accounted for 60 percent of infections, a surprising nine percent of all visitors were infected just by having an old version of java installed.

Java exploits are becoming increasingly useful for web attackers, as many people don’t even know that Java is installed on their machines, or that it may need to be updated. What is worse is that it is possible to have multiple versions of Java installed on a machine so you can still be vulnerable even after you install the latest version, giving you a false sense of security.

We strongly recommend users uninstall Java if they don’t use it, or remove old versions and upgrade to the latest version just released by Oracle which fixes 29 flaws in the previous version for which exploits have recently been published.

Tags: Adobe | Exploit Kits | Java | Unpatched