CRACKING THE ROOT PASSWORD AND CONNECTING VIA SSH TO THE KANKUN SMART PLUG
- Layout for this exercise:
1 - Cracking the root password with John The Ripper
- This exercise is based on the previous one, where the firmware of Kankun Smart Plug was extracted:
https://dgmsp.blogspot.com/2017/05/11-extracting-and-analyzing-firmware-of.html
- Checking the interesting contents of the file system, for instance the passwords file /etc/passwd:
- Also, the encrypted file for passwords is /etc/shadow:
- Before using John The Ripper to decrypt the passwords, let's unshadow /etc/passwd and /etc/shadow creating a file test:
- unshadow combines /etc/passwd and /etc/shadow:
- Using John The Ripper for decryption, the root password is p9z34c:
2 - Connecting to the network created by Kankun Smart Plug
- When the Smart Plug is plugged, and after 20 seconds of solid blue light, it starts blinking slowly:
- At that time Kankun works as a hotspot or Access Point creating a WiFi network of SSID OK_SP3.
- The device used in this exercise is an Ubuntu virtual machine hosted by a Windows 10, what detects the newly created WiFi network OK_SP3:
- The characteristics of the wireless network OK_SP3:
- The Virtual Machine is attached with the mode Bridged Adapter, so that it is networked directly to OK_SP3:
- Once inside the Ubuntu virtual machine we notice that Kankun (acting as Access Point) assigns an IP 192.168.10.140 to Ubuntu:
3- Accessing via SSH
- From Ubuntu, connected to the network (192.168.10.0/24) of the hotspot Kankun, let's discover any other host:
- The host 192.168.10.253 corresponds to the Kankun Smart Plug, acting as gateway for all possible connected devices to OK_SP3. Pinging it from Ubuntu:
- Let's scan ports of Kankun:
- Once detected that SSH port 22 is open, let's try to connect to Kankun via SSH, taking advantage that we know the root password of the device (p9z34c):
- The connection has all the privileges of the user root:
- Checking the IP of Kankun:
- We have access to the whole root file system of the Kakun Smart Plug:
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():
