[Analysis] Remote Overflow Analysis of Windows Workstation Service

Analysis of remote overflow of Windows Workstation Service

Created on:
Article attributes: Reprinted
Article submitted: stardust (stardust_at_xfocus.org)

By snake snake@cnns.net

Company page: http://www.cnns.net

First analysis: http://www.cnns.net/news/db/3796.htm

I published the Windows Workstation Service Remote Overflow Analysis in the previous two weeks. In fact, there are many details not clearly written, in particular, the section on how to use vsprintf to output to a buffer with incorrectly defined size for attack. I took the weekend to study it in detail. Below are some of my research experiences. Similarly, there is no specific attack source code in it. It is only analyzed and discussed in terms of technical principles and involves specific things, such as the source code and sorry, if you are really interested in these technologies, you should have a relatively high success rate by constructing the corresponding data packets by yourself.

To fully understand this article, three preparations are required:

1. Understand the principles of Stack Overflow

2. Windows Unicode and multi-byte conversion knowledge

3. read and understand the previous article <Windows Workstation Service Remote Overflow analysis>

Now, let's move on to the subject. The system object studied here is the Simplified Chinese version of Windows 2000. The versions of other multi-byte languages are the same, but the implementations are different.

According to the previous article, we can see that the problem mainly lies in msvcrt. DLL vsprintf (all vsprintf mentioned below are msvcrt. DLL vsprintf function, non-libc vsprintf) character to format the output result. Enter netvalidatename (L "// ip", "Attack String", l ", l", netsetupunknown) on the attack end. Then, the server will record the corresponding logs (of course, these are all when the permissions and other conditions are met .). The function defines the variable that outputs the buffer string, which is only 0x804. vsprintf formats the output content to this variable. If the size exceeds 0x804, it overwrites the stack data at the top of the stack, including the return addresses of variables and functions, resulting in buffer overflow.

The vsprintf formatted string is: [netpvalidatename: checking to see if '% ws' is valid as type % d name.]. We can see that the conversion from the input string to the output buffer is % ws. When we tracked the vsprintf of msvcrt. dll, we found that the process was like this: (the analyzed assembly code is skipped. You can see the source code of vsprintf of msvcrt. dll)

1. Read and process formatted characters one by one.

2. If the ASCII character is not 0x20 ~ 0x78 range, so, jump, here I don't care how it is processed, Skip...

3. Search for the ASCII value of the current character in the conversion table and obtain the conversion value.

4. Check the table again based on the conversion value to obtain the actual address of the processing function. The processing is as follows:

A) different letters jump to different handler address, for example. The jump addresses of %, W, S, D, F, P are different.

B) if it is %, set the flag to start conversion.

C) if it is W, set the width byte processing flag to 1.

D) if it is S, take the following parameters for string copying.

E) skip other parameters.

5. After processing the current character, continue to read the next byte until the length exceeds 0x7fffffff, or 0 characters are encountered as the end. Otherwise, skip to 1 for loop processing.

Here we will analyze in detail the processing of % ws in vsprintf, which is also the analysis of 4-> D in the above process.

Through tracking, we found that vsprintf calls wctomb for wide-byte conversion, and wctomb's msdn resolution converts wide-byte characters into multi-byte characters. The return value is the number of characters to convert. If the converted content is byte 0, the returned value is 1. If the conversion fails,-1 is returned.

Perform further analysis on wctomb and find that widechartomultibyte is called for conversion. (Down! It is also a function related to the system language. This may mean that different systems cannot be completely universal, and e-text letters do not have multiple bytes. How can they be converted ...?). If the conversion of widechartomultibyte fails, wctomb returns-1.

In vsprintf, conversion stops immediately when a conversion failure occurs for a wide byte character, no matter whether there are more characters waiting for conversion. Therefore, it is required that the characters in all attack data input as parameters must be wide-byte characters that can be converted.

Based on the above analysis results and the previous article, we constructed the following attack packets.

Buffer 1 Buffer 2 (jmp esp address) buffer 3 (shellcode)
Multibyte (2023 bytes) 4 bytes are not limited

Regardless of the size of the sent widechar buffer, the converted length must meet the preceding table requirements.

1. Buffer 1 after being converted back to a multi-byte string, the length must be 0x7e7 bytes.

2. buffer 2 is the JMP espaddress. After the strings are converted to multiple-character segments, the length is 4 characters, and in the service.exe process, the memory address points to 0x54 0xc3 (push ESP, RET); or 0xff 0xe4 (jmp esp ); or 0xff 0xd4 (call ESP ).

3. buffer 3 is the address of the ESP pointer when overflow occurs. It must be the content of the correct shellcode, and these shellcodes are all tested by widechartomultibyte. That is to say, they can all be converted by widechartomultibyte, no data of 0x00 is displayed. Other characters are not subject to special restrictions, for example, <,> ,*,?, ',', +,-,/,/, And other symbol restrictions.

4. the length of the converted data packet cannot be too long (I did not calculate the number of data packets, but in the empirical test, more than 5000 bytes will be triggered. This is used to observe the phenomenon, locate the cause of overflow .), Otherwise, the exception handling function will be triggered. This is another method to use. It is not described in detail here, but the conversion principle is the same.

The above is the condition. How can we conduct stable attacks in the above framework? That is to say, to write general attack code (regardless of Service Pack) for Win2k in the same language, we must find the following data:

1. The most important thing is that there is a shellcode that can be fully converted. This yuange article has come up with a technical solution several years ago. :)

2. A jump ESP address with the same version can be found, and can be successfully converted into a wide byte. In order to convert and restore in vsprintf.

3. the preceding buffer 1 has a length of 2023 bytes, which can be used to store attack code. The original content does not matter, and the original length does not matter. However, after widechartomultibyte conversion, the length must be 2023.

4. As mentioned in the previous article, a part at the end of buffer 1 will be rewritten by the writefile parameter. If it is not calculated in detail, it will not be used.

OK. After the construction is complete, send and get the shell !, Hey, it's that simple, is it possible? Of course!

After these messy analyses, we can see that the common attacks of Windows Workstation Service are not impossible. It's just that there are a lot of intermediate fees. It seems difficult to start WebDAV, but after all, it also came out.

As for the e-text, because of widechartomultibyte, the bytes greater than 0x78 cannot be converted successfully, so there is no better solution for the moment. It is not clear how the popular overflow program is implemented, as if the other party does not need to consider this conversion problem. I really don't understand. Maybe the technology is different. If anyone understands this, tell me how to learn it .~

Win XP also has this overflow. However, in the Chinese XP version I studied, The codePage of widechartomultibyte conversion is actually 437, that is, it is an e-file conversion method, difficult to use... We can't think of a better way to achieve this.

This overflow, although common, cannot be implemented multiple times, because entercriticalsection appears in at least two places before the RPC function enters this function and enters the critical section, although this overflow function also enters, and the function returns a correct exit from the current critical section, due to the overflow feature, the data in the subsequent Stack has been used as the shellcode storage area, the return address cannot be properly saved. Therefore, after overflow exploitation, you cannot return to the original path and continue executing the original code. The previous two critical sections cannot exit either. The next time you enter, it will also cause a lock and wait for a long time...

PS: exitprocess is not allowed after the overflow attack is successful. exitthread is a good method. If the services.exe process is killed, the system restarts it. However, in the Windows XP environment, the workstationservice is started by svchost.exe, so repeated overflow attacks are allowed without restarting. However, XP cannot be used until now...

Okay, so far, this article only explores the possibility of implementation from a technical point of view. I hope that the experts will not release the code. After all, this vulnerability still exists widely, if you are not careful, it will cause worms to flood. Be careful and be careful!

Snake. 2003/11/30 night.