Windows Vulnerability Exploits Technology summary

Source: Internet
Author: User
Tags new set

Windows Technical summary of exploit exploits

1. Preface

This article is my study summary of exploit technology, and also the practice of practicing qad (Questions, Answer, discussions). This article by reading a few Daniel's articles, lecture reports, exploit writing tutorials and other technical documents are constantly summarized and modified, listed the current Windows common attack mitigation technology basic principles and bypass method, the specific technical details are not described in detail, you can use reference literature or other articles to further study. Due to my limited ability, there may be many errors in the text, I will continue to review and improve.

2. Introduction to Windows Attack Mitigation Technology

Since Windows became a mainstream operating system, exploit technologies for the Windows platform have evolved, and Microsoft has been using new attack mitigation technologies to block exploit technologies. Based on the time sequence introduced to Windows, the following attack mitigation techniques have been introduced: GS (Control Stack Checking Calls), SafeSEH (Safe structured Exception Handler), Heap Protection, DEP (Data execution Prevention), ASLR (Address Space Layout randomization), and more.

The following is an example of these protection mechanisms and their bypass method to further explain

int Main (intChar * *argv) {    char buf[];    __try    {        memcpy (buf, argv[1], ATOL (argv[2]);    }    __except (exception_continue_search)    {    }    return0;}

The vulnerability of this example is obvious, so let's explain how to take advantage of this example's stack overflow vulnerability when different protection mechanisms are turned on.

    • No attack mitigation measures

If no protection mechanism is turned on when compiling the link, we only need to overflow the buf, overwriting the return address to point to the predictable shellcode address. Here I overwrite the return address of the main function with the address of the JMP ESP directive (any one of the JMP ESP instructions in memory, in the current process's own DLL), overwriting the subsequent stack space with Shellcode.

When the main function returns, it pops the return address (which is already the address of jmp ESP) from the stack and jumps to it to continue execution. When the JMP ESP instruction is executed, the EIP points to the current stack, at which point the program execution flow is transferred to the stack that has overflowed, and Shellcode is executed.

    • Gs

The GS (Control stack Checking Calls) is an attack mitigation technology for stack overflow, which protects stacks primarily through stack cookies and variable reordering two of techniques.

  Stack Cookies are a runtime stack overflow detection technique provided by the compiler, and the compiler that turns on the/GS option detects a stack overflow by adding a block of code to the head and tail of the function. When the function executes, this code saves a random value (that is, the stack cookie) between the stack local variable and the function return address. When the function returns, it checks to see if the random values stored in the stack have been modified, which means that a stack overflow has occurred, which stops the program from running and prevents malicious code from executing.

  Variable reordering is a technique that minimizes stack overflow corruption during the compilation phase by rearranging the order of variables. It rearranges local variables, placing a variable of type string buffer on a stack address space higher than other types of variables, preventing an attacker from overwriting other local variables by spilling a string buffer and gaining control before the stack cookie is detected. At the same time, Variable reordering copies the pointer in the function parameter, the string buffer to the additional allocated stack address space above the local variable, and the function does not use the parameters that were originally located behind the return address.

The following is a function stack layout protected by GS

Figure 2?1

For programs that turn on GS protection, you can overwrite the she record on the stack by spilling buf, because the GS does not protect the she record on the stack. At the same time, the attacker triggers an exception before the stack cookie is checked, gaining control over the rewritten she record.

Here, we make sure that the modified she record---handler is the address to the pop-pop ret instruction string (Note that you need to ensure that this instruction string is in a module that does not have SAFESEH protection, otherwise the exception distribution function validates it) and she record- Nextseh rewritten to Jumpcode (short jmp X).

A pop pop ret is executed when the function has an exception (can overflow a large amount of data through buf, making strcpy access to the bottom of the stack) and thus index the SEH exception handler function. This sequence of instructions pops the Nextseh address from the stack (at which point the Nextseh is the jump instruction Jumpcode) to the EIP, and after the Jumpcode is executed, it jumps to Shellcode to get the Execute permission.

Figure 2?2

    • GS & SafeSEH

SafeSEH (Safe structured Exception Handler) is an attack mitigation technique for she exception handling that prevents an attacker from overwriting the Exception Handler record on the stack to gain control. It includes validation for SEH exception handling functions (SHE Handler Validation) and validation for SEH chain integrity (SEH chain validation).

  SHE Handler Validation: The executable file generated using the (/SAFESEH) Link option will contain a SAFESEH table that records all valid exception handling functions in the header, When an exception occurs, the exception distribution handler in Ntdll.dll verifies that the exception Handler record on the stack points to a valid exception handler in Safeseh table. If the exception distribution handler detects that the exception Handler record was overwritten by an attacker and points elsewhere, the program's operation is terminated.

  SEH Chain Validation is a validation protection technique for SEH chain integrity, often referred to as sehop (structured Exception Handler Overwrite Protection), It is a protection mechanism introduced in Windows Server 2008. If the system turns on the Sehop protection mechanism, the Finalexceptionhandler in Ntdll.dll is set to the end of each she chain as the last exception handler. When an exception occurs, the exception distribution handler iterates through the entire exception-handling chain, ensuring that the last exception Handler record Nextseh pointer to 0xffffffff,handler always points to finalexceptionhandler. Otherwise, the program's run will be terminated.

For programs that turn on SAFESEH protection, you can further forge the entire SEH chain when overwriting the exception Handler record, bypassing detection. Details are not explained here, please refer to other technical documents.

    • GS & DEP

DEP (Data execution Prevention) attempts to fundamentally block the execution of Shellcode. In a DEP-enabled system, the code can only be executed on a page that is marked as execution, so it prevents an attacker from executing shellcode in the stack, heap, or data segment. When the EIP points to the page of the Non-execution property, the system terminates the program execution directly. You can turn on DEP protection for the resulting executable file by linking options (/NXCOMPAT).

Currently, there are two main types of techniques for bypassing DEP, the first of which is to borrow third-party applications and components that can be used to support readable, writeable, executable property memory pages, combined with the heap Spray technology realizes the layout and execution of Shellcode. The JIT spray belongs to this kind of technology; the second is the use of code reuse to implement a bypass of DEP, including the use of system APIs to overwrite memory page properties, invoke execute system commands, or load executables (EXE, DLL, etc.) to introduce external code, Overwrite the security configuration (ie safemode flag bit, etc.). It is the most common way to use the system API to overwrite memory page properties.

For this example, we use the vulnerability to overwrite the exception Handler record, when we modify she record--and Handler point to the address of the Pop/pop/pop ESP RET instruction string. Rewrite the Nextseh with the System API address (VirtualProtect, zwprotectvirtualmemory, etc.) that can override the page properties. When an exception occurs, the Pop/pop/pop ESP RET will be executed, where the pop ESP will change the stack pointer so that ESP points to Nextseh. Therefore, after the RET instruction executes, it jumps to the system API used to overwrite the page properties. The page is overwritten with the execution property through the system API, and finally jumps to shellcode to continue execution.

    • GS & DEP & SafeSEH

For applications that turn on GS, DEP, and Safeseh at the same time, the principle of exploiting exploits is similar to the above, and the other is the need to forge the SEH chain, which is no longer described in detail.

    • GS & DEP & SafeSEH & ASLR

The ASLR (Address Space Layout randomization) is an important attack mitigation technology introduced from Vista and Windows Server 2008. When the system loads an image file, such as an executable program that supports ASLR technology, a dynamic-link library, and so on, it randomly handles its loading location, making it different from the base address that is loaded into memory each time it is restarted. Therefore, the use of program writers can not find a stable and reliable jmp ESP, pop pop ret, xchg eax,esp and other command addresses, but also unable to locate the location of the system API, especially in the case of DEP, ASLR simultaneously open, will greatly increase the difficulty of exploit.

ASLR randomly handles the location of the loaded PE file, heap, Stack, PEB, TEB, and so on. The resulting executable file can be turned on for ASLR protection via the link option (/dynamicbase).

In the face of ASLR and DEP, many attackers need to address two key issues, first, how to gain access to a module (target process, system, or other DLL) base address, thus making it possible to use system APIs for code reuse, followed by locating the attacker's layout on the stack, The Shellcode address on the heap (usually composed of stack pivot, ROP chain, payload, etc.).

Currently, there are two common ways to get the base address of a module, the first is to see if the system or application is running when the NON-ASLR module is loaded, and if there are other external NON-ASLR modules that can be introduced into the current process space, such as Java 6 Run Environment JRE1.6 MSVCR71.dll, Office 2010/2007 hxds.dll (introduced when using ms-help://in URLs), and so on. The base addresses of these NON-ASLR modules are fixed each time they are loaded into the process memory space, so you can index the base addresses of the system DLLs in their import tables, search for executable instruction widgets (gadget) in their code space, and so on; the second Is through a memory information disclosure vulnerability to obtain information about the memory layout, the status of the target process, and so on. For example, the target process, system, or other DLL's base address can be exposed through static variable pointers, virtual function table pointers, etc. to further obtain the relevant API address and useful gadget. (A further discussion of the relevant technologies for bypass ASLR will be discussed later)

In order to locate the Shellcode address of the attacker's layout on the stack, heap, the most common method is the heap spray technology, which, through a large number of successive memory requests, will shellcode the layout at the specified memory address. This method has the disadvantage of low stability, time consuming and resource, easy to be detected, therefore, the best method is to use the vulnerability to read out the Shellcode address, its restriction is the vulnerability type, need a vulnerability with arbitrary address read and write to use.

For this example of vulnerability scenario, the attacker is less controllable and cannot be exploited with GS & DEP & SafeSEH & ASLR Mitigation technology turned on. However, when a vulnerability scenario such as this occurs in a browser, Adobe Flash, Adobe Reader, Office, and other applications, the combination of information disclosure vulnerability, the attacker will achieve the perfect use. Because attackers can use scripting languages such as JavaScript, ActionScript, and VBScript to perform memory operations (memory requests and releases, create special objects, and so on) to make use possible.

By the above introduction we know that even though Windows has gradually introduced new attack mitigation techniques to prevent malicious code from running, these attack mitigation techniques only improve the difficulty of writing exploits, and do not completely prevent malicious code from running. Through research, it can still be exploited by known or unknown methods.

Currently, ie, Adobe Flash, Adobe Reader, Microsoft office, etc. are often used in people's Daily office, entertainment life of the application software. Therefore, malicious code writers are often targeted at them, exploiting the vulnerabilities to attack, so that the spread of malicious code and wide range of impact. Industry security vendors, researchers are also focused on these software vulnerability mining, the use of technology for analysis and research, the following mainly for IE browser, specifically on the ASLR & DEP Bypass technology principles.

3. Bypassing ASLR

FireEye published an article on his blog-"ASLR Bypass Apocalypse in recent Zero-day exploits"-by illustrating three types of techniques that bypass ASLR, used in the recent 0day exploits: using NON-ASLR modules, modifying the BSTR length/null Terminator, modifying the Array object. Essentially, the second and third types of technology are the result of a series of memory corruption that eventually reveal the memory base of the critical module and gain control. The following is an introduction to the principles of the three types of technology in the FireEye article.

3.1. Using the NON-ASLR module

This is one of the simplest and most common techniques for fighting ASLR protection, because there are still many applications and their modules that do not have ASLR protection turned on at compile time (/dynamicbase link option). Each time the system loads them on a fixed memory base, a malicious code writer can pick commands (gadget), index system functions from these NON-ASLR modules, turn off DEP, gain control, and so on.

A common module that does not have ASLR protection turned on is the Java 6 Runtime Environment JRE1.6 MSVCR71.dll, Office 2007/2010 HXDS.DLL. HxDs. The DLL is loaded into memory when the browser loads a URL with "ms-help://", but Microsoft has patched it up with a patch, and now HSDS.DLL has the ASLR protection turned on. The Java 7 Runtime environment, JRE 1.7, also has all the ASLR protection turned on.

As more and more applications and their modules use ASLR protection, future use of this approach will be less versatile.

3.2. Modify the length or terminator of a BSTR3.2.1. BSTR

A BSTR is a string data type, a mixture of pascal-style strings (which clearly indicate the length of a string) and a C-style string (ending with a), mainly for COM, interactive functions, and so on. It is a composite data type consisting of a length prefix, a data string, and a terminator, as shown in:

Figure 3?1

Where the data string is Unicode encoded, but it can also store other non-\x00\x00 strings.

3.2.2. How to use

The first occurrence of this exploit is on Pwn2Own 2010, which only applies to special types of vulnerabilities that can rewrite memory, such as buffer overflows, arbitrary address writes, increased or decreased content at the memory pointer.

  1. modifying The length of a BSTR

When a memory corruption vulnerability can satisfy the final effect of modifying any 4-byte memory, it can be used to modify the length prefix of a BSTR at a specified location so that this BSTR can access memory outside its original bounds. The result is the exact location of the link library that is suitable for constructing the ROP chain, thus bypassing ASLR. When you bypass ASLR through this method, you can gain control over the same memory corruption vulnerability that alters the execution process.

For example, in the following scenario, you first create a number of identical BSTR sizes in memory consecutively, and their in-memory layouts are shown in Figure 3?2.

Figure 3?2

Release one of the BSTR, and then immediately apply for an object of the same size, the same size refers to the size of object that eventually occupies in memory and the BSTR in memory occupies the same size. Due to the role of the front-end heap low fragmentation heap, the requested object is likely to be allocated to the BSTR memory space just released. So this is the memory layout.

Figure 3?3

At this point, the length of the BSTR before the object is modified so that the memory base of the relevant module can be computed by reading through the bounds and reading the virtual function table pointer of the object.

  2. modifying the terminating character of a BSTR

Many times the memory corruption class vulnerability is not high enough to modify 4 bytes (can not be used to modify the length of the BSTR), only the memory pointer at 1, 2 bytes can be modified. In this case we can concatenate the string with the subsequent object by modifying the terminating character of the BSTR. Subsequent access to the modified Bstr,object is also accessed as part of the BSTR, where an attacker can calculate the base address of the relevant module.

3.3. Modifying the length of an array object3.3.1. How to use

This modification of the length of an array object is similar to the use of modifying the length of a BSTR, as well as the vulnerability of memory corruption types that can rewrite memory. However, from an attacker's point of view, it is more user-friendly to implement a vulnerability that bypasses ASLR, because once the length of an array object is modified, an attacker can gain the ability to read and write any memory through an array, making it easier to program the execution process and implement code execution. The following is an example of the use of Vupen on pwn2own2013, which describes the principle of utilization of this method.

This vulnerability is due to the module VGX.DLL, which is responsible for VML parsing, when dealing with the Dashstyle.array.length property of the <v:stroke> tag, there is no integer overflow vulnerability resulting from complete validation of the passed-in parameters. An attacker could exploit this vulnerability to read and write to any address-by reading sensitive memory information and rewriting the object's virtual table, it would be possible to bypass the heavy memory protection mechanism for arbitrary code execution.

First, when using the JS statement in VML to assign a value to the DashStyle property, for example: Stroke.dashstyle = "1 2 3 4", the function vgx! Parsedashstyle will be called and will control the flow to the _msofcreatearray function to create an org array. Call the _MSOFINITPX function in _msofcreatearray to allocate memory according to the number of members of the array, each array member accounts for four bytes of memory, so the size of the org array buffer is the number of Members X4 (byte). When assigning a value to the Dashstyle.array.length property, the number of array members is changed, and the vgx! that is called within it Coalinedashstylearray::p The Ut_length function will re-form the number of org numbers according to the newly set values to re-allocate memory to the number of Org numbers based on the new set value. However, an integer overflow vulnerability exists in put_length that allows the DashStyle array object length to be set to 0xFFFF without new memory allocations. The exploit principle of this vulnerability is as follows.

A continuous Coaruntimestyle object is allocated on the heap, each object consumes 0xb0 bytes, and in the middle is interspersed by setting DashStyle into an org array. Controls the size of the array so that it is also 0xb0 bytes. The memory layout at this time.

Figure 3?4

The vulnerability is used to modify the length of the dashstyle so that subsequent data can be accessed across the org array. After the length of the org array is modified, the MarginLeft property of each Coaruntimestyle is assigned a value, and the overflow org array is used in the loop to read the value at the specified offset (that is, reading the org array then The Coaruntimestyle object holds the address of the MarginLeft property, and if its value is greater than 0, the Coaruntimestyle object that is indexed to the Org array at this point. At this point, use the org array to write the value of the address in the Coaruntimestyle object that holds the MarginLeft attribute, modifying it to 0x7ffe0300. After the out-of-bounds write is completed, the MarginLeft property is read through the get_marginleft of the Coaruntimestyle object. So Coaruntimestyle will read the value of the 0x7ffe0300, and the 0x7ffe0300 store the system call entry function exactly ntdll! The address of the Kifastsystemcall is computed to get the ntdll memory base, bypassing the ASLR.

It is also possible to read the first 4 bytes (virtual function table pointers) of subsequent Coaruntimestyle objects through the org array, and eventually subtract the corresponding offsets to get the current vgx.dll memory base.

(Note: cve-2013-2551 exploit principle and code under WIN7+IE8/IE10 Please pay attention to my post after ISCC2014. )

4. Bypassing DEP

DEP technology was introduced in XP SP3, but relying only on GS & DEP & Safeseh technology is still not enough to block all malicious code. The common two types of bypass DEP techniques are briefly described in section 2nd. Currently, 0day exploits are often used in code reuse to circumvent DEP, including the use of system APIs to overwrite memory page properties, invoke execute system commands, or load executables (EXE, DLL, etc.) to introduce code from outside the process space, Overwrite the security configuration (for example, IE safemode flag bit [5], etc.).

Among them, the use of system APIs to overwrite memory page properties and load executables (EXE, DLL, etc.) from outside the process space to introduce code is the most common method of utilization, the core of which is ROP technology. It switches the stack to an attacker-forged stack and implements DEP bypass with a finely constructed stack. The technical principles of ROP are described below. (Note: TK proposed by the Ldrhotpatchroutine technology and other methods do not need to use ROP)

4.1. ROP Technology

ROP is all called return oriented programming, which is currently the most commonly used technique for bypassing Dep. It takes advantage of the fact that an attacker can control the execution of data by an attacker injecting a bogus call stack into the process memory space, and then executing a stack pivot (stack reversal) instruction, which translates the stacking pointer onto a forged call stack. A forged stack can be thought of as a causal chain (ROP chain, made up of ROP Gadget, explained below).

Under normal circumstances, when a function returns, the return address of the function is saved in the normal stack, the address of the next instruction when the parent function calls the child function. When the stack pointer is converted to a spoofed call stack, however, when the function returns, it gets the return address from the spoofed stack, where the return address is an ROP Gadget in the process space.

ROP gadget represents any useful executable instruction string (located on the executable page) in the process space, and the executable instruction string ends with a ret instruction, which causes the return address (the address of the next ROP gadget) to be fetched from the spoofed stack after the instruction string has been executed. To ensure that the address of the ROP gadgets in the forgery stack is predictable and reliable each time the target program runs, the attacker must first bypass ASLR to obtain the memory base of the relevant module, and then obtain the identified ROP gadget address based on the instruction offset (hard-coded, the instruction offset in each module is fixed) , or a dynamic search method to search for ROP gadget in memory space to build ROP chain.

The purpose of constructing a series of ROP gadget on a counterfeit stack is to lay out a "useful" environment for the vulnerabilities to be exploited (such as adjusting the stack pointer, setting the register value, etc.), since the last ROP gadget will point to VirtualAlloc, VirtualProtect, The addresses of functions such as WriteProcessMemory, Shellexecueex, LoadLibrary, and so on, which will be used to modify the specified memory page to be executable or to introduce code from outside the process space and execute. Eventually, the data on the stack, heap becomes executable or directly loaded to run the executable file, bypassing DEP protection.

The ROP approach works because attackers trick the system into using data that the attacker can control, and the data does not need to be executed, and the attacker simply needs to control the address that the EIP executes next to execute the required instructions and functions. When the forged stack is injected into the process space (via heap spray[4] at the specified address, shellcode, and the address of the shellcode is obtained through the vulnerability), the execution process of the ROP method is briefly summarized as follows:

1) Execute "stack pivot" instruction (e.g. xchg eax, esp; RET, etc.) to convert the stack pointer onto the fake stack.

2) perform ROP Gadget from the top of the counterfeit stack

A) Execute some "useful" instruction strings (Push/pop/add/sub ... )

b) Execute the RET instruction (if the return address on the forge stack is still an ROP Gadget, continue to jump to execution; If the return address is a function address such as virtualprotect, then the function is executed using the parameters laid out on the fake stack. After execution, you can jump to the set return address on the fake stack, run payload)

5. General Bypass Method

Researchers have published a more versatile approach to bypassing ASLR, DEP, such as the JIT spray (Just in time compilation) proposed by Dion Blazakis. Yu Yu (tombkeeper) found Ldrhotpatchroutine and so on. But researchers have also found that in the natural environment, there is never a 0day attack using these methods against ASLR, because these methods are released and will soon be patched. The following is a brief introduction to its implementation principle, technical details please refer to other technical documents.

5.1. JIT Spray Technology

JIT Spray is a way to bypass the use of ASLR and DEP using the "Compile in Time" feature. A "timely compiler" generates code by definition as its data. So its purpose is to generate executable data. The JIT compiler is a program that cannot run in the "No-executable-data" environment, so the JIT compiler will exempt dep. The JIT spray attack is an attack that uses the JIT compiler "generated code (using code)" for heap injection.

5.2. Ldrhotpatchroutine Technology

The location from Windows NT 4 to Windows 8,shareduserdata has been fixed at address 0x7ffe0000, and the Kifastsystemcall address has been saved at 0x7ffe0300 Place x86.

and x64 under 7ffe0350 Save the address of ldrhotpatchroutine, within it will be indexed ldrloaddll to load external DLLs, so that arbitrary code can be implemented.

5.3. Dev Technology

Dev technology was first proposed by Yuange, the basic idea is to use the innate advantage of scripting language, that is, the scripting language is interpreted to execute, code, Shellcode are data. The implementation of Shellcode as a script is eventually implemented by modifying the critical data structure through the vulnerability. See reference [6] for technical details on Dev.

5.4. Undocuments

It is believed that there are other common methods that are not disclosed, such as Ldrhotpatchroutine technology, JIT spray technology, and dev technology, without the need for careful memory layout to bypass ASLR, DEP. These undisclosed technologies have a higher value.

6. References

[1] bypassing Browser Memory protections-setting back Browser Security by ten years [Eb/ol]. Alexander Sotirov, Mark Dowd. 2008.

[2] The info leak era on software exploitation [Eb/ol]. Fermin J. Serna. 2012.

[3] ASLR Bypass Apocalypse in recent zero-day exploits [Eb/ol]. Xiaobo Chen. 2013.

[4] Heap Feng Shui in JavaScript. [Eb/ol]. 2007

[5] subverting without EIP. [Eb/ol]. Mallocat. 2014

[6] APT advanced exploit technology. [Eb/ol]. Yuange. 2014

Related Article

Contact Us

The content source of this page is from Internet, which doesn't represent Alibaba Cloud's opinion; products and services mentioned on that page don't have any relationship with Alibaba Cloud. If the content of the page makes you feel confusing, please write us an email, we will handle the problem within 5 days after receiving your email.

If you find any instances of plagiarism from the community, please send an email to: info-contact@alibabacloud.com and provide relevant evidence. A staff member will contact you within 5 working days.

A Free Trial That Lets You Build Big!

Start building with 50+ products and up to 12 months usage for Elastic Compute Service

  • Sales Support

    1 on 1 presale consultation

  • After-Sales Support

    24/7 Technical Support 6 Free Tickets per Quarter Faster Response

  • Alibaba Cloud offers highly flexible support services tailored to meet your exact needs.