With the leak of Hacking Team's data, the security industry came to learn about multiple new 0day vulnerabilities targeting Flash, Internet Explorer, Android, etc. As always, exploit kit authors were quick to incorporate these 0day exploits into their arsenal.
In this blog, we will be looking at the CVE-2015-5119 exploit payload that we have now seen in the wild. The sample has multiple layers of obfuscation and packer routines. The malicious Flash payload is packed, XOR'ed and stored as a binary data inside a parent Flash file that dynamically unpacks a malicious Flash file and writes it to memory at run time.
In this blog, we will be looking at the CVE-2015-5119 exploit payload that we have now seen in the wild. The sample has multiple layers of obfuscation and packer routines. The malicious Flash payload is packed, XOR'ed and stored as a binary data inside a parent Flash file that dynamically unpacks a malicious Flash file and writes it to memory at run time.
Here is the structure of the CVE-2015-5119 exploit payload:
Packages, properties and method names are stored in variables for obfuscation:
Here we observe the calling of the unpack routine to decrypt the embedded SWF exploit payload:
An XOR key is used for unpacking and is hardcoded and assigned to the variable vari_10. This is what the unpacked content looks like:
Upon decompilation, it is apparent that majority of the codebase, including variable names and function names are the same as what we saw in the leaked source by the Hacking Team. The public exploit also has checks for:
- Presence of a debugger
- Operating System bitness (32-bit or 64-bit)
When the program execution starts, the ActionScript looks for the input parameters and based on it, sets a variable which is then sent to the main exploitation routine as seen below:
The TryExpl() routine allocates sequential pages of memory and begins the exploit cycle:
The vulnerability lies in making use of the valueOf property and corrupting the vector space so that the valueOf property will overwrite the length field of the vector object, which will be further used to get access to vtables.
Here is explicit definition of valueOf function
prototype.valueOf() is setting up the length of the ByteArray to 4352
Once the memory allocation is done, a MyClass object is created and assigned to _ba[3]. The
valueOf() function defines the length of ByteArray to 4352, which is greater than the length of the object created, causing reallocation of bytes inside the memory.
If the value of _ba[3] is set to zero after the assignment then it was successful in triggering a Use After Free vulnerability. The exploit code looks for the kernel32.VirtualProtect() (VP) function in the corrupted vector space as seen below:
A call to the VP function is made, which replaces the vtable pointer and sets the PAGE_EXECUTE_READWRITE permission before executing the final payload.
Hashes of CVE-2015-5119 exploit payloads seen in the wild:
- 061c086a4da72ecaf5475c862f178f9d
- 079a440bee0f86d8a59ebc5c4b523a07
- 16ac6fc55ab027f64d50da928fea49ec
- 313cf1faaded7bbb406ea732c34217f4
- 6d14ba5c9719624825fd34fe5c7b4297
Conclusion
It will be a challenge for security vendors to get container file detection in place as majority of the time, the embedded content is highly obfuscated with multiple levels of packing. Adobe has already released a patch to fix this issue. We highly recommend enabling the Adobe's auto update feature to keep the relevant plugins updated.
References:
