Shulou(Shulou.com)06/01 Report--

MS08-067 vulnerability principle and process example analysis, I believe that many inexperienced people do not know what to do, so this paper summarizes the causes of the problem and solutions, through this article I hope you can solve this problem.

Principle of 0x01 MS08-067 vulnerability

The MS08-067 vulnerability is triggered when the NetPathCanonicalize function in the Server service program is called through the MSRPC over SMB channel, and when the NetPathCanonicalize function accesses other hosts remotely, it will call the NetpwPathCanonicalize function to standardize the path of the remote access, and the logic error in the NetpwPathCanonicalize function can cause the stack buffer to be overflowed and obtain remote code execution (Remote Code Execution).

The so-called path normalization is to convert [/] to [\] in the path string, while removing the relative paths [.\] and [..\]. Such as:

* * /. / * > *.

In the operation of path normalization, there is a logical loophole in the address space check of the path string by the service program. By carefully designing the input path, the attacker can copy the contents of the path string to the address space before the path string (low address) when the function removes the [..\] string, so as to overwrite the return address of the function and execute arbitrary code.

Path processing flow

The NetpwPathCanonicalize function does not directly input the path and normalize it, but continues to call the subordinate function CanonicalizePathName to organize the path, standardize the path string to be sorted out, and then save it to the pre-allocated output path buffer buffer.

Path processing process:

1. Check the first character of the path to be sorted out

two。 Call the wcslen function of the msvcrt.dll module to calculate the path length

3. Call the wcscat function of the msvcrt.dll module to copy all the paths to be sorted out into the newly applied memory.

4. Call the wcscpy function to remove the first relative path representing the parent directory in the path to be sorted out and copy it to strTemp, such as:

\ *\..\ * * = >\..

5. Call wcscpy in a loop until the path is sorted out.

Here we know that when normalizing replication, look for the [..\] string representing the parent directory and the preceding [\] string, remove this segment, and copy the new path.

As shown in the figure, the first relative path is removed and copied to the buffer on the first check

However, when the [..\] string is at the front of the path string, the preceding [\] is outside the buffer, where a forward (low-address) overflow occurs.

Buffer overflow

To be clear, Microsoft has made a preliminary defense against buffer overflows that may occur when string replication occurs when the path is normalized.

Every time you copy a string into a buffer, whether using wcsccpy or wcscat, always compare the length of the source string before copying to ensure that the length is less than a certain value, otherwise the copy will not continue. This strategy ensures that the buffer does not overflow to a high address, that is, there is no problem when the current function returns.

Note, however, that when normalizing the representation path and looking for [\] characters in front of the [..\] string of the parent directory, the program makes a judgment and boundary check: if the address of the current comparison character is the same as the address of the source string, it indicates that the entire string has been found, and the program will stop searching.

However, it only misses one situation, that is, when the parent directory relative path [..\] string is at the beginning of the source string, the string compared at the beginning of the lookup ([\] to [..\]) is outside the buffer, which causes the copied string to overflow to the low address, causing the return address of the function wcscpy to be overwritten.

Experimental Environment for 0x02 vulnerability recovery Analysis

Target machine: Windows2003 SP0 EN

Vulnerability component: netapi32.dll

Tools: IDA Pro, OllyDbg

Select the Windows XP SP3 EN system host as the analysis environment, locate the system module netapi32.dll containing the security vulnerability (path C:\ Windows\ system32) and the process svchost.exe that calls the vulnerability service Server, and target process command behavior:

C:\ Windows\ System32\ svchost.exe-k netsvcs

Open netapi32.dll with IDA pro and find the NetpwPathCanonicalize function where the vulnerability is located (the address in each run stack will be different, but the address of each function will be the same), as mentioned in the figure in the book:

Looking at the function flow chart, you can see that this function does not directly normalize the input path, but continues to call the subordinate function CanonicalizePathName

However, the CanonicalizePathName function is not found in the actual operation, and a variety of data show that the CanonPathName function should be called for standardization.

IDA analyzes the NetpwPathCanonicalize function code (F5 + finishing + main code):

The function is declared as follows:

DWORD NetpwPathCanonicalize (LPWSTR PathName, / / requires standardized path LPWSTR Outbuf, / / stores Buffer DWORD OutbufLen of standardized path, / / Buffer length LPWSTR Prefix, / / optional parameter, useful LPDWORD PathType when PathName is relative path, / / storage path type DWORD Flags / / reserved, 0) dynamic debugging

Check the process pid with the command line parameter svchost.exe-k netsvcs through wmic:

Open OllyDbg, click file- > attach, and attach to the svchost.exe process:

View- > Executable modules double-click netapi32, right-click Search for in the cpu instruction window to find exec (label) in current module, find the function NetpwPathCanonicalize, address is 71C#44A3E, and set a breakpoint here:

Tracking the vulnerability trigger process

Go back to the CPU instruction window to run the program, and then the attack machine Metasploit loads the ms08_067_netapi module and exploit:

NetpwPathCanonicalize interrupt

The svchost program in the analysis environment interrupts at the entry address of the NetpwPathCanonicalize function. The parameters passed in to this function are as follows:

Esp [esp] * Note * 00ECF924 02248D34; point to the path to be sorted out: 00ECF928 022321D8; point to the output path buffer00ECF92C 000003F1; output the length of buffer 00ECF930 02248FB0; point to prefix, the value is\ x5C\ x00, that is, unicode'\ '00ECF934 02248FB4; point to the path type, value is 0x100100ECF938 00000000; WORD Flags reserved, value is 0CanonicalizePathName interrupt

Combined with the process analysis of NetpwPathCanonicalize by IDA pro, the next level function CanonPathName will be called at the address, and a breakpoint will be set at this address:

Run to this breakpoint, and then trace the function CanonPathName, passing in the following parameters:

00F0F8FC 00157570; point to prefix, the value is\ x5C\ 00, that is, Unicode "\" 00F0F900 001572F4; point to the path to be sorted out 00F0F904 02132E80; point to the buffer00F0F908 000003F9 of the output path; the length of the output buffer is 00F0F90C 00000000; WORD Flag reserved word, the value is 0

You can see from the argument passing of the last two functions that the function CanonPathName collates the path and then saves it to the pre-allocated output path buffer buffer.

Path structure to be sorted out

Look at the structure of the path in OD. The path is a Unicode string, starting with [\ x5C\ X00] (Unicode character "\") and ending with [\ X00\ X00], containing some random uppercase and lowercase letters. The longer undisplayable character is the encoded Shellcode, the most important of which is the relative path of the two connected parent directories [.\].

The path is a Unicode string, starting with [\ x5C\ X00] (Unicode character "\") and ending with [\ x00\ x00], containing some random uppercase and lowercase letters, the longer undisplayable character is the encoded Shellcode, and the most critical part is the two concatenated [\..\], which is the relative path that represents the parent directory.

The whole path to be sorted out is like:

\ * pre-operation before sorting out the path

Set a memory access breakpoint on the 4-byte memory address 000C0F50 where the path to be cleaned is located:

Press F9 to run, it will be interrupted three times, the first two times are to check the first character of the path to be sorted out and call the wcslen function, and the third time is to call the wcscat function. Analyze two parameters in the third incoming stack:

The first is strDestination, which points to a memory space that begins with [\ x5c\ X00], and the second is strSource, which points to the content after the first two bytes of the above path to be sorted out [\ x5c\ X00].

The program copies all the paths to be sorted out to strDestination, namely 0x001572F6. Set a breakpoint in this 4-byte type and select "Hardware, on access" DWord.

Copy path to buffer

F9 continues to run, and the fourth interrupt is in 0x77BD4010. The memory shows that the first two characters of src are copied to the end of [\ x5C\ x00] of dest. This is due to the breakpoint of these two bytes:

The fifth interrupt is in 0x71C#44B1C, which is located in the wcscat function. The memory shows that src has been copied to dest, as shown in the figure:

The first path normalization

Press F9 to run, stop at the memory 0x77bd4d36 after several interruptions, which belongs to the wcscpy function from the stack. Call this function here to normalize the path for the first time. As shown in the figure:

The current parameter SRC is 0x00EC6E0, pointing to [.. *], and the parameter strDestination is 0x00ECF4DC, pointing to the first character [\] in temp. Obviously, this path normalization discards the content between the first character [\] and the first [..\] relative path in the path to be sorted out.

At this point, the wcscpy source address src is in the edx register and points to [.. *]; the destination address dest in the ecx register points to the first character [\] of the path to be sorted out, as shown in the figure:

So, this string copy operation is to remove the first relative path that represents the parent directory, that is, the content between the first [\] and the first [..\] in the path to be sorted out becomes useless and discarded. After the operation is completed, the path character in temp looks like [.. *].

After the first standardization, the path to be sorted out looks like:

\.\ *

Because there is [..\], there needs to be one more normalization, and this second normalization is where the mystery lies.

The second path normalization

Since the wcscpy function is called every time the path is normalized, delete the hardware breakpoint of 0x00ECF4DC and directly drop the breakpoint at the entry address 0x77BD4D28 of the wcscpy function.

After F9 runs, interrupt at the entrance 0x77BD4D28 of the wcscpy function, and call the parameters passed in the wcscpy function:

Esp [esp] * Note * 00ECF4AC 00ECF494 destination address, pointing to the memory area value of\ x5c\ x00, that is, [\] 00ECF4B0 00ECF4E2 source address, pointing to the last slash of the second relative path [\..\].

Normally, this normalization process performs the same operation as the first time, removing the second relative path [..\], thus completing the second path normalization. However, there is an unexpected situation here. The first address of temp is 0x00ECF4DC, but the destination address of this string copy operation is dest, which is before temp, as shown in the figure:

Also notice that the stack pointer ESP value is 0x00ECF4A8, which points to the return address 0x71C52FD4 of the wcscpy function. The ESP to the copy destination dest address 0x00ECF494 has only 0x14 bytes, so if the function wcscpy continues, it will overwrite the return address of the wcscpy function with the source string src.

When you execute the retn command, you can see that the return address becomes 0x0100129E, and the instruction for that address is:

00100129E FFD6 call esi

Execute the call esi (ES=0x00F0F4DE) instruction, exactly pointing the EIP to the 8th byte null instruction constructed in the string as copied as possible, followed by [\ xeb\ x62] (jmp 0x62), which skips the middle random string and points to the encoded Shellcode, as shown in the figure:

So this is due to a [\] (0x5C) at the memory 0x00F0F494, which overflows the pending path forward when dealing with the relative path [..\] of the parents, thus overwriting the string to the location of the return address of the function wcscpy, and jumping to shellcode to cause remote code execution.

As mentioned earlier, when [..\] is at the beginning of the source string, the compared characters are outside the buffer at the beginning of the lookup, resulting in a forward overflow.

After reading the above, have you mastered the method of example analysis of the principle and process of MS08-067 vulnerability? If you want to learn more skills or want to know more about it, you are welcome to follow the industry information channel, thank you for reading!

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.