An interesting case of the CVE-2014-8439 exploit


We have recently seen an exploit targeting the Adobe Flash Player vulnerability CVE-2014-8439 (we detect it as Exploit:SWF/Axpergle). This exploit is being integrated into multiple exploit kits, including the Nuclear exploit kit (Exploit:JS/Neclu) and the Angler exploit kit (Exploit:JS/Axpergle).

Adobe released a patch in November to address this exploit (APSB14-26).  Coincidentally, our investigation shows that Adobe released a patch to address a different exploit and that patch appears to have rendered this exploit useless.

CVE-2014-0569 or CVE-2014-8439?

In our analysis of the exploit code, we noticed that the exploit author seems to be confused about the CVE number of the vulnerability they are trying to exploit. It appears the author thinks the exploit is CVE-2014-0569, when the vulnerability they are actually targeting is CVE-2014-8439. This incorrect CVE number is used in the source path (Figure 1) of the SWF file.

incorrect CVE

Figure 1: Incorrect CVE number (CVE-2014-0569) used 

The unusual control transfer trick

To successfully deliver the attack, the exploit needs to transfer control to the deliberately crafted code.  In this exploit we didn't see the common tricks used by SWF exploits to cause the control transfer (see Cracking the CVE-2014-0569 nutshell and A journey to CVE-2014-0497 exploit). Actually, we didn't even see any code which explicitly causes the control transfer.

After some further investigation, we discovered the new trick used by this exploit: it attempts to use the vulnerability to corrupt a garbage collection (GC) object. In the GC object, there is an ITelemetry object pointer (offset 0x180 on the Flash Player we are analyzing). The ITelemetry object's VTABLE is crafted with the address to which the control is transferred (Figure 2).

Crafted GC object

Figure 2: Crafted GC object, Crafted ITelemetry object and Crafted VTABLE entries

The control will be transferred to return-oriented programming (ROP) gadgets via the ITelemetry.IsActive() virtual function call  when garbage collection occurs (Figure 3).

Control transfer

Figure 3: Control transferred to ROP gadgets

Shellcode and payload

The shellcode downloads and decrypts a DLL from a remote server. It then registers the DLL by executing the regsvr32 command. The DLL is detected as Ransom:Win32/Reveton, which is a lockscreen ransomware trojan.

You should apply the update from Adobe, mentioned in APSB14-26, keep your software up-to-date, and use a real-time security product such as Microsoft Security Essentials to help protect your PC from this and other threats.

Chun Feng
MMPC

Acknowledgements

I would like to thank Timo Hirvonen from F-Secure and Kafeine from Malware don't need Coffee for the great help during my analysis.

SHA1s used in this analysis:


Comments (4)

  1. Robert Scroggins says:

    Now the malware author knows how to correct his code. Why not explicitly mention his error? You have just made it easy for him–I guess you could say you are his quality control office. Perhaps computer security personnel should all not explicitly mention
    things like this. The average user doesn't really care, and you can communicate with other security people through less public channels. Eh?

  2. EricLaw says:

    @Robert: The CVE number isn't a relevant factor here; the exploit works just fine, the bad guy was just confused about the identification number of the vulnerability he was attacking. Correcting the number would have no impact on anything.

  3. Andy says:

    @Robert: @EricLaw is spot on; additionally, now we know that the same malware author is weaponizing (or attempting to weaponize) the other CVE in a similar fashion. It helps the community as a whole.

  4. adwbust says:

    Make it a policy that dll needs to be either signed, is from a trusted publisher or whitelisted before it can register itself?

    Does MSE guard monitor behavior that tries to kill task manager, AV process or other Windows process? How about changes to group policy?

    Maybe UAC can warn user when an untrusted dll tries to register itself or when a process tries to kill another or system process?

    Does MSE guard monitor behavior that disables UAC or disables prompt for running executable?

Skip to main content