Flash Threats: Not Just In The Browser

July has been a fairly poor month for Adobe Flash Player security, to say the least. Three separate zero-day vulnerabilities (all courtesy of the Hacking Team dump) have left many people concerned about Flash security, with many (including this blog) calling for it to go away.

Some sort of reaction from Adobe to improve Flash security was inevitable. The recent version of Flash, version (18.0.0.209), includes several additional mitigation techniques. These were developed by Adobe, working together with Google’s Project Zero.

The new exploit mitigation techniques are:

Vector.<*> length validation – adds a length cookie to the Vector buffer. If an exploit overwrites the Vector length, the cookie checking will cause a failure. Because every Flash exploit today uses overwrites the Vector length, this mitigation point makes Flash exploit harder, and can stop even undisclosed zer0-day exploits.
After adding the length cookie check, an attacker needs two vulnerabilities to carry out an attack – one to leak the length cookie, and another to overwrite the length. A single vulnerability that can both leak and overwrite this field can also be used, but this kind of vulnerability is rare.
Vector.<uint> buffer heap partitioning – this mitigation makes leaking cookies and overwriting the vector length harder. Specific vulnerabilities are now needed instead of generic information leak and overwrite vulnerabilities.
stronger randomization for the Flash heap – this mitigation point makes leaking cookies and overwriting the vector length harder, because the heap layout is harder to predict than before.

These techniques mitigate exploits fairly effectively, as it can decrease the number of exploits using vector length overwrite techniques. However, note that these are exploit mitigation techniques: in effect, it’s a band-aid on any vulnerable code. Other attempts at exploit mitigation (such as that done on Internet Explorer by Microsoft in 2014) have added mitigation techniques and fixed the underlying code. In the IE example, most IE UAF vulnerabilities became NULL pointer dereferences.

Not all vulnerabilities can be mitigated in this manner. If attackers were able to find a new class of potential Flash vulnerabilities that bypass these steps, we could be back in a situation where similar vulnerabilities appear in relatively close succession. Alternately, it may become the case that each exploit is essentially “from scratch” and does not rely much on what was found

Not all of these protection techniques apply to all browsers. Vector.<*> length validation is available to other browsers; however the other techniques are not. Users on other browsers are not yet fully protected, although they will be next month.

Hacking Team, Targeted Attacks, and Flash: Exploits Beyond the Browser

While these additional mitigation techniques are useful and can reduce the problems that users face, however Flash is now being targeted for exploitation outside of the browser. It is now being embedded into Office documents; this allows many of these defenses to be bypassed.

Once again, credit for this “discovery” must go to the people over at Hacking Team. Trend Micro has noticed that some of these zero-day vulnerabilities, CVE-2015-5119, has been adopted in targeted attacks. Emails spoofing the Taiwanese government that contain a malicious attachment have been spotted in the wild, as seen below:

Figure 1. Spoofed email

At first glance it would appear to be a perfectly ordinary targeted attack email, complete with a malicious email. We believe that this particular sample has links to the PLEAD campaign which we found last year. In addition, we believe that it can now target 64-bit versions of Windows as well as Mac OS X:

Figure 2. Windows x64/OS X

However, what is more interesting is these malicious attachments do not target Microsoft Office vulnerabilities at all. These Office documents contain an embedded Flash file which contains an exploit. If this exploit is successful, it is then used to download and run the actual malware payload.

Figure 3. Successful exploit with an Internet Explorer process (Click to enlarge)

Builder tools

How was this attack carried out? The attackers appear to have been inspired by the Hacking Team, which used a very similar method. Based on correspondence and files from the Hacking Team leak, we learned that the attackers used automated builders to help automate their attacks. The following diagram shows how this builder was actually used:

Figure 4. Builder usage

The attackers would provide a “clean” Office document they would use for the attack, the Flash exploit, and the actual malware payload. The builder would create the documents with embedded Flash files, as well as the files that need to be uploaded to a malicious or compromised server of the attacker’s choosing.

There is one key difference in how the attacks we encountered and how the Hacking Team designed their attacks. The files we saw had the Flash exploit embedded directly. The Hacking Team builder embeds a Flash file which downloads a separate Flash exploit. This has the advantage of not placing any exploit code inside the Flash file which may be detected.

While the Flash files and the payload do not have to be in the same directory, the builder is designed to place them in the same location.

The builder is also designed to help make detection and analysis of the malware used more difficult:

Network traffic uses HTTPS to encrypt its traffic, making detection by network security solutions such as Deep Discovery more difficult.
A random 4-byte key and the XOR function is used to encrypt the malware used.

Best practices

A key part of Flash-related best practices to date has been to keep it up to date and use click-to-play in browsers (or to disable it entirely). However, these controls only work with attacks that use Flash via the browser. Solutions that use Flash via Microsoft Office would not be affected, so users can be affected even if they think they are “safe”.

Security-conscious users should consider completely disabling Flash on their systems, and uninstalling it if possible. Windows users may also opt to use kill bits to disable Flash from running on their systems at all.