For readers: Vulnerability analyst, Black fan
Pre-Knowledge: The basic debugging steps of overflow vulnerability, SoftICE Basic use method
Wtf:windows XP
SP2 believe that everyone is concerned about a system, this version just launched, because of its overflow protection mechanism, the traditional way of overflow has been lost, it has been favored. I remember when the peers began to mutter about the need to continue to study the technology of overflow exploits. But as time goes on, XP
SP2 also slowly exposes compatibility issues with previous versions of the operating system, such as software that works on Windows 2000 or XP SP0, SP1, and is not available on SP2; XP
SP2 makes a lot of restrictions on the use of raw sockets to transmit TCP packets, which can lead to obstacles when we develop certain web programs, and so on. As a result, a large number of users are still insisting on using other versions of the system for a long time. I am not a conservative, I just want to use this to explain the fact that MS is actually giving us a lot of time to continue to study the traditional overflow vulnerabilities--for XP SP2 ie vulnerabilities not just out of several? All right, here's the crap, read the article first:
Rookie version of the exploit guide to write nine--
debugging system process from the perspective of ms03-049 Vulnerability Utilization
In this paper, I mainly based on some problems in the process of using Workstation service overflow (ms03-049) during the previous period, and how I can use this flaw to serve myself by debugging the process of the system. My goal is not entirely to talk about this loophole, but rather to explore the use of the vulnerability process to discuss the future without the use of the code, or someone announced the use of the code but in the key place with reservations, how to write their own use of the code step by step. Of course, the present method is only very preliminary.
Make the best use of available information
I've been bored for a while to see what new vulnerabilities can be exploited, but when you open Xfocus and NSFocus, you can't find a new windows-based stack Overflow vulnerability. Then I think of last year's workstation loophole seems to have no outbreak of worms, that is, although the Internet has a related patch, but the vulnerability is still a widespread possibility. So, I decided to use it to practice practicing.
The ms03-049 overflow found by eeye is call in an API of Wkssvc.dll
Occurs when the function is vsprintf. I later found Snake's two analytic articles, understanding the principle of the vulnerability and the scope of application, here no more. Unfortunately, perhaps because of the pressure of public opinion, Xfocus or NSFocus not in the prominent position to publish the use of code, finally a great effort to find from the forum Sbaa wrote that code. With the use of code, of course, try it immediately. Boy! Incredibly soon went into a friend of a machine, as shown in Figure 1, 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 that case, see if you can rewrite the code as an automatic transfer file. Fortunately this aspect of the Shellcode has been written before, then use ready-made. Now all that remains 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.
The determination of the overflow point
The overflow point, of course, was found in the ready-made code. Open the source code of the DOS window again, and find two noteworthy places, a place as shown in Figure 3:
Javascript:if (this.width>500) this.width=500 "border=0>
Figure 3
Another is the arrangement for sending packets in your code as follows:
| shellcode| aaaaaaaa...| Jump Address |
aaaa...|
Strange! This is the only address covered in the entire code, but 0x7ffa4a1b is a generic jmp under Windows 2000
EBX's address. My initial understanding was that the author would overwrite Seh's handler address, but why use 0x7ffa4a1b in two places? And there is no command to jump forward, why just jump to the place where Shellcode started? And what exactly is the overflow point? How many bytes of space does the Workstation service allocate to store parameters? Snake in the analysis article probably pointed out around 2023, then try this first.
After I populated the data, I covered the generic jmp at the beginning of the No. 2023 byte.
ESP address 0x7ffa4512, followed by about 40 bytes for \xeb\xfe (why do this, keep looking back!) And then open SoftICE, if the overflow point is here, SoftICE back out will stop at "EB
Fe "section. Unfortunately, this time did not appear to want the effect, obviously 2023 is not an overflow point. But do not worry, and then from 2001 to 2040 in order to fill in the area "ABCD ... Xyz0123456789jjjj ", just 40 bytes. Compile, connect, get executables, and then reboot the system (this is a cumbersome place to reboot after each test) and just bounce out the information shown in Figure 4 below:
Javascript:if (this.width>500) this.width=500 "border=0>
Figure 4
Now it is clear that 0x54535251 corresponds to "Qrst", the corresponding position is in 2017. That is, you can assume that the Workstation service allocates a 2013-byte buffer to hold the parameter, and the function return address is at the No. 2017 (subscript) byte. The overflow point is found, the following things are good to do some.
Check the reserved address after the EIP
Before I detected 2023 is not included function return address, in the back about 40 bytes filled with \XEB\XFE, the purpose is to check the JMP
Whether there is a reserved address after esp. Because sometimes, buf fill in jmp esp in the back is not directly with Shellcode. For example, the RPC (ms03-026) vulnerability is JMP
There must be a 8-byte reserved address behind ESP, what about the Workstation service vulnerability? Try the previous method, as shown in Figure 5:
Javascript:if (this.width>500) this.width=500 "border=0>
Figure 5
As can be seen from Figure 5, after 0x7ffa4512 to the execution "EB
Fe "places exactly 12 bytes, in other words, the 12 bytes are reserved addresses. In general, we just need to put the shellcode in the 12 bytes.
The receive buffer size for the detection service
In fact, I think this is a more easily overlooked place, in some vulnerabilities in the process, it may appear that the service used to receive network parameters of the buffer size limited. If that's the case, we can't put Shellcode in the jmp.
After the ESP address, and should consider putting it in front. This test method from the SoftICE to view the memory to know, here no more talk. Of course, there is no such problem with testing Workstation service vulnerabilities.
Use a generic jump address
Can use the general jump address best, even if cannot find the general jmp ESP the address, also may look for other general jump address, and some service itself has the general jump address. such as SQL
In the Resolution service vulnerability, there is a generic jmp
The address of ESP is 0X42B0C9DC, and the RPC Overflow vulnerability has a generic jump address 0x0100139d with jmp ESI functionality.
If you want to jump the address more general, here is recommended now more popular two: Windows 2000, XP, 2003 are common to have jmp
The address of the EBX feature is 0x7ffa1571, and common jmp with the ESP feature is 0x7ffa4512. In the Workstation service vulnerability, I used the 0x7ffa4512.
Next, you can rewrite the transfer file I want and execute the use of the code, Shellcode was previously written, here is not the story. The code that is written to use code and download Sbaa is attached to the code of the CD.
Using JMP ESP
Here's a little something to add. As already mentioned, the code in Sbaa's code that effectively overwrites the function returns an address with only one sentence: memcpy (szbuffer+2017,
"\x1b\x4a\xfa\x7f",
4), but his shellcode is at the front of the szbuffer. From the previous analysis, it must be when the function returned EBX pointed to the szbuffer! See Figure 6 below with SoftICE:
Javascript:if (this.width>500) this.width=500 "border=0>
Figure 6
EBX = 0x00109744, and Szbuffer's first address is also 0x00109744, sure enough and imagined the same!
The reason why I want to say this is to show that we are in fact similar to the principle of exploiting loopholes, but there are many ways to implement them. Concrete how to achieve, that is eight Immortals crossing, recount.
Okay, that's what I got. Through the use of Workstation service vulnerabilities in some of the experience, may be written in some places is not very clear, hoping to communicate with you. In addition, this article on the SoftICE screen I have no other way, is to use a digital camera directly down, so a little fuzzy, I hope you forgive me.
