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 (0?40000003). 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:
- Microsoft Security Bulletin MS13-022 (CVE-2013-0074)
- Microsoft Security Bulletin MS13-087 (CVE-2013-3896)
Leave a reply
