Whitelist: STACK OVERFLOW / 6 - Exploiting Aviosoft Digital TV Player

STACK OVERFLOW / 6 - Exploiting Aviosoft Digital TV Player

- Layout for this exercise:

0 - Introduction

- The Aviosoft Digital TV 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 Digital TV player on 2012, and documented at Exploit Database:

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

1 - Installing and running Digital TV Player

- Aviosoft Digital TV Player 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 consequence is the creation of a file called DTVexploit.plf, what will be read by the vulnerable program DTV player on the victim machine:

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

- Now, DTV player reads DTVexploit.pfl and the exploite 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 DTV player restarted with Immunity Debugger, the exploit is launched:

- DTV player opens DTVexploit.plf and the program crashes, but now EIP is overwritten with 69413469 and ESP with 41316A41:

- 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. This area will be the best one to locate the future shellcode.

- Executing DTVexploit.py, restarting DTV player, and opening DTVexploit.plf.

- As expected, the program crashes. EIP is overwritten with four 'B's.

4 - Hunting bad characters

- Bad characters are those ones interpreted literally that truncate the program 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 just before the 'C's:

- Executing DTVexploit.py, restarting DTV player, and opening DTVexploit.plf.

- The program crashes as usual. 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 DTVexploit.py:

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

- After removing \x00, restarting DTV player, executing DTVexploit.py and opening DTVexploit.plf..

- 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 DTVexploit.py:

- Once \0x00 and \0x0A removed from DTVexploit.py, and following previous steps \x1A is discovered also as a bad character, because the buffer is interrupted just after \x19:

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

- \x1A is removed from DTVexploit.py:

- Again, executing DTVexploit.py, restarting DTV player, and opening DTVexploit.plf.

- The program crashes, but now the execution of AllChars has been completed,from \x01 to \xFF, meaning that there are 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) local port, LPORT = 443, where the attacker listens for a reverse connection
d) format = -f c, language C

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

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 772052FB:

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

- The Python script is redefined to include the shellcode. Also, as mentioned before, a bunch of 50 NOPs (\x90) is introduced after '\xFB\x52\x20\x77', ensuring that the shellcode is actually executed.

- The final DTVexploit.py: