Anatomy of Flash Exploit (CVE-2015-8651) integrated into Rig Exploit Kit

Credit to Author: Pavankumar Chaudhari| Date: Tue, 25 Apr 2017 08:58:48 +0000

We all know how the infamous RIG Exploit Kit have been used to infect the end users. We are seeing a constant spike in the usage of the RIG Exploit Kit by malware actors to spread malware. Its use has been noticed in different campaigns such as EITest, pseudoDarkleech, and AFRAIDGATE. The RIG Exploit Kit is mostly used to drop ransomware on targeted machines. We have recently observed an upsurge in the usage of Adobe Flash Player Exploit (CVE-2015-8651) by the RIG Exploit Kit. The infection chain starts with a compromised web page which redirects the user to a landing page and then loads the Flash exploit as shown in Fig 1.

Fig 1. RIG Exploit Kit infection cycle

Fig 1. RIG Exploit Kit infection cycle

In this blog post, we will discuss the working of the Adobe Flash exploit (CVE-2015-8651).The Flash exploit has 5 DefineBinary tags which hold obfuscated data. After analysing the DefineBinary tags, we found that two DefineBinary tags data are encrypted by RC4 encryption algorithm and their keys are kept in other DefineBinary tags. Let’s take a closer look at these DefineBinary tags.

DefineBinary Tag-1

Fig 2. Decryption key present in DefineBinary Tag-1

Fig 2. Decryption key present in DefineBinary Tag-1

The ‘DefineBinary Tag-1’ shown in Fig 2 contains the decryption key. This key is used to decrypt the data present in DefineBinary Tag-2. After the decryption of DefineBinary Tag-2, we found the below strings.

DefineBinary Tag-2

Fig 3. Decryption of strings using Fig 2 Key

Fig 3. Decryption of strings using Fig 2 Key

Also, there was another decryption key in the ‘DefineBinary Tag-4’. This key is used to decrypt the data present in ‘DefineBinary Tag-3’.

DefineBinary Tag-4

Fig 4. Decryption Key present in DefineBinary Tag-4

Fig 4. Decryption Key present in DefineBinary Tag-4

DefineBinary Tag-3

Fig 5. Decryption of strings using the key shown in Fig 4

Fig 5. Decryption of strings using the key shown in Fig 4

The decrypted data shows strings which are used in shellcode preparation by the exploit.

The Exploit Entry Point

The code snippets in Fig 6 shows the entry point of Flash execution. In method_6 given argument -1820302796 gets XOR’ed with 0x93806237 (present in DefineBinary tag-5 data) gives the index value as ‘3’ which represents string “iQWERddQWERqd”. The _loc5_ variable holds “iddqd” which is decoded from the string “iQWERddQWERqd” after removing “QWER”. This iddqd variable holds data which is passed as a parameter to the current Flash file. Then _loc6_ variable holds hex data which is decoded by replacing “QWER” by “E” by the earlier XOR process and those strings are also stored in DefineBinary tag-3.

Fig 6. Start of exploitation

Fig 6. Start of exploitation

The function call ‘this.sdfghfghfgj’ triggers the exploit code. It performs fingerprinting and version checks to obtain the version of the installed Flash player. If a vulnerable Flash installation is found, it triggers the vulnerability and carries out heap spray. The function ‘get_big_ba’ triggers the well-known integer overflow vulnerability (CVE-2015-8651).

Fig 7. Function Call flow depicting vulnerability trigger

Fig 7. Function Call flow depicting vulnerability trigger

Exploit Checks

The function ‘is_vuln performs Exploit checks.

 Fig 8. Exploit checks

Fig 8. Exploit checks

Below are the checks:

  • Anti-debugging check
  • Operating system Version check
  • Checks if it’s a standalone player
  • Flash player version

Below is the snippet of the function ‘check_versions’ which does the Flash player version checking when it’s called.

Fig 9. Flash player version checks

Fig 9. Flash player version checks

Vulnerability

The functions related to domain memory which is responsible for the Flash exploit are defined in package “avm2.intrinsics.memory”. The package provides methods as ‘li32’ and ‘si32’ where li32 is used to load 32-bit integer values from the memory and si32 used to store 32-bit integer into the memory. The definition of ‘li32and ‘si32’ functions exploits an Integer Overflow Vulnerability (CVE-2015-8651). The detailed analysis of the vulnerability can be found here.

Fig 10. Integer overflow vulnerability

Fig 10. Integer overflow vulnerability

Upon successful exploitation of the said integer overflow vulnerability, the exploit runs a shellcode. We have observed that the shellcode generally connects to the exploit kit domain and downloads malware and executes them on the victim’s machine.

Quick Heal Detections

Quick Heal has released the following detection for the RIG Exploit Kit Flash exploit:

  • Exp.SWF.Rig.EK

As observed in Quick Heal Labs, below is the trend of the ‘Exp.SWF.Rig.EK over the last month.

Fig 11: Quick Heal Labs’ detection stats

Fig 11: Quick Heal Labs’ detection stats

Conclusion

With a limited set of reversing tools, the analysis of the highly obfuscated Flash Exploit was a bit difficult. Malware actors are using a deeper level of obfuscation to hide actual exploit from reverse engineering. Such techniques are used to evade detection at every level and will continue to evolve in the future. We strongly recommend users to update the Windows Operating System and Flash Player and use a multi-layered security software such as Quick Heal.

 ACKNOWLEDGMENT

Subject Matter Experts

  • Prashant Kadam
    – Vulnerability Research Labs

The post Anatomy of Flash Exploit (CVE-2015-8651) integrated into Rig Exploit Kit appeared first on Quick Heal Technologies Security Blog | Latest computer security news, tips, and advice.

http://blogs.quickheal.com/feed/