hamburger

BitDam Blog

Eyal Blyachman
Eyal Blyachman
3 minutes & 43 seconds read · December 9, 2018

Exploited in a flash – CVE 2018-15982

A few days ago, a new flash zero-day vulnerability was discovered.

The attack was allegedly linked to ‘HackingTeam’, the Italian offensive cyber company that was breached about three years ago.

The sample exploits a Use After Free’ vulnerability in a Flash class named “com.adobe.tvsdk.mediacore.metadata.Metadata”. A weaponized MS Word document contains an embedded malicious SWF that exploits flash into running a shellcode.

Would BitDam detect it?

Luckily, none of our customers received this attack, but we wanted to confirm that they would have been protected if they would have received it when it was just issued.

That is why we used an older version of BitDam to scan the malicious file. We used an engine version that was never exposed to this attack. We had no doubt that BitDam would detect it, after all, that’s the “magic” about BitDam – it detects zero day attacks that it hasn’t seen before.

So we scanned the original sample of the vulnerability (Sha1-2d22bf18ab1a8db0309c477472b481b0641b9dc7) with BitDam’s old engine. Here are the scan results:

Figure 1

As expected, the BitDam engine was able to notice whitelist deviations and extract interesting information:

  1. There was a foreign commandline identified with the following commandline –
    C:\\WINDOWS\\system32\\cmd.exe /c set path=%ProgramFiles(x86)%\\WinRAR;C:\\Program Files\\WinRAR; && cd /d %~dp0 & rar.exe e -o+ -r -inul *.rar scan042.jpg & rar.exe e -o+ -r -inul scan042.jpg backup.exe & backup.exe
  2. BitDam extracted the APIs that the shellcode was using. One of those APIs was “CREATEPROCESSASTUB“.

When we tried to look at the file manually, the first thing that popped up is a document written in Russian that looks like a personal information form of a healthcare company (shown in figure2).


Figure 2

When the user allows the content to play, the malicious SWF is loaded.

Technical Drilldown

Due to the results we received from our system, the first step we took was to look for the shellcode. Figure 3 shows the call instruction within the shellcode that starts the cmd.exe process.


Figure 3

A deeper look into the extracted shellcode revealed additional functionalities and a string.

Figure 4 shows a dump of the shellcode in the memory. The string is highlighted in red and the ‘call’ instruction from before is marked in blue.

Figure 4

The highlighted string is the arguments used to create the malicious process that runs the payload.

To dig a little deeper into the shellcode, we created a very simple and small program that allocates memory in a page with execute permissions, then copies the shellcode and executes it. We changed the last byte of the execution string from ‘e’ to ‘d’ to make sure that nothing malicious will eventually run.

Figure 5 shows the code used to do that

Figure 5

In the beginning of the shellcode’s execution, the code calls a function in relative offset 0x129. The call is shown in Figure 6.

Figure 6

The function, shown in Figure 7 is what seems to be resolving of function addresses.

The highlighted section in Figure7 is the resolving of a single function, using a help function embedded in the Shellcode (at relative offset 0x59).

Figure 7

Once the attackers finished with the perquisites, the shellcode reaches the final stretch. The shellcode creates a process with the relevant parameters. The ‘call’ instruction highlighted in Figure8 calls the address pointed by ebp-24h which is CREATEPROCESSASTUB.

Figure 8

At that point, the address pointed by ESP+0x4 (see figure9) should look familiar to us. We’ve examined that memory to get the final approval.

Figure 9

That memory address does hold the commandline that we expected to see.

Decompiling the SWF resulted ActionScript and two binary data blobs. Those blobs are used as classes in the script and both are shellcodes. One is 32-bit shellcode while the other is 64-bit.

Figure 10 shows the ActionScript that checks the architecture and calls the appropriate function in accordance with the architecture.

Figure 10

That interesting vulnerability is not the first Flash exploit we encounter and probably not the last either.

When this file was initially submitted to VirusTotal towards the end of November, it had an extremely low detection rate. Today, almost any engine on it detects the file. 

Figure 11

BitDam’s proactive approach allows the detection of such threats from day one, with no need to update signatures when an attack is at your gates, or worse, already entered your organization.