Re-analysis of Windows Workstation Service Remote Overflow

xiaoxiao2021-03-14  197

Create time: 2003-12-01

Article properties: reprint

Article submission:

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

"Analysis of Windows WorkStation Service Remote Spill", in fact, there are many details in many details, especially how to use vSprintf to output to size incorrectly defined buffers, attacking parts . With the opportunity of weekends, I have studied in detail, and below is some of my own research. Similarly, there is no specific attack source code, just analyzing and discussing in principle of technology, involving something specific, such as source code, sorry, I can't post it, everyone is really interested in these technologies So, it is a relatively large success rate to construct the corresponding packet.

To fully understand this article, it takes three preparatory knowledge:

1. Understand the principle of stack overflow

2. Conversion knowledge between Windows Unicode and multi-byte

3. Reading Understanding Previous Article << Windows WorkStation Service Remote Spill Analysis >>

Ok, transfer to the topic. The system objects here are still the Windows 2000 Simplified Chinese version, and the version of the other multi-byte languages ​​is in communication, but the implementation is not the same.

Refer to the last article, you can see that the problem is mainly in the result of the MSVCRT.DLL (all mentioned VSPrintf, all the vsprintf functions of MSVCRT.DLL, non-libc vsprintf) characters formatted. Enter NetValidateName (L "// IP", "Attack String", L "", L ", NetSetupunkNown; then, the server will perform the corresponding log record (of course, these are permissions, etc. The conditions are in line with.). The function defines the variable of the output buffer string, only the size of the 0x804, the VSPrintf formats the output content to the variable, if the size exceeds 0x804, then cover the stack data of its top, including variables and functions return addresses, resulting Buffer overflow.

The VSPrintf formatted string is: [NetpValidateName: Checking to See IF '% WS' Is Valid as Type% D name.]. It can be seen that the input string to the output buffer is the conversion of% WS. When tracking the VSPrintf of MSVCRT.DLL, the discovery process is like this: (Analysis assembly code is slightly, everyone can see the vsprintf source code of MSVCRT.DLL)

1. Format the character reading one by one to process.

2. If the character's ASCII is not the range of 0x20 ~ 0x78, then, jump, here I don't care how it is handled, skip. . .

3. The conversion value is obtained based on the ASCII value of the current character to the conversion table, and then the conversion value is obtained.

4. According to the conversion value, check the table again, get the actual processing function address, the processing is as follows:

a) Different letters, jump to different processing function addresses, for example. The jump address of%, W, s, d, f, p, etc. is different.

b) If you are%, set the flag bit that starts the conversion.

c) If W, set the wide byte processing flag to 1.

d) If it is s, then start the following parameters to make a string replication.

e) Other parameters, don't care, skip.

5. After the current character is processed, continue to read the next byte until the length exceeds 0x7fffffffffffffffffffffffff, or the 0 character is touched as the end. Otherwise, jump to 1 loop processing.

Here, the processing of% WS in vsprintf is analyzed in detail, and it is also an analysis of 4-> D in the above process.

By tracking, it is found that the vsprintf is called WCTOMB for wide byte conversion, and the WCTOMB's MSDN resolution is a character that converts the width byte character into a multi-byte character. The return value is the number of converted characters. If the content of the conversion is byte 0, then the return value is 1. If the conversion fails, then -1 is returned.

For WCTOMB and then analyze, track it in, and finally it is called WideChartomultibyte to convert. (Pour! It is also the function of the system language. This may mean that there is no complete generality between the different systems, and the letters of the E text do not have multiple bytes, how to convert ...?). If the WideChartomultibyte conversion failed, then WCTOMB returns -1.

In VSPrintf, when the conversion failed wide byte character, the conversion stops immediately, regardless of the following characters without more waiting conversion, no processing. Therefore, in all attack data as parameters input, characters must be a wide-byte character that can be converted.

According to the above analysis results, and the previous article, the following attack package is constructed.

Buffer 1 Buffer 2 (JMP ESP Address) Buffer 3 (shellcode)

MultiByte (2023 bytes) 4 bytes are not limited

Regardless of the transmitted widechar buffering, the length of the converted must meet the above table requirements.

1. After the buffer 1 is converted back to the multi-byte string, the length must be 0x7e7 bytes.

2. Buffer 2 is the JMP ESP address, after being converted back to multi-byte strings, the length must be 4 bytes, and in the service.exe process, the content of the memory address is: 0x54 0xc3 ( PUSH ESP, RET); or 0xFF 0xE4 (JMP ESP); or 0xFF 0xD4 (Call ESP).

3. Buffer 3 When the overflow occurs, the address of the ESP pointer must be the content of the correct shellcode, and these shellcode is tested by WideChartomultibyte, that is, all can be converted by WideChartomultibyte, and not 0x00 data. Here for other characters, there will be no specific limits, for example, the limitations of <,>, *,?, ', ", , -, /, /, and other symbols are not hit. 4. Data after the conversion The length of the package cannot be too long (how much, I have no calculations, but the experience test, more than 5,000 bytes will trigger, this time it is used to observe the phenomenon, the reason for the positioning overflow is still ok.), Otherwise, it will trigger An exception handler, this is another way of use, which is not described in detail here, but the truth of the conversion is the same.

The above is the conditions, how to make a stable attack in the above frame? That is to say, it is written out for General Attack Code (regardless of service pack) for the same language, we must find the following data:

1. Most important, there is a completely convertible shellcode. This article in the previous year has already said a technical approach, everyone flips, or find it. :)

2. You can find all versions of the same jump ESP address, and can be successfully converted into a wide byte. To convert, restore in VSPrintf.

3. The previous buffer 1, with a length of 2023 bytes, can be used to store the attack code, the original content does not care, the original length does not care, however, after the WideChartomultibyte conversion, the length must be 2023.

4. Previous article, a place at the end of buffering 1 will be rewritten by Writefile parameters, and it is not used in detail here.

OK. After the construction is completed, send, get shell!, 嘿嘿, is it simple, maybe? of course!

After these more messy analysis, you can see that the general attack of Windows Workstation Service is not impossible. It's just a lot of people in the middle. It seems to be difficult to start WebDAV, but it is also coming out after all.

As for E text, since WideChartomultibyte, it is impossible to successfully switch to the byte greater than 0x78, there is a better handling method. It is also unclear how popular overflow programs on the market are implemented, as if the other party does not need to consider this conversion problem. I really don't understand, it may be different from the perspective of technology. If a friend understands, then, please tell me, let me learn to learn. ~

Win XP also has this overflow, however, the Chinese XP version I studied, and the CodePage of its WideChartomultibyte's conversion is 437, which means that it is a way to transform the e-text, it is difficult to use. . . I still can't think of a better implementation.

This overflow, although it can be universal, but cannot do multiple overflows, because the RPC function has entered at least 2 places, and enters the critical area, although this overflow function has entered, and functions When returned, the current critical area was indeed exited. Due to the overflow characteristics, the data of the back stack has been used to do the shellcode storage area, and the return address cannot be saved correctly. Therefore, after overflow, it is no longer possible to return to the original road. Continue the execution of the original code, the entry of the two critical regions in front, and cannot be exited. The next time you enter, it will also cause lock and wait for a long time. . . PS: After this overflow attack is successful, you can't exitprocess, ExitThread is a good way. Otherwise, after the Services.exe process is dead, the system will protect the restart. However, in the XP environment, since the WorkStation service is started by SVCHOST.exe, you can repeated overflow attacks without restarting. Just, XP is still unable to use now. . .

OK, discussion here, this article only discusses the possibility of implementation from the perspective of technology, I hope that the masters who wish to realize should not release the code, after all, this vulnerability is still very existed, one is not careful, will cause worms, cautious ,careful!

. 2003/11/30 NIGHT.

转载请注明原文地址:https://www.9cbs.com/read-129344.html

New Post(0)