{"id":6324,"date":"2017-01-23T15:50:22","date_gmt":"2017-01-23T23:50:22","guid":{"rendered":"http:\/\/www.palada.net\/index.php\/2017\/01\/23\/news-162\/"},"modified":"2017-01-23T15:50:22","modified_gmt":"2017-01-23T23:50:22","slug":"news-162","status":"publish","type":"post","link":"http:\/\/www.palada.net\/index.php\/2017\/01\/23\/news-162\/","title":{"rendered":"Reverse-engineering DUBNIUM\u2019s Flash-targeting exploit"},"content":{"rendered":"

The DUBNIUM campaign in December involved one exploit in-the-wild that affected Adobe Flash Player. In this blog, we\u2019re going to examine the technical details of the exploit that targeted vulnerability CVE-2015-8651<\/a>. For more details on this vulnerability, see Adobe Security Bulletin APSB16-01<\/a>.<\/p>\n

Note that Microsoft Edge on Windows 10 was protected from this attack due to the mitigations introduced into the browser.<\/p>\n

 <\/p>\n

Vulnerability exploitation<\/h2>\n

Adobe Flash Player version checks<\/h3>\n

The nature of the vulnerability is an integer overflow, and the exploit code has quite extensive subroutines in it. It tries to cover versions of the player from 11.x to the most recent version at the time of the campaign, 20.0.0.235.<\/p>\n

The earliest version of Adobe Flash Player 11.x was released in October 2011 (11.0.1.152) and the last version of Adobe Flash Player 10.x was released in June 2013 (10.3.183.90). This doesn\u2019t necessarily mean the exploit existed from 2011 or 2013, but it again demonstrates the broad target the exploit tries to cover.<\/p>\n

\"Figure<\/a><\/p>\n

Figure 1 Version check for oldest Flash Player the exploit targets<\/p>\n<\/div>\n

 <\/p>\n

Mainly we focused our analysis upon the function named qeiofdsa<\/em>, as the routine covers any Adobe Flash player version since 19.0.0.185 (released on September 21, 2015).<\/p>\n

\"Figure<\/a><\/p>\n

Figure 2 Version check for latest Flash Player the exploit supports<\/p>\n<\/div>\n

 <\/p>\n

Why is this version of Flash Player so important? Because that is the release which had the latest Vector<\/em> length corruption hardening applied at the time of the incident. The original Vector<\/em> length hardening came with 18.0.0.209 and it is well explained in the Security @ Adobe blog https:\/\/blogs.adobe.com\/security\/2015\/12\/community-collaboration-enhances-flash.html<\/a>.<\/p>\n

The Vector<\/em> object from Adobe Flash Player can be used as a corruption target to acquire read or write (RW) primitives.<\/p>\n

This object has a very simple object structure and predictable allocation patterns without any sanity checks on the objects. This made this object a very popular target for exploitation for recent years. There were a few more bypasses found after that hardening, and 19.0.0.185 had another bypass hardening. The exploit uses a new exploitation method (ByteArray<\/em> length corruption) since this new version of Adobe Flash Player.<\/p>\n

Note, however, that with new mitigation from Adobe released after this incident, the ByteArray<\/em> length corruption method no longer works.<\/p>\n

To better understand the impact of the mitigations on attacker patterns, we compared exploit code line counts for the pdfsajoe<\/em> routine, which exploits Adobe Flash Player versions earlier than 19.0.0.185, to the qeiofdsa<\/em> routine, which exploits versions after 19.0.0.185. We learned that pdfsajoe<\/em> has 139 lines of code versus qeiofdsa<\/em> with 5,021.<\/p>\n

While there is really no absolute way to measure the impact and line code alone is not a standard measurement, we know that in order to target the newer versions of Adobe Flash Player, the attacker would have to write 36 more times the lines of code.<\/p>\n\n\n\n\n\n\n\n
Subroutine name<\/strong><\/td>\npdfsajoe<\/em><\/strong><\/td>\nqeiofdsa<\/em><\/strong><\/td>\n<\/tr>\n
Vulnerable Flash Player version<\/strong><\/td>\nBelow 19.0.0.185<\/td>\n19.0.0.185 and up<\/td>\n<\/tr>\n
Mitigations<\/strong><\/td>\nNo latest Vector mitigations<\/td>\nLatest Vector mitigations applied<\/td>\n<\/tr>\n
Lines of attack code<\/strong><\/td>\n139 lines<\/td>\n5,021 lines<\/td>\n<\/tr>\n
Ratio<\/strong><\/td>\n1<\/td>\n36<\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n

Table 1 Before and after Vector mitigation<\/em><\/p>\n

 <\/p>\n

This tells us a lot about the importance of mitigation and the increasing cost of exploit code development. Mitigation in itself doesn\u2019t fix existing vulnerabilities, but it is definitely raising the bar for exploits.<\/p>\n

 <\/p>\n

Heap spraying and vulnerability triggering<\/h3>\n

The exploit heavily relies on heap spraying. Among heap spraying of various objects, the code from Figure 3 shows the code where the ByteArray<\/em> objects are sprayed. This ByteArray<\/em> has length of 0x10. These sprayed objects are corruption targets.<\/p>\n

\"Figure<\/a><\/p>\n

Figure 3 Heap-spraying code<\/p>\n<\/div>\n

 <\/p>\n

The vulnerability lies in the implementation of fast memory opcodes. More detailed information on the usage of fast memory opcodes are available in the Faster byte array operations with ASC2<\/em> article at the Adobe Developer Center<\/a>.<\/p>\n

After setting up application domain memory, the code can use avm2.intrinsics.memory<\/em>. The package provides various methods including li32<\/em> and si32<\/em> instructions. The li32<\/em> can be used to load 32bit integer values from fast memory and si32<\/em> can be used to store 32bit integer values to fast memory. These functions are used as methods, but in the AVM2 bytecode level, they are opcode themselves.<\/p>\n

\"Figure<\/a><\/p>\n

Figure 4 Setting up application domain memory<\/p>\n<\/div>\n

 <\/p>\n

Due to the way these instructions are implemented, the out-of-bounds access vulnerability happens (Figure 5). The key to this vulnerability is the second li32<\/em> statement just after first li32<\/em> one in each IF statement. For example, from the li32((_local_4+0x7FEDFFD8)) <\/em>statement, the _local_4+0x7FEDFFD8 <\/em>value ends up as 4 after integer overflow. From the just-in-time (JIT) level, the range check is only generated for this li32<\/em> statement, skipping the range check JIT code for the first li32<\/em> statement.<\/p>\n

\"Figure<\/a><\/p>\n

Figure 5 Out-of-bounds access code using li32 instructions<\/p>\n<\/div>\n

 <\/p>\n

We compared the bytecode level AVM2 instructions with the low-level x86 JIT instructions. Figure 6 shows the comparisons and our findings. Basically two li32<\/em> accesses are made and the JIT compiler optimizes length check for both li32<\/em> instructions and generates only one length check. The problem is that integer overflow happens and the length check code becomes faulty and allows bypasses of ByteArray<\/em> length restrictions. This directly ends with out-of-bounds RW access of the process memory. Historically, fast memory implementation suffered range check vulnerabilities (CVE-2013-5330, CVE-2014-0497). The Virus Bulletin 2014 paper by Chun Feng and Elia Florio, Ubiquitous Flash, ubiquitous exploits, ubiquitous mitigation (<\/em>PDF download<\/em><\/a>)<\/em>, provides more details on other old but similar vulnerabilities.<\/p>\n

\"Figure<\/a><\/p>\n

Figure 6 Length check confusion<\/p>\n<\/div>\n

 <\/p>\n

Using this out-of-bounds vulnerability, the exploit tries to locate heap-sprayed objects.<\/p>\n

These are the last part of memory sweeping code. We counted 95 IF\/ELSE statements that sweep through memory range from ba<\/em>+0x121028 to ba<\/em>+0x17F028 (where ba<\/em> is the base address of fast memory), which is 0x5E000 (385,024) byte size. Therefore, these memory ranges are very critical for this exploit\u2019s successful run.<\/p>\n

\"Figure<\/a><\/p>\n

Figure 7 End of memory sweeping code<\/p>\n<\/div>\n

 <\/p>\n

Figure 8 shows a crash point where the heap spraying fails. The exploit heavily relies on a specific heap layout for successful exploitation, and the need for heap spraying is one element that makes this exploit unreliable.<\/p>\n

\"Figure<\/a><\/p>\n

Figure 8 Out-of-bounds memory access<\/p>\n<\/div>\n

 <\/p>\n

This exploit uses a corrupt ByteArray.length<\/em> field and uses it as RW primitives (Figure 9).<\/p>\n

\"Figure<\/a><\/p>\n

Figure 9 Instruction si32 is used to corrupt ByteArray.length field<\/p>\n<\/div>\n

 <\/p>\n

After ByteArray.length<\/em> corruption, it needs to determine which ByteArray<\/em> is corrupt out of the sprayed ByteArrays<\/em> (Figure 10).<\/p>\n

 <\/p>\n

\"Figure<\/a><\/p>\n

Figure 10 Determining corrupt ByteArray<\/p>\n<\/div>\n

<\/h3>\n

RW primitives<\/h3>\n

The following shows various RW primitives that this exploit code provides. Basically these extensive lists of methods provide functions to support different application and operating system flavors.<\/p>\n

\"Figure<\/a><\/p>\n

Figure 11 RW primitives<\/p>\n<\/div>\n

 <\/p>\n

For example, the read32x86 <\/em>method can be used to read an arbitrary process\u2019s memory address on x86 platform. The cbIndex<\/em> variable is the index into the bc array which is an array of the ByteArray <\/em>type. The bc[cbIndex]<\/em> is the specific ByteArray<\/em> that is corrupted through the fast memory vulnerability. After setting virtual address as position member, it uses the readUnsignedInt<\/em> method to read the memory value.<\/p>\n

\"Figure<\/a><\/p>\n

Figure 12 Read primitive<\/p>\n<\/div>\n

 <\/p>\n

The same principle applies to the write32x86<\/em> method. It uses the writeUnsignedInt<\/em> method to write to arbitrary memory location.<\/p>\n

\"Figure<\/a><\/p>\n

Figure 13 Write primitive<\/p>\n<\/div>\n

 <\/p>\n

Above these, the exploit can perform a slightly complex operation like reading multiple bytes using the readBytes<\/em> method.<\/p>\n

\"Figure<\/a><\/p>\n

Figure 14 Byte reading primitive<\/p>\n<\/div>\n

 <\/p>\n

Function<\/em> object virtual function table corruption<\/h2>\n

Just after acquiring the process\u2019s memory RW ability, the exploit tries to get access to code execution. This exploit uses a very specific method of corrupting a Function<\/em> object and using the apply<\/em> and call<\/em> methods of the object to achieve shellcode execution. This method is similar to the exploit method that was disclosed during the Hacking Team leak. Figure 15 shows how the Function<\/em> object\u2019s virtual function table pointer (vptr) is acquired through a leaked object address, and low-level object offset calculations are performed. The offsets used here are relevant to the Adobe Flash Player\u2019s internal data structure and how they are linked together in the memory.<\/p>\n

\"Figure<\/a><\/p>\n

Figure 15 Resolving Function object vptr address<\/p>\n<\/div>\n

 <\/p>\n

This leaked virtual function table pointer is later overwritten with a fake virtual function table\u2019s address. The fake virtual function table itself is cloned from the original one and the only pointer to apply<\/em> method is replaced with the VirtualProtect<\/em> API. Later, when the apply<\/em> method is called upon the dummy function object, it will actually call the VirtualProtect<\/em> API with supplied arguments \u2013 not the original empty call body. The supplied arguments are pointing to the memory area that is used for temporary shellcode storage. The area is made read\/write\/executable (RWX) through this method.<\/p>\n

\"Figure<\/a><\/p>\n

Figure 16 Call VirtualProtect through apply method<\/p>\n<\/div>\n

 <\/p>\n

Once the RWX memory area is reserved, the exploit uses the call<\/em> method of the Function<\/em> object to perform further code execution. It doesn\u2019t use the apply<\/em> method because it no longer needs to pass any arguments. Calling the call<\/em> method is also simpler (Figure 17).<\/p>\n

\"Figure<\/a><\/p>\n

Figure 17 Shellcode execution through call method<\/p>\n<\/div>\n

 <\/p>\n

This shellcode-running routine is highly modularized and you can actually use API names and arguments to be passed to the shellcode-running utility function. This makes shellcode building and running very extensible. Again, this method has close similarity with the code found with the Adobe Flash exploit leaked during the Hacking Team information leak in July 2015.<\/p>\n

\"Figure<\/a><\/p>\n

Figure 18 Part of shellcode call routines<\/p>\n<\/div>\n

 <\/p>\n

Note that the exploit\u2019s method of using the corrupted Function<\/em> object virtual table doesn\u2019t work on Microsoft Edge anymore as it has additional mitigation against these kinds of attacks.<\/p>\n

ROP-less shellcode<\/h2>\n

With this exploit, shellcode is not just contiguous memory area, but various shellcodes are called through separate call<\/em> methods. As you can see from this exploit, we are observing more exploits operate without return-oriented programming (ROP) chains. We can track these calls by putting a breakpoint on the native code that performs the ActionScript call<\/em> method. For example, the disassembly in Figure 19 shows the code that calls the InternetOpenUrlA<\/em> API call.<\/p>\n

 <\/p>\n

\"Figure<\/a><\/p>\n

Figure 19 InternetOpenUrlA 1st download<\/p>\n<\/div>\n

 <\/p>\n

This call only retrieves some portion of a portable executable (PE) file\u2019s header, but not the whole file. It will do another run of the InternetOpenUrlA<\/em> API call to retrieve the remaining body of the payload. This is most likely a trick to confuse analysts who will look for a single download session for payloads.<\/p>\n

\"Figure<\/a><\/p>\n

Figure 20 InternetOpenUrlA 2nd download<\/p>\n<\/div>\n

<\/h2>\n

Conclusion<\/h2>\n

With the analysis of the Adobe Flash Player-targeting exploit used by DUBNIUM last December, we learned they are using highly organized exploit code with extensive support of operating system flavors. However, some functionalities for some operating system are not yet implemented. For example, some 64-bit support routines had an empty function inside them.<\/p>\n

The way the shellcode is authored makes the exploit code very extensible and flexible as changing shellcode behavior is extremely simple \u2013 as much as just changing AS3 code lines.<\/p>\n

The actual first stage payload download is not just performed by a single download but are split into two.<\/p>\n

They also use the ByteArray.length<\/em> corruption technique to achieve process memory RW access. There was a hardening upon this object just after this incident and ByteArray<\/em> now has better sanity checks. Therefore, the same technique would not work as straightforwardly as in this exploit for the versions after the hardening.<\/p>\n

The exploit relies heavily on heap-spraying techniques, and this is one major element that makes this exploit unreliable.<\/p>\n

This is a good example of how mitigation undermines an exploit\u2019s stability, and how it increases exploit development cost.<\/p>\n

Due to the exploitation method it relies on for the Function<\/em> object corruption, with Microsoft Edge you have additional protection over this new exploit method.<\/p>\n

\u00a0<\/em><\/p>\n

Jeong Wook Oh
MMPC<\/em><\/p>\n

https:\/\/blogs.technet.microsoft.com\/mmpc\/feed\/<\/a><\/p>\n","protected":false},"excerpt":{"rendered":"

The DUBNIUM campaign in December involved one exploit in-the-wild that affected Adobe Flash Player. In this blog, we\u2019re going to examine the technical details of the exploit that targeted vulnerability CVE-2015-8651. For more details on this vulnerability, see Adobe Security Bulletin APSB16-01. Note that Microsoft Edge on Windows 10 was protected from this attack due…<\/p>\n","protected":false},"author":4,"featured_media":0,"comment_status":"closed","ping_status":"closed","sticky":false,"template":"","format":"standard","meta":{"colormag_page_container_layout":"default_layout","colormag_page_sidebar_layout":"default_layout","footnotes":""},"categories":[10759,10378],"tags":[666],"class_list":["post-6324","post","type-post","status-publish","format-standard","hentry","category-microsoft","category-security","tag-uncategorized"],"_links":{"self":[{"href":"http:\/\/www.palada.net\/index.php\/wp-json\/wp\/v2\/posts\/6324","targetHints":{"allow":["GET"]}}],"collection":[{"href":"http:\/\/www.palada.net\/index.php\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"http:\/\/www.palada.net\/index.php\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"http:\/\/www.palada.net\/index.php\/wp-json\/wp\/v2\/users\/4"}],"replies":[{"embeddable":true,"href":"http:\/\/www.palada.net\/index.php\/wp-json\/wp\/v2\/comments?post=6324"}],"version-history":[{"count":0,"href":"http:\/\/www.palada.net\/index.php\/wp-json\/wp\/v2\/posts\/6324\/revisions"}],"wp:attachment":[{"href":"http:\/\/www.palada.net\/index.php\/wp-json\/wp\/v2\/media?parent=6324"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"http:\/\/www.palada.net\/index.php\/wp-json\/wp\/v2\/categories?post=6324"},{"taxonomy":"post_tag","embeddable":true,"href":"http:\/\/www.palada.net\/index.php\/wp-json\/wp\/v2\/tags?post=6324"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}