Whitelist: STACK OVERFLOW / 4 - Exploiting Blaze DVD Windows application

STACK OVERFLOW / 4 - Exploiting Blaze DVD

- Layout for this exercise:

0 - Introduction

- The BlazeDVD Microsoft DVD player uses the .plf extension for the creation of playlist files that are used with the software.

- PLF is an acronym for Playlist File. Files that contain the .plf file extension most commonly store playlist files for the InterVideo WinDVD software application. When a user creates a playlist within the application, the PLF file is created, containing an index of the media files referenced in the playlist.

- A buffer overflow vulnerability was registered for BlazeDVD player on 2013, and documented at Exploit Database:

https://www.exploit-db.com/exploits/26889/

1 - Installing and running BlazeDVD

- BlazeDVD can be downloaded from Exploit Database, as seen in previous image.

- The program can be started either directly or using Immunity Debugger.

- Running the Trial version:

- At this point the program needs to read a .plf file from a PlayList, what will be the exploit created by the attacker:

- For the purpose of making easier the process of creating and reading an exploit, a shared folder is enabled between the attacker and the victim:

2 - Overwriting the stack

- Writing a basic Python script to overwrite the stack of the victim with a set of 1000 'A' characters:

- Giving execution permissions to the exploit:

- Launching the exploit:

- The consequences of the exploit is the creation of a file called BDexploit.plf, what will be read by the vulnerable program BlazeDVD on the victim machine:

- Due to the fact of having enabled shared folders, every time the BDexploit.py and BDexploit.plf are changed at the attacker's side, the modified files are available immediately at the victim's machine, so that BDexploit.pfl can be read by BlazeDVD:

- Now, BlazeDVD reads BDexploit.pfl and the exploited is executed:

- The program crashes, because it is forced to be executed in a non accessible memory area like 41414141 (AAAA in ASCII):

3 - Controlling the EIP

- With the purpose of detecting where the EIP is overwritten, an easily recognizable string of 1000 bytes is created with a Ruby script, and sent to the victim.

- The string is introduced into the exploit:

- Once BlazeDVD restarted with Immunity Debugger, the exploit is launched:

- BlazeDVD opens BDexploit.plf and the program crashes, but now EIP is overwritten with 37694136 and ESP with 6A41336A:

- Using another Ruby script, both addresses are located into the memory dump:

- Now, the Python script is modified according to the previous results:

i) the set of 'A's will reach up to the EIP location.
ii) EIP will be overwritten with four 'B's.
iii) the rest of the stack will be overwritten with 'C's, where ESP points directly to the beginning of this section.

- Executing BDexploit.py, restarting BlazeDVD, and opening BDexploit.plf.

- As expected, the program crashes. EIP is overwritten with four 'B's. The 'C's area will be the best one to locate the future shellcode. Because ESP points 40 Bytes further than the beginning of the 'C' s area, a bunch of NOPs instructions will be introduced:

4 - Hunting bad characters

- Bad characters are those ones interpreted literally by the program, so that the program is truncated in the middle of the execution.

- With the purpose of identifying bad characters, a string with all the possible hexadecimal characters is created. The Python script is modified, introducing the 256 bytes AllChars string before 'C's section:

- Executing BDexploit.py, restarting BlazeDVD, and opening BDexploit.plf.

- The program crashes as usual, because EIP points to a non executable area of 'B's:

- However, a close inspection of the memory details that the buffer execution has been interrupted just after the four 'B's, just where the AllChars string would begin to be executed. This means that the character '0x00' truncates the execution of the rest of the buffer:

- So, '\x00' is clearly a bad character, and it should be removed from the DBexploit.py:

- Let's go on searching for more bad characters.

- Executing BDexploit.py, r

- Now, the buffer execution has been interrupted just after '0x09'. This means that the character '0x0A' truncates the execution of the rest of the buffer:

- Following ind dump:

- So, '\x0A' is a bad character, and it should be removed from DBexploit.py:

- Once \0x00 and \0x0A removed from BDexploit.py, and following previous steps \x1A is discovered also as a bad character,

- Following in dump, it is clear that \x1A truncates the execution of the buffer:

- \x1A is removed from BDexploit.py:

- The new BDexploit.py:

- Again, executing BDexploit.py, restarting BlazeDVD, and opening BDexploit.plf.

- The program crashes, but now the execution of AllChars has been completed,from \x01 to \xFF, meaning that there no more bad characters:

- Following in dump, it is clear that all characters, from \0x01 to \xFF, have been executed:

- To sum it up, there are 3 bad characters, that being interpreted literally by the compiler, its immediate effect consists of truncating the normal execution of the program. Once removed, the buffer is executed correctly.

0x00 = Null Byte = terminates a string copy operation.

0x0A = Line Feed = advances by the space of one line.
0x1A = Substitute character = used in the place of a character that is recognized to be invalid or in error or that cannot be represented on a given device. It is also used as an escape sequence for some programming languages.

5 - Generating a shellcode

- msfvenom helps generating a shellcode, with these options:

a) payload: -p windows/shell_reverse_tcp
b) local host, attacker's IP = LHOST = 192.168.149.129

c) c) local port, LPORT = 443, where the attacker listens for a reverse connection
d) format = -f c, language C

e) encoding = -e x86/shikata_ga_nai
f) EXITFUNC = thread, the execution of the shellcode does not shutdown the program
g) bad characters = -b "\x00\x0A\x1A"

- The Python script is redefined to include the shellcode. Also, as mentioned before, a bunch of NOPs (\x90) is introduced after the set 'BBBB', ensuring that the shellcode is actually be executed:

6 - Redirecting the flow execution

- The goal of this part of the attack is to find an stable way of redirecting the execution flow to the memory section (now, full of 'C's, and pointed by ESP), where the shellcode will be located.

- One way of achieving that goal would be finding an instruction JMP ESP located in a memory section not subject to changes. Let's remember that techniques like ASLR or DEP rebase the memory address allocations in each reboot of the system.

- Looking for executable modules:

- For instance, clicking on KERNEL32.DLL:

- Searching for a JMP ESP command:

- One JMP ESP is detected at 75948C1F:

- The set of four 'B's on the Python exploit is replaced by the memory address 75948C1F, introduced in reverse order '\x1F\x8C\x94\x75' due to the fact that x86 processor architecture follows the Little Endian format (least significant byte occupying the lowest memory position).

- The final BDexploit.py: