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:

8 - Shell exploitation on ARM architecture emulated with QEMU by debugging with GDB

SHELL EXPLOITATION ON ARM ARCHITECTURE EMULATED WITH QEMU BY DEBUGGING WITH GDB

- Layout for this exercise:




- This is an exercise based on the previous one, running the executable confidential in an ARM architecture emulated with Qemu.

- Before starting the exercise let's ensure that ASLR is disabled:




- Launching the debugger GDB for the program confidential:




- Setting up a breakpoint for the vulnerable function vfunction():



 
- Starting the debugging for the binary, for instance with just a simple parameter like A:




- The function erand48() is part of the general set of commands for Linux:






- Disassembling erand48():




- What actually makes erand48() interesting in this exercise is the section starting at 0x40057148. Let's examine the instructions of that section one by one:

a) ldm sp,{r0,r1} ->  loads 4 Bytes pointed by r0 and another 4 Bytes by r1 into the SP
b) add sp,sp,#12 -> prepares the Stack for making room for next instructions
c) pop {lr} -> pops the content of the top of the Stack to LR
d) bx lr -> jumps to LR




- Actually, any other alternative function to erand48() could be used, having similar functionality to the quoted section.

- On the other hand, it is also very useful the function system(), what executes a shell command, in this case "/bin/sh":






- system() is located at address 0x4005ed34:




- Now, let's pass the crafted parameter to the program:

- Let's examine all parts of the parameter:

a) AAAABBBBCCCCDDDD allows to reach LR (see previous exercise)

b) \x48\x71\x05\x40 is the Little Endian format for the address of the instruction ldm sp,{r0,r1} (0x40057148). 

c) XXXX would be the "/bin/sh" address, which location we don't know at this moment, that will be pass as the r0 argument.

d) YYYY would be padding for r1 and ZZZZ for the next instruction.

e) \x34\xed\x05\x40 is the address location where the function system() starts (0x4005ed34)

f) finally, the command "/bin/sh" itself that will be passed to system(), like system(/bin/sh)


- Entering the whole parameter, the program debugging is restarted from the beginning and the breakpoint for vfunction() is hit:





- Stepping one instruction:





- At this moment the sections of the parameter are located in these memory addresses of the Stack:




- Actually, the address for "/bin/bash" is 0xbefffc18:





- Now, we can replace XXXX with 0xbefffc18 in Little Endian format (\x18\xfc\xff\xbe):




- Passing the whole parameter, and restarting the debugging from the beginning:




- Stepping on instruction:




- Stepping another instruction the program enters the function erand48():




- Stepping another instruction the program enters the function system():




- At this moment, the registers hold these values:




 - It is interesting to notice that the register SP points to 0xbefffc18 ("/bin/sh") and LR points to 0x4005ed34 (system())

- Stepping another instruction, system() calls to "/bin/bash" and eventually a shell with root privileges is achieved::




- Also, the successful of the exploitation can be checked passing the parameter directly, not debugging with GDB: