Author Archive - Yuki Chen (Threat Solution Engineer)

Recently, independent security researchers found that the Angler Exploit Kit had added Silverlight to their list of targeted software, using CVE-2013-0074. When we analyzed the available exploit, we found that in addition to CVE-2013-0074, a second vulnerability, CVE-2013-3896, in order to bypass ASLR. These vulnerabilities are discussed in two separate Microsoft security bulletins, namely MS13-022 and MS13-087, respectively.

This particular exploit checks what version of Silverlight is installed on a user’s system and only runs on the following versions:

4.0.50401

4.0.60310

4.1.10329

5.0.61118

5.1.10411

Up-to-date versions of Silverlight are not affected by this exploit; in this case it simply exits.

Anti-analysis Capabilities

The main component of the exploit is a DLL named fotomaster.dll (MD5 hash: 5f36a4c019d559f1be9fdd0cd770be2e), which is a PE file that contains MSIL (Microsoft Intermediate Language) code, as is expected of an app written using Silverlight. We detect this as TROJ_EXPLOIT.SVL. The exploit is loaded via a Silverlight app on a malicious website; when the app is loaded fotomaster.dll is loaded and the MSIL code inside is executed.

The exploit also uses several techniques to make analysis more difficult. These include:

Preventing Decompiling

Normally, the first step in reverse-engineering a .NET binary is to decompile it into its source code, in order to understands its logic and flow. However, this exploit has obfuscated its code. This causes standard decompiling tools to fail, as can be seen here:

Figure 1. Failed decompilers

Preventing Disassembly

If a .NET binary cannot be decompiled, disassembly into MSIL code would be the next step. The .NET SDK provides a tool, ildasm.exe, to do this. However, Microsoft itself has provided a technique that prevent this.

Figure 2. Failed disassembler

Obfuscated names and code

The above technique makes disassembly more difficult, but does not prevent it completely. However, if one looks at the resulting MSIL code, one finds that it is highly obfuscated and not human-readable. For example, all the class names and method names use unreadable characters and junk code is inserted everywhere to hide the actual control flow of the program.

Exploit Analysis

Vulnerabilities used

As mentioned earlier, the exploit uses two separate vulnerabilities in Silverlight. The first one, CVE-2013-3896, is an information leak vulnerability which can be used to leak sensitive information which is in memory. The exploit uses this vulnerability to leak a pointer address in memory, and then uses this leaked address to compute the base address of mscorlib.ni.dll, bypassing ASLR. Later, this base address is used to compute the ROP gadgets in order to bypass DEP.

The second vulnerability, CVE-2013-0074, is a double-dereference vulnerability, which is used to control the execution flow to jump to the ROP gadget.

The ROP Gadget

Instead of using a sequence of ROP gadgets as many other exploits do, this exploit contains only one ROP gadget, as shown below:

The effect of this ROP gadget it to temper the length field of a .NER uint array. After the ROP gadget is executed, the length of the array becomes a very large value (0x40000003). This array can be used to read/write nearly arbitrary memory in the process’s memory space. This technique of overwriting the length of buffers is well-known, as similar techniques have been in used in Adobe Flash, Java, and Internet Explorer.

The Shellcode

After the buffer’s length field is modified, the exploit will use this buffer to search the process memory space to find some executable memory (a JIT-compiled function’s code area), then copy the shellcode into the executable memory area and execute it. The shellcode resolves the necessary APIs dynamically, and downloads the payload from the server by invoking APIs in wininet.dll, as shown below:

Figure 3. Shellcode

Silverlight and Java

Java is currently the favored targets of exploit kits today. However, there are many similarities between Java and Silverlight:

Both of them are VM languages (Java bytecode versus MSIL code).

Both of them can be embedded in a web page and started remotely.

Both of them run in a sandbox which is based on dynamical privilege checks in critical library functions. When started from web browser, both of them have low privileges by default.

Both require breaking the sandbox to create exploits.

More exploits against Silverlight in the future cannot be ruled out, but mass attacks are unlikely considering Java’s superior market penetration. However, for targeted attacks, it does offer a tempting target. We will continue to monitor the threat landscape for other Silverlight-related threats.

Yesterday, Oracle recently released a new round of updates for Java. Two of these vulnerabilities (CVE-2013-5809 and CVE-20135778) and one in-depth defense issue were discovered by Trend Micro researchers and were privately reported to Oracle. All of these are now patched, and we do not believe they are in use or were earlier discovered by threat actors.

All of these vulnerabilities were in Java’s native layer code, which could lead to remote code execution or information leakage. For example, one of the vulnerabilities we found was a heap overflow issue. An attacker could craft a malicious Java applet targeting this flaw on a malicious web site. When the user visits the malicious web site, if his browser has Java enabled, he may get infected by malware.

Java native vulnerabilities, also known as “Java memory corruption vulnerabilities”, are vulnerabilities which exist in the JRE’s native code (C/C++ code). Other than the sandbox-bypassing vulnerabilities in the JRE’s Java code, native vulnerabilities can cause memory corruptions (e.g. buffer overflows) directly, which could lead to code execution.

Earlier, my colleague Jack Tang talked about the trend of increasing Java native vulnerabilities. What I want to add here is that it is still possible to exploit Java native vulnerabilities, even with the latest exploit mitigation techniques such as DEP and ASLR.

The vulnerabilities we reported also affect Java version 6, which Oracle already stopped supporting since early this year. This can be a problem, in particular to users who are still using the said version as Oracle will not be providing any security update for them. Thus, it is important for users to migrate to use the latest version of the software the soonest possible.

Last month, as SyScan 360 in Beijing, I introduced several methods to exploit Java native vulnerabilities even when DEP and ASLR are both turned on. At the end of the presentation, I also demonstrated remote code execution vulnerability on a fully patched Java install on Windows 8, using a native zero-day vulnerability. (To protect our users, I did not publish the details of this security flaw.)

We urge users to carefully evaluate their usage of Java as necessary and ensure that copies of Java that are used are up-to-date, to reduce exposure to present and future Java flaws.

Trend Micro Deep Security protects users from the exploits targeting the vulnerabilities cited in this blog via the following rules:

After the Tunisian Revolution, also called the Jasmine Revolution by many media organizations, in late 2010 or in early 2011, “Jasmine” became a hot word in China.

Last week, a friend of mine in China received an email message with an .RTF attachment entitled, “My thoughts on the jasmine flower (the language of the document is Chinese).” He had no idea who the sender was. When he opened the document and read its contents, to his surprise, the document’s author tried to persuade him to join a demonstration called the Jasmine Revolution. He was even more surprised when he found out later that his PC was infected with a backdoor program.

After checking the .RTF file, I figured out that this sample tries to exploit CVE-2010-3333—an old stack-based buffer overflow vulnerability in Microsoft Word. By crafting a malformed .RTF file, the attacker may execute arbitrary code on a user’s machine. One of my colleagues here in Trend Micro already reported about a malware exploiting this vulnerability late last year. This vulnerability was already patched by Microsoft a month before that through MS10-087.

Today, more and more exploit developers are using Return-Oriented-Programming (ROP) techniques to bypass the Data Execution Prevention (DEP) feature in recent versions of Windows. In order to successfully launch an attack using ROP, one must know the fixed base address of the targeted module. However, Address Space Layout Randomization (ASLR), another security feature, makes it more difficult for an attacker to predict target addresses by randomly arranging the locations of key data areas.

There are several methods to bypass ASLR. For example, we have seen the use of just-in-time (JIT) spray attack wherein the JIT compiler of Adobe Flash Player was used to place large amounts of code in a system’s memory. We’ve also seen DLLs that did not have ASLR enabled (such as those associated with Java or .NET) targeting Internet Explorer (IE) 8 vulnerabilities in Windows 7. Information leakage can also give the attacker some useful information about the system’s memory layout, which can be used to bypass ASLR. Today, let’s take a look at a recent proof-of-concept (POC) exploit that uses both information leakage and ROP to bypass DEP+ASLR.

The original POC has already been published on the Exploit Database and has been used to attack a known vulnerability in Windows. This vulnerability was fixed with the January 2011 Patch Tuesday (see the Microsoft bulletin MS11-002). It was designated as CVE-2011-0027 and was discovered by Peter Vreugdenhil. Together with a separate use-after-free vulnerability, it defeated a fully patched Windows 7 system running IE 8, which allowed Vreugdenhil to win “Pwn2Own 2010.”

Although the exploit code is not 100% reliable, Vreugdenhil’s idea of using the vulnerability to leak information is still worth looking at.Read the rest of this entry »

Several weeks ago, a new Adobe Acrobat/Reader zero-day vulnerability was found and soon exploited in the wild. What’s most interesting about this particular exploit is how it used return-oriented exploitation (ROP) techniques to bypass some of Windows’ security features such as Data Execution Prevention (DEP). In addition, it uses a two-staged shellcode to perform its routine. The first stage uses ROP techniques to load the second stage. The second stage is what actually executes the malicious behavior and is sprayed into memory by JavaScript within the .PDF file itself.

Threats like these show how vulnerability threats, like malware, are evolving to become more sophisticated. Despite the best attempts of vendors such as Microsoft to incorporate new and emerging technology to make exploitation more difficult, those behind these threats are just as ready to grow and make life more difficult for users.