Trend Micro Facebook TrendLabs Twitter Malware Blog RSS Feed You Tube - Trend Micro
Search our blog:

  • Recent Posts

  • Calendar

    December 2014
    S M T W T F S
    « Nov    
     123456
    78910111213
    14151617181920
    21222324252627
    28293031  
  • Email Subscription

  • About Us

    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:

    83493440        or      dword ptr [ecx+34h],40h
    b801000000      mov     eax,offset <Unloaded_pi.dll> (00000001)
    ret     4

    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.

    Microsoft has released two bulletins for the two vulnerabilities:





    Share this article
    Get the latest on malware protection from TrendLabs
    Email this story to a friend   Technorati   NewsVine   MySpace   Google   Live   del.icio.us   StumbleUpon




    Comments are closed.



     

    © Copyright 2013 Trend Micro Inc. All rights reserved. Legal Notice