CRACKING AUTHENTICATION WITH BURP FOR NETGEAR ROUTER EMULATED FIRMWARE
- Layout for this exercise:
- This exercise is based in a previous emulation of Netgear firmware:
- Downloading the free edition of Burp Suite in its .JAR file version:
https://portswigger.net/burp/freedownload
- The .JAR file is downloaded:
- Launching the application:
- After accepting all the default options for Burp, let's ensure that the proxy is listening locally (127.0.0.1) on port 8080:
- Also, let's configure Burp so that the interception applies for both the Client requests and the Server responses:
- Now, it is time to enable the proxy at the Firefox browser:
- Let's introduce some fake credentials, like for instance Username:Password
- Burp intercepts and displays the fake credentials:
- Looking into the tab "HTTP history", right clicking the request and choosing the option "Send to Intruder":
- The attack target is the known one (Firmware emulation with 192.168.0.100 and port 80):
- The attack consists on using two payload lists, the first one for the username and the second one for the password:
- Because this is a simple example, let's provide just 10 possible usernames and 10 possible passwords, totally 10x10 = 100 possible requests.
- For the username (list of 10):
- For the passwords (list of 10):
- As said before, in this simple case the total Request count is 100 (10x10):
- However, in a real scenario case, and using the Pro version of Burpsuite, large wordlist text files could be provided. Of course, trying many possible combinations would take a longer time to perform the attack:
- Starting the attack:
- It is noticeable that the only trial (number 3) with a status 200 OK and different length (313) corresponds to admin:password, what are the default credentials for the NetGear device, meaning that the attack is successful.
- Also, the 3th trial yields a loginok response message:
- It is interesting to notice that this attack has been launched against an "emulated firmware", and not against an actual physical device.
EMULATING NETGEAR ROUTER FIRMWARE
- Layout for this exercise:
- The goal of this exercise is to emulate firmware corresponding to a Netgear router, both accessing the file system of the firmware and also running it as if it were real.
- Once the emulation is successful the firmware will work as an actual physical device running on the network.
- The reason of emulation is the need to run firmware binaries of embedded devices in a Linux system (x86 architecture), whereas they are intended to work with different architectures like MIPS or ARM.
- In this way, we can analyze and understand the firmware's functionality, or even interact with it for security purposes.
1 - Downloading, extracting and decompressing the firmware
- The Netgear Download Center provides all the firmware for the Netgear devices:
http://downloadcenter.netgear.com/
- For instance, let's download WNAP320 Firmware Version 2.0.3:
- Renaming the file to a more manageable name:
- Extracting and decompressing with unzip and tar:
2- Extracting and decompressing the file system of the firmware
- The .squashfs file contains the compressed file system of the firmware:
https://en.wikipedia.org/wiki/SquashFS
- binwalk -e (extraction) extracts the directory _rootfs.squashfs.extracted:
- The folder squashfs-root contains the decompressed file system of the firmware:
- It is very usual that embedded devices commands are run through busybox, and not directly by /bin/sh or /bin/bash, as it happens with typical Linux systems:
- For more information about busybox:
https://busybox.net/
https://en.wikipedia.org/wiki/BusyBox
3 - Identifying the architecture
- file command shows that the extracted binaries are intended for the MIPS architecture, and not for the x86 architecture where Linux is running:
- Same result with the comand readelf:
4 - Emulating with FAT (Firmware Analysis Toolkit)
- FAT (Firmware Analysis Toolkit) is composed by a set of tools (qemu, binwalk, mitmproxy, ...) useful to emulate embedded devices firmware.
- It is an open source tool what can be downloaded and configured according to these directions:
https://github.com/attify/firmware-analysis-toolkit
- Copying the downloaded .zip file from the original folder /Downloads to the folder /tools/fat, where FAT is located:
- Launching fat.py the user is prompted to a couple of questions, like the absolute path for the file WNAP320.zip, and the name of the manufacturer, in this case Netgear. That information is stored in a postgres database for the purpose of later utilization.
- Also, two passwords are required to complete the process:
a) password for user firmadyne: firmadyne
b) password for oit: password@123
- At this point the network connection is being set up and an interval of 60 seconds must be waited, because that is the time considered to allow the firmware image to boot up.
- Finally an IP address is assigned to the virtual interface and the emulated firmware is accessible:
- Pinging the assigned IP address:
- From the browser the firmware is accessible, after booting, just entering the assigned IP address. The default credentials for this Netgear device are admin:password:
- Once the browser is closed the emulation session is destroyed:
INPUT VALIDATION ISSUES 3 - BUFFER OVERFLOW
- Layout for this exercise:
- Connecting from Santoku to Nexus 5 with ADB:
- Launching the application:
- Clicking the tab for challenge 13:
- The applications prompts the user to enter any input able to crash the app.
- Entering 1111 the application just answers "Access denied!":
- However, entering a long string of characters, let's say a string of 30 "1"s, the app stops after crashing:
- To understand what has happened inside the app, it is very convenient to examine the log generated by the command logcat.
- We see a fatal signal (SIGSEGV = segmentation fault, or segmentation violation), because the operating system considers protected the memory address 0x31313131 (0x31 is the ASCII code for character "1"):
- Looking up into the Java source code of the challenge, InputValidation3Activity.java:
- The application is using JNI (Java Native Interface), what suggests that the method DivaJni is related to a program written in other language:
- Going to the source code of the applications, there is a program divajni.c written in language C:
- Opening divajni.c, there is a constant (#define CODESIZEMAX 20) defining a maximum value of 20, later used to determine the size of the string code:
- Also, the function strcpy copies the string entered by the user over the variable code:
- The problem is that the function strcpy does not check whether the size of the destination's buffer is large enough to hold the source parameter.
- A consequence of function strcpy bad usage is the corruption of memory or buffer overflow, and eventually the crash of the application.
