AdSense

Tuesday, May 2, 2017

10 - Buffer Overflow exploitation on MIPS architecture emulated with QEMU by remote debugging with GDB


BUFFER OVERFLOW EXPLOITATION ON MIPS ARCHITECTURE EMULATED WITH QEMU BY REMOTE DEBUGGING WITH GDB

- Layout for this exercise:




1 - Introduction

- This exercise is based on the previous one, where the source code of the binary stack_bof_01 (belonging to DVRF) was analyzed.

- In this case we will try to exploit the Buffer Overflow vulnerability present on the file, due to the usage of the strcpy function.

The executable stack_bof_01 is intended for a MIPS architecture, and it is emulated with qemu-mipsel by enabling chroot command.

- Let's pass to the program a simple parameter like asdfg:




- The answer corresponds to this part of the source code of the program:





2 - Remote debugging with gdb-multiarch 

- Let's install the package gdb-multiarch, what is a version of the GNU Debugger with support for multiple artchitectures: 

http://packages.ubuntu.com/precise/devel/gdb-multiarch




- The program is emulated again, now with the parameter AAAA and the option "-g 1234", meaning that the file is going to be debugged remotely at port 1234:




- Running the debugger gdb-multiarch in a quiet mode (-q):




- Setting the architecture option for MIPS:




- The remote target will be the Qemu instance launched before, that is running locally at the port 1234:





- Continuing the execution:




- The usual output is displayed:





3 - Preparing the attack

- Now, in order to prepare the attack, let's examine the functions of the binary. Specifically, because we are interested to control the flow of the program to execute the function dat_shell, let's notice that this function starts at 0x004000950:




- Also:




- In order to overwrite the buffer, let's use a pattern of 300 characters generated by a Perl script like this:


https://securitythoughts.wordpress.com/2010/03/18/tool-unique-pattern-generator-for-exploit-development/





- Copying the pattern, and pasting it as a parameter to the program:




- Debugging again:



- Continuing the execution, there is a segmentation fault at 0x41386740, a non executable area of memory:





- As before, the usual message is displayed:




- Examining the registers, we see that the PC (Program Counter) has been overwritten with the 0x41386741 direction:




- Converting the hexadecimal number 0x41386741 into ASCII:

http://www.asciitohex.com/







- After reversing A8gA to Ag8A, locating it into the pattern, there is an offset of 204:




- Marking Ag8A into the pattern:










4 - Launching the exploitation

- The key concept to perform the attack is that the buffer must be rewriten with the first 204 characters (all characters before Ag8A) followed by the address of the function dat_shell().

- Now, creating a new pattern of just 204 characters and copying them:

 

- Instead of choosing the beginning address of dat_shell(), let's pick four more advance instructions (0x0040095c). Otherwise the exploit does not work, and to be honest I don't understand why:





- Crafting a new parameter, composed of the 204 set of characters of the pattern, plus echoing 0x0040095c in a Little Indian format with option -e, to enable the interpretation of backslash escapes:






- Let's pass the argument to the program:




- Setting a breakpoint at the function dat_shell():




- Remote debugging again:




- Continuing the execution:





- At this point let's have a look at the registers. Now the PC has been loaded with the function dat_shell():




Eventually the buffer overflow attack is successful because dat_shell() function is executed:




- Remembering the code for the function data_shell():





9 - Analysis with RADARE2 of MIPS architecture


ANALYSIS WITH RADARE2 OF MIPS ARCHITECTURE

- Layout for this exercise:




1 - DAMN VULNERABLE ROUTER FIRMWARE (DVRF)

- DVRF is a firmware that was built vulnerable on purpose whith the goal of providing a simulated learning environment for architectures different to x86.

- DVRF can be found here:

https://github.com/praetorian-inc/DVRF







- Downloading the firmware:








- Extracting with binwalk:






- Going into the extracted folder, the usual squashfs-root folder is found:




- Checking the content of  squashfs-root the full system file is available:





- The folder pwnable contains some vulnerable binaries, for instance the executable stack_bof_01 that suffers from a Stack Buffer Overflow vulnerability, as its name indicates:




2 - ANALYZING THE BINARY WITH RADARE2/R2

- radare2/r2 is a complete framework for reverse-engineering and analyzing binaries, composed of a set of small utilities that can be used together or independently from the command line. 

- Built around a disassembler for computer software which generates assembly language source code from machine-executable code, it supports a variety of executable formats for different processors and operating systems.

https://github.com/radare/radare2

https://radare.org/r/

https://en.wikipedia.org/wiki/Radare2


- rabin2 is a tool that is part of the Radare2 framework, useful for extracting information from executable binaries like ELF, PE, Java CLASS, MACH-O. It's used from the core to get exported symbols, imports, file information, xrefs, library dependencies, sections, ...

https://github.com/radare/radare2/wiki/Rabin2


- Using rabin2 to achieve information about stack_bof_01, for instance that the file is intended to be run under MIPS architecture:




- Now, applying the analyzer radare2 to stack_bof_01:




- aa (analyze all):




- afl (analyze functions):




- uClibc (aka µClibc/pronounced yew-see-lib-see) is a C library for developing embedded Linux systems, much smaller than the GNU C Library.


https://www.uclibc.org/about.html





- Also, the vulnerable strcpy function is found, a well-known C function related with Stack Buffer Overflow vulnerabilities:

https://en.wikipedia.org/wiki/Stack_buffer_overflow





- Checking the source code stack_bof_01.c the strcpy function can be detected:









- The goal of the Stack Buffer Overflow attack would be the execution of the function dat_shell so that the "/bin/sh" shell is launched.

 - Finally, the function dat_shell displays a congrats message once a Buffer Overflow has been performed successfully, as it will be seen during the next exercise









- Disassembling the first 20 lines of the main function:





- However, the look of the previous code is not very convenient, so it could be changed using some of the functionalities of radare2.

- Going to the source code of radare2:





 - Some of the options are removed and the rest is copied to a new file radare2rc:





- Now, the new disassembled code look reflects in an easy way what is happening as the function main is executed:





- izz (printing all the strings), the strings that are part of the binary are displayed, for instance the congrats message after the BoF attack is successfully performed:




- VV (starting an HTTP server working on localhost and port 9090):




- Now, connecting the browser to localhost:9090, a visual mode of the binary is available: