Yahoo! Protocol: Part 18 - Arbitrary Code Execution

[tansqrx 0]

The holy grail of any exploit is to be able to run arbitrarily injected code. If code from the attacker can be run on the target system, in most cases the attacker just gained full control of the target system. An attacker can inject previously tested shellcode onto the victim machine and at the very least spawn a command prompt. The primary focus of this paper is to take the act of booting from annoying DoS attacks to much more sophisticated and dangerous remote code execution attacks.

To analyze and follow the execution of Yahoo! Messenger, break points and analysis of the system stack was performed at key points. It is found that the stack is corrupted with the address 00730079 shortly after one of the registry accesses during the first packet. Because of the large amount of commands executed between packets, it still not clear as to which command causes the corruption or the exact timing of the corruption. While analyzing the stack after a crash, it is also found that the address of 00730079 is not completely random. When converted to UNICODE characters, 00730079 is the string âysâ. Looking further down the stack after a crash it is found that the string âD:\System\Program Files\Yahoo\Messenger\Ypager.exeâ is passed as an argument several times. In the case for this computer, âD:\System\Program Files\Yahoo\Messenger\Ypager.exeâ is the path for the Yahoo! Messenger executable. It is not hard to see that the string âysâ, aka 00730079 is actually part of the string D:\System\...â. While performing an earlier operation, the Messenger executable path overwrote a valid stack entry and eventually caused the access violation. Table 4 shows the system stack immediately after the crash. The address 00730079 (âysâ) and the Messenger executable path are both highlighted.

 

Table 4 - Stack

In short it is found that the ultimate goal for this paper, arbitrary code execution through a Yahoo! booter, is not possible. It is shown that the stack corruption that causes the access violation is the result of a timing issue and not the code sent in the booter packet.