CVE-2014-0497 – a 0-day vulnerability

CVE-2014-0497 – a 0-day vulnerability

A short while ago, we came across a set of similar SWF exploits and were unable to determine which vulnerability they exploited.

We reported this to Adobe and it turned out that these ITW exploits targeted a 0-day vulnerability. Today, Adobe released a patch for the vulnerability.

This post provides a technical analysis of the exploits and payload that we discovered.

All in all, we discovered a total of 11 exploits, which work on the following versions of Adobe Flash Player:

11.3.372.94
11.3.375.10
11.3.376.12
11.3.377.15
11.3.378.5
11.3.379.14
11.6.602.167
11.6.602.180
11.7.700.169
11.7.700.202
11.7.700.224

All of the exploits exploit the same vulnerability and all are unpacked SWF files. All have identical actionscript code, which performs an operating system version check. The exploits only work under the following Windows versions: XP, Vista, 2003 R2, 2003, 7, 7x64, 2008 R2, 2008, 8, 8x64. Some of the samples also have a check in place which makes the exploits terminate under Windows 8.1 and 8.1 x64.

http://www.securelist.com/en/images/vlweblog/cve-2014-0497_01.png

Operating system version check algorithm

If the OS version check is successful, control is passed to functions which assemble ROP chains depending on the Flash Player version. Curiously, there are two such functions – one for Windows 8 / 8x64 and the other for all other versions of Windows.

http://www.securelist.com/en/images/vlweblog/cve-2014-0497_02.png

The algorithm that checks Flash Player version and assembles an ROP chain

Next, a shellcode specific to the version of Windows used is generated and the vulnerability is exploited.

http://www.securelist.com/en/images/vlweblog/cve-2014-0497_03.png

Code fragment which generates the shellcode

We discovered three types of shellcode. The first is a primitive shellcode that reads an executable named a.exe from an SWF file and drops it to the hard drive. Only one of the 11 exploits in our possession (all detected by Kaspersky Lab products as HEUR:Exploit.SWF.Agent.gen) included a payload, but this is discussed below.

http://www.securelist.com/en/images/vlweblog/cve-2014-0497_04.png

The shellcode that reads an embedded file from an exploit and drops it to the hard drive

The second type downloads and executes a file from a URL passed in the SWF file’s parameters. Unfortunately, since we do not have the containers that can pass parameters (html/docx), we were unable to check what is downloaded and from where.

http://www.securelist.com/en/images/vlweblog/cve-2014-0497_06.png

Code which inserts the URL passed in parameters into the shellcode (+ checks the Flash Player type and whether a debugger is present)

The third shellcode type, which is only present in some of the files, is the most interesting. Its main purpose is to use MessageBox to display a dialog window with the following strings:

«Oops – what happened ?X “

«You have been owned by CorelanX »

It is not impossible that these messages are connected with the Corelan team.

As for the SWF files, we found out with the help of KSN that they were embedded into .docx documents with the following Korean names:

http://www.securelist.com/en/images/vlweblog/cve-2014-0497_07.png

A machine-generated translation of these names reads as follows: “List of the latest Japanese AV wind and how to use torrents.docx”.

We discovered that these exploits had been detected on three different user machines, one of which worked under Mac OS 10.6.8 and the other two under Windows 7. On the Mac user’s machine, the exploits were detected in an email attachment. On the Windows 7 machines, they were in a browser cache, but this does not mean the files were not loaded from an email attachment, since Outlook can call Internet Explorer components to open files. Judging by the IP addresses, all these users are located in China. The browser used was SogouExplorer, which originates from China, and the mailbox was hosted on 163.com. All of this may be an indication that the .docx document with the 0-day exploit was distributed via a targeted email mailing.

As for the payload, only one exploit included an executable file. The file is a primitive downloader which downloads several files encrypted using Microsoft CryptoAPI from a level 3 domain (thirdbase.bugs3.com) of the free hosting service bugs3.com. The downloader (detected by Kaspersky Lab products as Trojan-Downloader.Win32.Agent.hdzh) is, as mentioned above, primitive; it includes a string linking to a local pdb file on the developer’s computer –
“d:\0.Work\0.Coding\0.Workspace\downLoader\Release\dLoad.pdb” –
and uses a simple string decryption algorithm:

http://www.securelist.com/en/images/vlweblog/cve-2014-0497_08.png

String decryption algorithm in downloader dropped by an SWF exploit

We managed to obtain two executables out of (presumably) three from the server mentioned above. The first file (detected as Trojan-Spy.Win32.Agent.cjuj) steals mailbox passwords from a variety of programs (Foxmail, OperaMail, Opera, Mozilla Firefox, Safari, IncrediMail, Pidgin, Thunderbird etc.) and steals data from forms on the following login pages:

http://twitter.com
http://facebook.com
http://passport.yandex.ru/passport
http://www.yandex.ru
http://qip.ru
http://mail.qip.ru
https://login.nifty.com/service/login
http://e.mail.ru/cgi-bin/login
http://mail.ru
http://mail.126.com
http://secure.zapak.com/mail/zapakmail.php
https://lavabit.com/apps/webmail/src/login.php
http://www.bigstring.com
http://www.gmx.com
http://passport.sohu.com/indexaction.action
http://www.sohu.com
https://www.zoho.com/login.html
http://mail.sina.com.cn
http://members.sina.com/index.php
http://www.care2.com/passport/login.html
http://www.mail.com/int
https://fastmail.fm/mail
https://www.inbox.com/login.aspx
http://www.gawab.com
http://mail.163.com
http://registration.lycos.com/login.php
http://www.mail.lycos.com
https://my.screenname.aol.com/_cqr/login/login.psp
https://edit.bjs.yahoo.com/config/login
https://login.yahoo.co.jp/config/login
https://login.yahoo.com/config/login_verify2
https://login.live.com/login.srf
https://www.google.com/accounts/servicelogin

The second file, a backdoor detected as Backdoor.Win32.Agent.dfdq, works in conjunction with the first. We discovered that it uses C&C servers located at the following addresses:

sales.eu5.org
mobilitysvc.com
javaupdate.flashserv.net

In the process of analyzing the bot, we managed to receive a JPEG file with a .dll embedded in it from several servers. If the file is opened in a standard viewer, you will see an image of a heart:

http://www.securelist.com/en/images/vlweblog/cve-2014-0497_09.png

However, in reality, a dynamic library named kboc.dll (detected as Backdoor.Win32.Agent.dfdr) is extracted from the JPEG and injected into the svchost.exe process. The library communicates to the C&C; however, we have not been able to obtain any additional files. We are continuing to follow the bot’s activity.

P.S. Kudos to my colleagues Alexander Polyakov and Anton Ivanov for discovering the 0-day vulnerability.

http://www.securelist.com/en/blog/8177/CVE_2014_0497_a_0_day_vulnerability

virus and false positive problems should be posted in the. viruses and worms forum section

there is also created a topic here for posting security news. http://forum.avast.com/index.php?topic=52252.0

I think copying the entire Blog post from Kaspersky is bad form, and may even be considered a copyright infringement. Simply posting the URL would have sufficed.

Well this is more important news than the above copied report: http://krebsonsecurity.com/2014/02/adobe-pushes-fix-for-flash-zero-day-attack/
link article author Brian Krebs. We know now that Google Chrome browser came out with a special update just to fix this 0-day and have their users protected.
Java and Adobe already produced many security headache. Watch your clicks, folks.

polonus

Not ideal because the exploit was actively exploited, but the turnaround was pretty quick, less than a day from the report from Kasperky researchers to a patch released from Adobe.

Adobe updated flash for all platforms, Google just incorporated it into their version of Chrome. Usually Google updates Flash through components update system, but this was urgent enough to push a whole new Chrome update. From the blog post it didn’t mention anything about the various Sandboxes, but it seems to imply that it doesn’t matter which is disappointing.

Flash is sandboxed in Firefox for Windows Vista and up and Safari 6 I believe just recently got a Flash sandbox. Chrome and MS also sandboxes its own version of Flash for Chrome and IE on Windows 8 perspective.