By Elliot Cao
On September 18, 2018, more than a month after we published a blog revealing the details of a use-after-free (UAF) vulnerability CVE-2018-8373 that affects the VBScript engine in newer Windows versions, we spotted another exploit that uses the same vulnerability. It’s important to note that this exploit doesn’t work on systems with updated Internet Explorer versions.
Instead of modifying the CONTEXT structure of NtContinue to execute shellcode, such as in the case of the previous exploit sample, this new sample obtains execution permission from Shell.Application by modifying the SafeMode flag in the VBScript Engine. The execution of this exploit is similar to that of CVE-2014-6332 and CVE-2016-0189.
Figure 1. Code snippet of the exploit modifying the SafeMode Flag to run Shellcode
Figure 2. Code snippet showing the decoding of the PowerShell payload
When using Shell.Application or wscript.Shell to execute scripts, the VBScript engine will check the SafeMode flag to decide if the script can run. If the VBScript engine is not in safe mode, the shellcode in Shell.Application or wscript.Shell can execute directly.
Figure 3. A screenshot showing how it checks the SafeMode flag
In fact, the SafeMode flag in the VBScript Engine for the latest version of Internet Explorer (IE 11) is no longer in COleScript+0x174, so this exploit script will not work on it even without a patch. Older versions of Internet Explorer have not been supported since January 2016. However, the exploit will not work on machines with supported and patched IE versions installed.
Figure 4. A side-by-side view of the code showing the SafeMode flag in Windows 10 (left) and Windows 7 (right).
On top of this, we also found that attackers used another VBScript vulnerability, CVE-2018-8174, in a file hosted on an exploit-laced website:
Figure 5. Screenshot of CVE-2018-8174 vulnerability being used in a file hosted on the same website.
Microsoft already fixed CVE-2018-8373 in the August edition of Patch Tuesday.
Based on our previous blog analysis, VBScript!AccessArray stores the address of an array’s element in the stack. VBScript!AssignVar then triggers the call of the Default Property Get function in the script to modify the length of the array. This will free the memory of the element whose address has been saved in the stack by VBScript!AccessArray.
After patching, the SafeArrayLock function is added to lock the current array before Vbscript!AssignVar, so that the array length can no longer be modified in the Default Property Get function.
Indicators of Compromise (IoC)
Hash detected as CVE-2018-8373 Exploit (SHA256)
Related Malicious URLs: