View the process of debugging from the MS03-049 vulnerability exploitation (figure)

Target readers: vulnerability analysts and fans
Prerequisites: Basic Debugging steps for overflow vulnerabilities and how to use Softice
WTF: Windows XP
SP2 is believed to be a system that everyone is paying attention to. At the beginning of this version, due to its overflow protection mechanism, traditional overflow exploitation methods were no longer available, so it was favored. I remember that our colleagues began to wonder if there was any need to continue to study the exploitation of overflow vulnerabilities. However, over time, XP
SP2 also gradually exposes compatibility issues with previous operating system versions. For example, some software can be used normally on Windows 2000, XP SP0, and SP1, but not on SP2; XP
SP2 imposes a lot of restrictions on using the original socket to send TCP data packets, which leads to obstacles in the development of some network programs, and so on. As a result, a large number of users still insist on using other versions of the system for a long time. I am not an old man, I just want to illustrate that MS has given us a lot of time to continue studying traditional overflow vulnerabilities-Isn't there a few IE vulnerabilities for XP SP2? Now, read the article first:
Guide to writing Exploit for cainiao --
　　　　
View the process of debugging system from the exploitation of MS03-049 Vulnerability
This article is mainly based on some problems encountered in the process of using WorkStation Service Overflow Vulnerability (MS03-049) in the past, let's talk about how I debug the system process to use this vulnerability to serve myself. My goal is not to talk about this vulnerability completely. Instead, I would like to introduce the exploitation process of the vulnerability to discuss the exploitation code that will not be published in the future, or someone has published how to write your own exploitation code step by step while the code is retained in key areas. Of course, the current method is only preliminary.
Use existing data whenever possible
Some time ago, I was bored. I wanted to see if any new overflow vulnerabilities could be exploited. However, when I opened Xfocus and Nsfocus, I couldn't find a new Windows-based Stack Overflow Vulnerability. As a result, we remembered that last year's WorkStation Vulnerability did not seem to have caused any worms. That is to say, although there are patches available on the Internet, this vulnerability still has a wide range of possibilities. So I decided to use it to train my hands.
The MS03-049 overflow discovered by EEYE is called in an API of Wkssvc. dll
Occurs when the vsprintf function is used. I later found two analysis articles about Snake and learned about the principles and applicability of the vulnerability. Unfortunately, due to public opinion pressure, neither Xfocus nor Nsfocus published the Code explicitly, finally, it took a lot of effort to find the piece of code written by SBA on the forum. With the code, try it now. Good guy! I quickly entered a friend's machine, as shown in 1 and 2:

Javascript: if (this. width> 500) this. width = 500 "border = 0>

Figure 1

Javascript: if (this. width> 500) this. width = 500 "border = 0>

Figure 2
So smooth ?! In this case, check whether the code can be rewritten to automatically transfer files. Fortunately, the ShellCode in this area has been written before, so it is ready for use. Now the rest is to find the overflow point and then modify it. For convenience, the following work is for Windows
2000, and the current system partition is Fat32.
Determine overflow points
　
The overflow is of course found from the ready-made code. Open the source code of the DOS window again and find two points worth attention, one of which is shown in Area 3:

Javascript: if (this. width> 500) this. width = 500 "border = 0>

Figure 3
The other is the arrangement for sending data packets in the Code as follows:
| ShellCode | AAAAAAAA... | Jump address |
AAAA... |
Strange! The whole code only covers this address, but 0x7ffa4a1b is a common JMP in Windows 2000.
The address of EBX. I initially understood that the author would overwrite the processing function address of SEH, but why should I use 0x7ffa4a1b in two places? And there is no forward jump command, why just jump to the place where ShellCode starts? Also, what are the advantages? How many bytes of space does the WorkStation Service allocate to store parameters? In the analysis article, Snake points out that it is near 2023. try this first.
After the data is filled, the common JMP is overwritten at the beginning of 2023rd bytes.
ESP address 0x7ffa4512, followed by about 40 bytes \ xeb \ xfe (why do you want to do this? Continue reading it later !), Then open Softice. If the overflow is here, the Softice bounce will stop at "eb
Fe. Unfortunately, this time we didn't see the desired effect. Obviously, 2023 is not an overflow. But you don't need to worry about it. Then, enter "ABCD…" in the range from 2001 to 2040... XYZ0123456789JJJJ ", exactly 40 bytes. Compile, connect, get the executable file, and then restart the system (this is complicated and requires a restart after each test). Exactly the information shown in Figure 4 is displayed:

Javascript: if (this. width> 500) this. width = 500 "border = 0>

Figure 4
　
Now it is clear that 0x54535133 corresponds to "QRST", and the corresponding position is at 2017. That is to say, we can think that the WorkStation Service allocates a buffer of 2013 bytes to store parameters, and the return address of the function is at 2017th (subscript) bytes. After finding the cause, we can do some of the following.
Retained address after detecting the EIP
When I first detected whether 2023 contains the function return address, about 40 bytes later filled with \ xeb \ xfe, in order to check JMP
Whether there is a reserved address after ESP. Sometimes, jmp esp cannot be directly followed by ShellCode in BUF. For example, the RPC (MS03-026) vulnerability is in the JMP
ESP must be followed by an 8-byte reserved address. What about the WorkStation Service vulnerability? Try the preceding method, as shown in Figure 5:

Javascript: if (this. width> 500) this. width = 500 "border = 0>

Figure 5
As shown in figure 5, after 0x7ffa4512
Fe "has exactly 12 bytes. In other words, these 12 bytes are reserved addresses. In general, we only need to put ShellCode after these 12 bytes.
Check the size of the receiving buffer of the service.
In fact, I think this is a relatively easy place to ignore. During the exploitation of some vulnerabilities, the buffer size of the service for receiving network parameters may be limited. In this case, we cannot place ShellCode in JMP.
The ESP address must be followed by the ESP address. This test method can be used to view the memory in Softice. I will not talk about it more here. Of course, this problem does not exist after testing the WorkStation Service Vulnerability.
Use a general jump address
It is best to use a general jump address. Even if you cannot find the General jmp esp address, you can also find other general jump addresses, and some services have a general jump address. For example, SQL
The Resolution Service Vulnerability contains a common JMP.
ESP address 0x42b0c9dc, while RPC Overflow vulnerability has a common jump address 0x0100139d with jmp esi function.
If you want to make the jump address more generic, we recommend two popular ones: JMP for Windows 2000, XP, and 2003
The address of the EBX function is 0x7ffa1571, and the address of the common jmp esp function is 0x7ffa4512. In the WorkStation Service vulnerability, I used 0x7ffa4512.
　
Next, we can rewrite the code used to transfer the desired file and execute it. The ShellCode was previously compiled and is not described here. The written exploitation code and the exploitation code for downloading sb-a are included in the Code of the CD.
Use JMP ESP
　
Here, I will add one point. As mentioned above, the Code for effectively overwriting the return address of the function in the code of SBA has only one sentence: memcpy (szBuffer + 2017,
"\ X1b \ x4a \ xfa \ x7f ",
4), but his ShellCode is placed at the top of the SzBuffer. Starting with the previous analysis, ebx points to SzBuffer when the function returns! Use Softice to view details, as shown in Figure 6:

Javascript: if (this. width> 500) this. width = 500 "border = 0>

Figure 6
EBX = 0x00109744, and the first address of szBuffer is 0x00109744!
The reason why I want to talk about this is to explain that the principle of exploits is similar, but there are many ways to implement it. How to implement it? It's a matter of different ways.
Well, the above is some of my experiences through the use of WorkStation Service Vulnerabilities. Some may not be clearly written and I hope to communicate with you. In addition, there is no other way to capture Softice in this article. It is taken directly by a digital camera, so it is a bit vague. I hope you will forgive me.