We recently observed RIG exploit kit delivering Adobe Flash exploit that takes the advantage of Integer overflow vulnerability CVE-2015-8651 in the Adobe Flash and delivering the malware on the infected system. I got the opportunity to analyze the Rig exploit kit infection chain and the delivered exploit.
Infection starts when user accesses the link which initiates the “GET” request to “signup1.php” to the IP: 194.58.40.252. Current Whois information of this IP reveals that this server is hosted in Russian Federation
This web server was compromised which possibly would have been a part of the malvertising campaign, and the page was modified to inject the malicious iframe which would redirect the browser to the Exploit kit landing page.
Once the Browser is redirected to the landing page, server responds with the obfuscated JavaScript. Purpose of the JavaScript is most likely to determine the type and version of the browser running according to which the exploit will be delivered in subsequent stage.
Below is the part of the Deobfuscated JavaScript that contains the URL to request the flash exploit from the hosting server.
Subsequently, the Flash exploit is delivered to the victim machine that exploits the Adobe flash vulnerability. Below communication with the server depicts the clear picture of the flash file being delivered to the user.
Flash exploit triggers CVE 2015-8651 vulnerability post which the encrypted payload embedded in the flash file is executed.
Below picturizes the entire infection cycle of the Rig exploit kit.
Vulnerability exploited and the root cause
Vulnerability exploited by the delivered flash exploit: CVE 2015-8651. This vulnerability is due to the Integer overflow in Intrinsics Memory / Fast Memory opcode generation by ActionScript Virtual Machine JIT compiler.
Analysis of the exploit:
Execution of the ActionScript starts with the Init() method as show below which passes “-1820302793” which is 0x93806237 as the argument in the method_10 of the class 3 , where it gets XORED with the var_7 which is set in the method_1 by reading 32 bit Unsigned Integer from the ByteArray Class. The returned value is a string in which “QWERTY” is then replaced with “E” and subsequently appended to the var_209 . This resultant string is then stored in _loc_5_ which stores the decrypted shellcode and passed as the parameter to the sdfghfghfgj() function where ultimately exploit is triggered .
Function sdfghfghfgj() is the one that initiates the vulnerability triggering flow . This function calls the run () function internally which in turn executes the vulnerability check function “is_vuln()’ . Latter checks for the Windows version, flash versions and then prepares to triggers the vulnerability, and eventually triggers Integer overflow by calling the method get_big_ba()
As indicated earlier, function sdfghfghfgj() creates the instance of the class “world” which calls the prepare() method in the constructor to check for the following :
- Debug version checks
- Determine the flash player type
- Get the flash player version
- Get the OS type
Below is the code snippet performing above mentioned checks.
Vulnerability:
Adobe implemented a feature in the Adobe Flash Player called “DomainMemory” which was primarily used by developers to gain the fast read and write access to the domain memory. Domain memory opcodes are provided by the package avm2.intrinsics. memory. This package provides the methods to load / store integers to byte streams like ByteArrays. Integer overflow vulnerability lies in the way these Domain Memory opcodes are generated by Action Script Compiler (ASC). As seen below, Flash exploit imports these packages and specifically li32 and si32 which is used to load and store 32-bit unsigned integers into the memory.
Below is the documented list of Domain Memory opcodes provided for faster read and write access to ByteArrays.
Vulnerability existing in these si32 and li32 domain memory opcodes allows the attacker to perform arbitrary read and writes into the memory.
Triggering the Integer Overflow:
As indicated in the previous figure get_big_ba() function within the exploit is responsible to trigger the Integer overflow condition. In this function, first the several ByteArray objects is sprayed on the heap and then ByteArray.Length is corrupted. Domain memory data is initialized after that in the function make_big_ba() and then eventually confuse_ba() function is called where it is able to perform out-of-bounds read and write in the calls read_int_overflow() and write_int_overflow() respectively. However, the latter calls will achieve the arbitrary memory read /write using si32_overflow () and li32_overflow ().
Bypassing windows Mitigations to execute shellcode
Let's take a detailed look at how this flash exploit bypasses windows mitigations
Bypassing ASLR:
Exploit performs the ASLR bypass by creating the information leak. It leaks the address of the Initialized ByteArray object by calling the method get_obj_addr() and eventually gets the address of the objects’ virtual function table which is later corrupted by writing the address of VirtualProtect() API. As described in the earlier section, world:run_payload() method triggers the execution of the shellcode before which the mitigations are bypassed. In the run_payload() function , init_ba() function is called which initializes the ByteArray and ByteArray.Length is corrupted to gain RW primitives.
Below code snippet from the find_data() reveals the leaking of ByteArray object address.
Subsequently in the run_shell() function, find_virtprot() is called which resolves the address of the VirtualProtect () API leading to the ASLR bypass. Below is the code performing the address resolution.
In the subsequent code, address of the VirtualProtect () API is written using the acquired RW primitives [ write_uint() ] following which the arguments to the API are pushed.
In the following code, apply() method is called on the function object which will execute VirtualProtect () API and marks the shellcode buffer as RWX achieving DEP bypass.
Finally call() method is invoked on the dummy object, which will execute the shellcode as shown in the code below.
Details on the call() method of the function object as described by Adobe:
Intention and analysis of Shellcode
Once the shellcode is executed, it would connect and download additional malware from the attacker-controlled server. Debugging the Action Scripts with the AS debugger reveals that the shellcode embedded in the DefineBinaryData 1 tag of the flash file is decrypted with the key and then XORed with 0x84 during the execution.
Below is the snapshot of the code that decrypts the shellcode when the init() method is called initially.
During the execution , shellcode is then XORed with 0x84 as shown below.
Once code is XORed , it will execute and drop the JavaScript in the “Temp” directory, which is finally executed using the windows wscript engine with the command “wscript //B //E: Jscript o32.tmp”. Below is the XORed code.
Indented JavaScript is as show below for readability.
From the dropped JavaScript, it is apparent that exploit is downloading additional malware [ a DLL ] from the attacker controlled server and then executes it using “regsvr32.exe /s ” command.
Posts
