0
1
Before diving into the analysis of CVE-2018-4878, a quick reminder that this is the continuation of our previous post, which provided background on CVE-2018-4878, including a video of how Morphisec prevents any attacks leveraging this Flash vulnerability. Morphisec prevents the attack at all phases and components in the attack chain – during the exploit, the shellcode, as well as the malware which is executed using wbscript.exe with additional in-memory command control code.
At the time of the previous post, the vulnerability was still a zero-day. Adobe released a new version that fixed the flaw yesterday. With that fix available, Morphisec is now free to release technical details of the attack.
Set-up of Analysis
Although in this overview we focus mainly on the 32 bit exploitation flow, the original exploit was implemented to support both 32 and 64 bit browsers. The exploit included adaptation of offsets for shellcode to cope with the difference in the file header structures (e.g. Import Address table pointer is with a higher offset for 64 bit process from the NT header) as well as many other adaptations during the pointer leakage.
It is also important to mention that the exploit writers didn’t delete debug symbols from the Flash and therefore it was much easier to de-obfuscate the object.
We will not focus on the malspam document that delivered a Flash wrapper; this Flash object is now inactive due to the fact that the decryption key for the inner exploit presented here was only delivered during the activity of the C2.
This document focuses solely on the already fully decrypted working exploit. For those interested, Proof of Concept details can be found in a separate section toward the end of this report.
Structure Overview
After decrypting the exploit from the encrypted Flash wrapper, we identified action script files to handle 32 and 64 bit browsers. We also identified 2 blobs relevant for the 32 and 64 bit shellcodes (in our walkthrough we deleted the 64 bit files and blob to make it easier for the reader, we also renamed many of the variables for the same reason).
In this stripped and de-obfuscated form, the exploit is well structured. It, starts from the Main class that initializes the shellcode blob to a local variable and forwards the flow to the next stage of utilizing the vulnerability by triggering Use After Free on a DRM Operation object (UAF).
UAF Triggering
As shown in the screenshot, first a DRM Listener object is created and pointed to by “var_13”– eventually this pointer points to a “free” memory (as part of use after free – this one is usable).
Then the attacker creates a MediaPlayer and initializes the player’s DRM manager with a new DRM operation listener object. Immediately after, it triggers the “free” of the DRM object by assigning it a null value, while the Media player DRM manager points to it.
To read the original article:
https://blog.morphisec.com/cve-2018-4878-an-analysis-of-the-flash-player-hack
