A technical analysis of Adobe Flash Player CVE-2012-0779 Vulnerability

[M2G]

Recently, we've seen a few attacks in the wild targeting a patched Adobe Flash Player vulnerability. The vulnerability related to this malware was addressed with a recent patch released by Adobe on May 4th. On the Windows platform, Flash Player 11.2.202.233 and earlier is vulnerable. If you're using vulnerable version, you need to update your Flash Player now to be protected against these attacks. We had a chance to analyze how the malware (sha1: e32d0545f85ef13ca0d8e24b76a447558614716c) works and here are the interesting details we found during the investigation.

The following diagram shows the overview of the attack flow. The attack is initiated by sending a malicious document that contains a SWF download trigger and a malicious binary. The document doesn't contain any malicious SWF payload at all.

Figure 1 Overview of the attack

Here is the detailed process that describes how the infection occurs when the victim opens the malicious document:

1) When the user opens the malicious document, the SWF download trigger part of the document downloads external content for rendering. This is specifically crafted to download malicious SWF content from malicious server 1. The embedding feature is not malicious itself, but the downloaded SWF is malicious and abuses the vulnerability in the Adobe Flash Player plugin.

2) The malicious SWF content is downloaded to the user's application and is rendered. The malicious SWF is a wrapper with the actual payload encoded inside it and is loaded dynamically. We call this dynamically loaded content layer 2 SWF. The layer 2 SWF is loaded and spreads heap spraying code on the target application's memory space.

3) The vulnerability trigger part of the layer 2 SWF contacts the designated malicious server to retrieve malicious data. This data causes the vulnerability to manifest.

4) The heap spray code loaded by layer 2 SWF is executed when the vulnerability is triggered.

5) The shellcode inside this layer 2 SWF decrypts a PE file from the malicious document. First of all, it enumerates all the opened handles to find the original malicious document - if the enumerated file contains an 8 byte marker at a certain offset then it is found. Then it decrypts the PE file from 0x10 bytes after the found marker. Each byte is XORed with a hard coded key while skipping byte zero and the byte with the same value as" key". After decryption, the PE file (SHA1: 27c8bdacd4023858a810bec917381c6a7512715e) is detected as TrojanDropper:Win32/Glacid.A.

Compared to other attacks in the past, this attack is a little bit more complicated as different elements work together to achieve the whole attack. Each modularized component is designed to be configurable.

For example, when the original malicious SWF is downloaded from malicious server 1, the original malicious document is crafted to pass HTTP request parameters which will be used inside the malicious SWF file. The following packet capture shows one of the example requests we obtained. We can see that the request is using the "info" and "infosize" HTTP parameters. These parameters are later used in layer 2 SWF.

Figure 2 Malicious SWF Download Request

Here is the layer 2 SWF code which uses one of the dynamically passed parameters. The data dynamically passed is converted to binary form and is decompressed. The decompressed data is connection information about malicious server 2 which serves malicious data.

Figure 3 Parameter Usage Inside Layer2 SWF

As we saw from the overview diagram, layer 2 is loaded dynamically from the malicious SWF. The following code from the malicious SWF file shows how the layer 2 SWF file is loaded. The "loadBytes" method from "flash.display.Loader" class is called to load layer 2 SWF dynamically. This is a very typical way of loading malicious layer 2 SWF as seen in recent SWF malware.

Figure 4 Dynamic Loading Of Layer2 SWF Using loadBytes

One notable thing with the layer 2 SWF file is that it is using the"Shared Object" feature from Adobe Flash Player. This is the mechanism to save persistent data on a user's machine which can be shared through sessions. When the same SWF file is loaded later, it can retrieve previously saved data from this "Shared Object". By using this "Shared Object" feature, the malware avoids multiple exploitation attempts by checking the existence of the data and not performing the exploitation when it is found.

Figure 5 Usage Of Shared Object To Prevent Multiple Exploitation

As usually seen from malware abusing Adobe Flash Player, this malware is also using a heap spray technique to achieve shellcode execution. The following code part shows how the heap spray is happening. During this heap spray phase, you can observe that the application's memory usage spikes.

Figure 6 Heap Spraying

The following picture shows what the shellcode sprayed on the memory looks like. When the exploitation is successful, the control flow is passed to one of these sprayed shellcodes in the memory.

Figure 7 Sprayed Shellcode On the Memory

The overall attack requires multiple modules to work together. We don't see the attack as widespread yet. The vulnerability is not about the carrier that triggers the downloading of the SWF, but more of the Adobe Flash Player's vulnerability. So, if you update your Adobe Flash Player, you can prevent the attack from affecting you.

Sursa: A technical analysis of Adobe Flash Player CVE-2012-0779 Vulnerability - Microsoft Malware Protection Center - Site Home - TechNet Blogs