Introduction
Over the last couple of months, we’ve seen several new waves of Dridex banking malware where on the latest c, a new RTF 0-day vulnerability was successfully exploited and used against millions of targets, mainly in Australia, as spotted in the wild.
The primary objective of Dridex malware is to steal banking information from users of infected machines to immediately launch fraudulent transactions. Bank information for the software installs a keyboard listener and performs injection attacks. During 2015, theft caused by this software were estimated at £20 million in the United Kingdom and $10 million in the United States. By 2015, Dridex attacks had been detected in more than 20 countries. In early September 2016, researchers spotted initial support for targeting crypto-currency wallets. [Wikipedia]
The infection was done using file, with , leveraging a logical bug in Microsoft Word where a special OLE object is being embedded.
Embedding OLE objects in RTF
As described in the RTF specification, OLE objects can be easily embedded, utilizing pre-installed piece of software, linking container document with additional functionality.
You can find below useful keywords for such embedded objects.
RTF Specification from http://latex2rtf.sourceforge.net/RTF-Spec-1.0.txt
Dridex embedded malicious OLE object
We gathered a sample of the 0-day and ran it through Votiro’s research lab analysis, approving that this is indeed a new attack method, bypassing most of the security defenses today including Sandboxes and all endpoint memory based mitigation techniques.
As you can see in the snippet below, the offending OLE object is marked in yellow.
The Logical Bug
As originally reported by and acknowledged by Microsoft, the bug is a logical issue in Microsoft Word and the Mshta.exe component.
Mshta.exe is responsible for handling the Content-Type “application/hta,” parsing the content, and executing the script. Winword.exe parses the OLE object instruction, queries a remote server for an external content where the server returns an “application/hta” that eventually invokes to execute mshta.exe. Mshta.exe then executes any code that is embedded in the malicious HTA document. The interesting thing in the bug that it’s pure logical and none of the memory based endpoint mitigations cannot detect it, as it’s not involves any memory corruption or overrun.
Mitigations
approach is to disable RTF files from being loaded by setting the following registry keys, as offered by @ryHanson, by setting: Software\Microsoft\Office\15.0\Word\Security\FileBlock\RtfFiles to 2 and OpenInProtectedView to 0.
Another approach to mitigate those kind of attack is to perform a of document formats such as RTF. Using Advanced CDR image module, that supports RTF and many other document formats, the OLE objects are carefully examined as the document is being re-built from scratch, eliminating any non standard or documented attributes, values, and OLE objects without requiring any signature or learning.
I’ve used API (api.portal.votiro.com) and uploaded the same CVE-2017-0199 sample to Votiro’s service. The safe document was retrieved in less than a second and as expected, the faulty OLE object was removed automatically as expected.
In the Virustotal.com snippet above, you can find that the re-generated document is free of any malicious component and can be safely opened.
Advanced CDR technology
CDR or Content Disarm and Reconstruction approach, as designed by , could be a solution to this and many other security holes that hackers can take advantage of. CDR involves disarming potential exploits by dissecting files (like RTFs) and perform thorough analysis. The system is able to determine the implications of modifications, whether it was written to specifications, whether it needs to be patched, etc. Once analyzed – and vetted for proper form and safety – the file is reconstructed and passed onto the system, keeping all functionality intact, while disarming any malicious, suspicious or potentially harmful objects.
With Votiro’s Advanced CDR technology, the solution moves from detection to ; instead of tracking down problems and retroactively solving them, Advanced CDR puts the onus on files to “prove” that its code is proper; without that proof, CDR will simply dismiss the file, and it won’t have its opportunity to cause mayhem – or potential mayhem, as in the case listed here. While no reports have come in of hackers using the vulnerability to carry out malware attacks, that could just be because security firms haven’t connected all the dots yet. It may yet come to light that malformed file such as RTFs are a major risk – but for companies that have a CDR system in place, it won’t make a difference how widespread the vulnerability is; they’re safe.