Kaspersky Exploit Prevention is a component part of Kaspersky products that has successfully detected a number of zero-day attacks in the past. Recently, it caught a new unknown exploit for Google’s Chrome browser. We promptly reported this to the Google Chrome security team. After reviewing of the PoC we provided, Google confirmed there was a zero-day vulnerability and assigned it CVE-2019-13720. Google has released Chrome version 78.0.3904.87 for Windows, Mac, and Linux and we recommend all Chrome users to update to this latest version as soon as possible! You can read Google’s bulletin by clicking here.
Kaspersky endpoint products detect the exploit with the help of the exploit prevention component. The verdict for this attack is Exploit.Win32.Generic.
We are calling these attacks Operation WizardOpium. So far, we have been unable to establish a definitive link with any known threat actors. There are certain very weak code similarities with Lazarus attacks, although these could very well be a false flag. The profile of the targeted website is more in line with earlier DarkHotel attacks that have recently deployed similar false flag attacks.
More details about CVE-2019-13720 and recent DarkHotel false flag attacks are available to customers of Kaspersky Intelligence Reporting. For more information, contact: email@example.com.
If the browser version checks out, the script starts performing a number of AJAX requests to the attacker’s controlled server (behindcorona[.]com) where a path name points to the argument that is passed to the script (xxxxxxx.php). The first request is necessary to obtain some important information for further use. This information includes several hex-encoded strings that tell the script how many chunks of the actual exploit code should be downloaded from the server, as well as a URL to the image file that embeds a key for the final payload and RC4 key to decrypt these chunks of the exploit’s code.
The browser exploit script is obfuscated; after de-obfuscation we observed a few peculiar things:
- Another check is made against the user agent’s string – this time it checks that the browser version is 76 or 77. It could mean that the exploit authors have only worked on these versions (a previous exploitation stage checked for version number 65 or newer) or that other exploits have been used in the past for older Chrome versions.
- There are many functions and variables that are not used in the actual code. This usually means that they were used for debugging code and were then left behind when the code was moved to production.
- The majority of the code uses several classes related to a certain vulnerable component of the browser. As this bug has still not been fixed, we are not including details about the specific vulnerable component here.
- There are a few big arrays with numbers that represent a shellcode block and an embedded PE image.
The analysis we have provided here is deliberately brief due to vulnerability disclosure principles. The exploit used a race condition bug between two threads due to missing proper synchronization between them. It gives an attacker an a Use-After-Free (UaF) condition that is very dangerous because it can lead to code execution scenarios, which is exactly what happens in our case.
The exploit first tries to trigger UaF to perform an information leak about important 64-bit addresses (as a pointer). This results in a few things: 1) if an address is leaked successfully, it means the exploit is working correctly; 2) a leaked address is used to know where the heap/stack is located and that defeats the address space layout randomization (ASLR) technique; 3) a few other useful pointers for further exploitation could be located by searching near this address.
The exploit attempts to perform numerous operations to allocate/free memory along with other techniques that eventually give the attackers an arbitrary read/write primitive. This is used to craft a special object that can be used with WebAssembly and FileReader together to perform code execution for the embedded shellcode payload.
The final payload is downloaded as an encrypted binary (worst.jpg) that is decrypted by the shellcode.
After decryption, the malware module is dropped as updata.exe to disk and executed. For persistence the malware installs tasks in Windows Task Scheduler.
The payload ‘installer’ is a RAR SFX archive, with the following information:
File size: 293,403
The archive contains two files:
File name: iohelper.exe
File name: msdisp64.exe
Both files were compiled at the same time, which if we are to believe the timestamp, was “Tue Oct 8 01:49:31 2019”.
The main module (msdisp64.exe) tries to download the next stage from a hardcoded C2 server set. The next stages are located on the C2 server in folders with the victim computer names, so the threat actors have information about which machines were infected and place the next stage modules in specific folders on the C2 server.
More details about this attack are available to customers of Kaspersky Intelligence Reporting. For more information, contact: firstname.lastname@example.org.
This post appeared first on SecureList – Kaspersky Lab’s Cyberthreat Research and Reports