Read the original article: Internet Explorer CVE-2019–1367 Exploitation — part 1
Internet Explorer CVE-2019–1367 Exploitation — part 1
Extracting the Exploit from the PCAP
In this section we will go through the process of extracting the exploit from the pcaps generously provided by malware-traffic-analysis.
Luckily for us the pcaps contain the traffic of a successful exploitation of a target!
This will help us to get what further network requests were made after a successful exploitation and shellcode execution, ultimately to get to the dropped payload (that is in the pcap as well!)
Looking at the first HTTP request, we can see Accept-Language: ko-KR, a good indication that it is targeting Korean users. This is in line with Magnitude Exploit Kit targeting :
base64 only data is returned, typical to Magnitude Exploit KIT landing page:
Decoding it will give us a stage 2, obfuscated:
stage 2 use some simple de-obfuscation steps to ultimately see a final request to b6883l0bak[.]pophot.website, returning Jscript encoded data and setting IE8 compatibility mode :
Note: By default, IE11, IE10, and IE9 uses Jscript9.dll which is not impacted by CVE-2019–1367 vulnerability. Setting IE8 compatibility mode, will force IE browser to use the legacy jscript.dll ( and trigger the vulnerable code of CVE-2019–1367 bug)
We decoded this Jscript.Encode encoded data using Windows Script Decoder 1.8 tool that can be found here: https://gist.github.com/bcse/1834878
After decoding, we are greeted with the full CVE-2019–1367 exploit, but obfuscated:
The exploit comes with some of the native javascript functions encoded, obfuscating the real nature of the script. but still we can spot the vulnerable Array.Sort() function , and the use of the Enumerator object, and subsequent calls to CollectGarbage() for some heap feng shui!
Understanding the vulnerability
When dealing with unknown vulnerabilities, Patch diffing or debug trace diffing aka differential debugging are used to detect the root cause and this is usually the way to go to find vulnerable code path(s) or understand a recent patch intended to kill a bug. F-secure did a write up analyzing CVE-2020–9674 using differential debugging.
To put it in simple words, CVE-2019–1367 is caused by Jscript’s Garbage collector (GC) that doesn’t track properly the arguments of Array.sort() callback function.
Not updating the reference count of a currently in-use object. This results in the object currently in-use to be prematurely freed.
In other words, the arguments of Array.sort() callback function will be pointing to a prematurely freed memory allocation after calling Garbage collection this is also knowns as dangling pointer.
Why this is a big deal? Well if we can somehow replace the memory pointed by this dangling pointer (and we will see this in part2, the exploitation part) by an object we control we can start executing our own code : which is typically a shellcode that will execute and perform tasks like: Popping a calculator, or /*spoiler alert*/ downloading a ransomware as we will see in part 3.
We can write a minimalistic proof of concept to quickly demonstrate this vulnerability with the elements we have until now. We will create an empty array to be able to call Array.sort() function, save a references to arguments, force garbage collection, then try to access to the saved references again and see what happens.
CVE-2019–1367 proof of concept
Below is our proof-of-concept for CVE-2019–1367. We allocated enough objects to allocate more than 50 GC blocks. Why 50? If we look at the GcBlockFactory::freeBlk method in Jscript.dll we can see that GC maintains a list of 50 free GC Blocks. When garbage collection is called, GC blocks marked as free will be added to this list, if the counter of the free block is ≥ 50 then next free blocks won’t be added to the block list, but will get directly deallocated:
The garbage collection process in jscript.dll is based on the mark-sweep algorithm :
In IE Jscript engine this can be translated to 3 different steps:
- Step 1: Mark all the VARs. The marking is done via | 0x881.
- Step 2: Scavenge functions are called for each VARs object (each object have its scavenge function implemented) Which consist of checking if any references to these marked objects do exist, if it’s the case then the objects are unmarked.
- Step 3: Reclaim Garbage is called to free all the marked VARs. Note: A whole GC block is Freed if all of its VARs are marked and therefore freed.
We can write a proof-of-concept where we will allocate more than 50 GcBlocks, and keep a reference of one of the Objects in Arguments, trigger garbage collection and access to that reference again via Alert() to trigger the bug.
We did a test on both IE8 and IE11 with the below code:
In IE8, we get a crash (tested on Windows 7 SP1 32bits)
IE11 the current tab crashes then get reloaded (tested on Windows 10 x64)
Attaching WinDBG to IE11 with page heap enabled, we can this time catch the exception as we can see in the trace below where EDI points to an unspecified memory address 0x23d28a30:
Analyzing 0x23d28a30 memory address we can see it is pointing to a memory address belonging to a memory block that got freed. In the stack trace, we can notice the calls to GcAlloc::ReclaimGarbage and especially GcBlockFactory::FreeBlk that was responsible for freeing the block:
With this minimal Proof of concept, we confirmed the use-after-free vulnerability, addressed by CVE-2019–1367.
This use-after-free bug can be exploited and that is covered in part2.
Readers can go to part3 for the shellcode analysis, resulting from a successful exploitation of this bug!
Internet Explorer CVE-2019–1367 Exploitation — part 1 was originally published in Confiant on Medium, where people are continuing the conversation by highlighting and responding to this story.
Read the original article: Internet Explorer CVE-2019–1367 Exploitation — part 1