In September Microsoft published information about a new Internet Explorer vulnerability – CVE-2013-3893. The vulnerability affects IE versions 6 through 11 for platforms from Windows XP through Windows 8.1. Later in September, the company released a patch closing the vulnerability.
Cybercriminals are happy to exploit such vulnerabilities because they are easy to monetize – the Internet Explorer remains popular.
Top 5 browsers according to http://gs.statcounter.com
This type of vulnerability is very dangerous because it allows the execution of arbitrary code on the target system. In late September, we discovered an exploit for the vulnerability, which uses an attack of the Use After Free type against the Internet Explorer’s HTML rendering engine -mshtml.dll.
We have recently discovered that a modification of the exploit was used in targeted attacks against a number of high-profile organizations in Japan.
The vulnerability is exploited only on those computers which are part of specific subnets of the target organizations’ networks:
Defining subnets in which computers will be attacked
If a computer’s IP address belongs to one of the ranges defined by the cybercriminals, the vulnerability will be exploited after a user visits an infected web page.
The following information is obtained in the first stage of the attack:
- Operating system version
- Internet Explorer version
- Language used by the OS
- Whether Microsoft Office is installed
The exploit selects the appropriate ROP chain and shellcode based on the data obtained in this stage:
Choice of ROP chain and shellcode
It is worth mentioning that the exploit will not work on those Windows 7 systems which do not have Microsoft Office installed.
Checking OS version and whether Microsoft Office is installed
This is because today’s operating systems include mechanisms that make exploiting vulnerabilities more difficult. One of such mechanisms is ASLR (Address Space Layout Randomization). The exploit uses a clever trick to evade the mechanism: it loads a module compiled without ASLR support into the context of the browser process – the hxds.dll library.
Code after executing which hxds.dll is loaded
The library, which is part of the Microsoft Office package, does not support ASLR. It is loaded at known addresses in memory, after which the attackers use the ROP technology to mark the memory containing shellcode as executable.
The following shellcode is executed after the vulnerability has been successfully exploited:
It can be seen in the figure above that the shellcode decrypts its main part using 0x9F as key.
After decryption, the code searches for functions needed to download and launch the payload, finding them by their hashes:
Hashes of the functions used
When the search for the addresses needed is completed, the following activity takes place:
- a malicious object named “runrun.exe” is downloaded from the attackers’ server:
Downloading the payload
- Since the module downloaded is encrypted, the shellcode reads it from disk and decrypts it using 0x95 as key, after which the decrypted module is launched:
Decrypting the module downloaded
Distribution of the exploit
As mentioned above, the targeted attack used only one modification of the exploit for CVE-2013-3893. At the same time, the total number of modifications discovered to date amounts to 21. Attacks using this exploit have mostly been detected in Taiwan:
We have the following information on the servers from which the exploit’s payload has been downloaded:
A brief analysis of one of the payload’s variants (md5 – 1b03e3de1ef3e7135fbf9d5ce7e7ccf6) has shown that the executable module has encrypted data in its resources:
Encrypted data in the payload’s resources
The executable module extracts the data and converts it to a DLL module:
Extracting encrypted data
The DLL created by converting the data extracted from the payload is written to disk using the following path:
TempPath\tmp.dll (md5 – bf891c72e4c29cfbe533756ea5685314).
The library exports the following functions:
Functions exported by tmp.dll
When the library has been written to disk, it is loaded into the process’s address space and the ishk exported function is called:
Calling the ishk exported function
The library itself performs an injection into another process’s address space.
After launching, the malware communicates to a server in South Korea. The following requests are sent from the infected machine:
Requests sent from the infected machine
Kaspersky Lab detects the payload downloaded as Trojan-Dropper.Win32.Injector.jmli.
We detect the exploit as HEUR:Exploit.Script.Generic.