We have found an interesting discrepancy in how the Angler exploit kit targets Adobe Flash.
The Angler exploit kit is known for its use of various Adobe Flash Player exploits. Reports have indicated that Angler has started targeting CVE-2015-0359, a vulnerability that was fixed in Adobe’s April 2015 update. CVE-2015-0359 is a race condition vulnerability that occurs because ByteArray::Write is not thread-safe, and it requires many workers to trigger. However, in the sample that we analyzed, the current exploit used by Angler is a use-after-free (UAF) vulnerability related to domainMemory and is easier to trigger, opening the possibility that an already known and patched vulnerability is being exploited.
Instead of CVE-2015-0359, the execution flow of the Flash exploit that we saw is very similar to that used by CVE-2015-0313:
- A shareable ByteArray object is set to be shared between the main thread and worker thread by calling setSharedProperty.
- Set this shareable ByteArray object memory to domainMemory.
- A worker thread gets the shareable ByteArray object through worker shared property by calling getSharedProperty, and the execution flow is dependent on the Flash player version. If the version of Flash present is vulnerable to CVE-2015-0313 vulnerability, it then calls ByteArray::Clear; if not, it calls ByteArray::WriteBytes
Figure 1. Difference between this sample and CVE-2015-0313
The difference between this new exploit and CVE-2015-0313 is that it will call ByteArray::WriteBytes to cause the underlying buffer change, and this change is not notified to domainMemory (which will still point to the freed memory). This will cause a UAF vulnerability. An attacker can use intrinsic instructions to read and write from the freed memory address. In effect, it is the same kind of flaw as CVE-2015-0313, except a different function is called to trigger it.
It is not clear why it is thought that the newer exploit used by Angler targets CVE-2015-0359. Perhaps it may have been a happy coincidence that the fix for CVE-2015-0359 also fixed this UAF vulnerability; given that the race condition vulnerability does use the ByteArray::WriteBytes function as well that is a distinct possibility.
We are working with Adobe to clarify the scope of this vulnerability.
Additional analysis by Brooks Li and Joseph C. Chen
Related SHA1 of the Flash sample is as follows:
- E0C46A5BF1F98C0BF5F831E7AD1881502809DA93 – detected as SWF_EXPLOIT.CAK