CVE-2023-27216 - DLink Router

This document is my personal experience of me - a newbie into firmware reversing and exploiting.

Scope

For demonstration, we will analyze and reproduce CVE-2023-27216.

• CVE number: CVE-2023-27216
• Vulnerability description: An issue found in D-Link DSL-3782 v.1.03 allows remote authenticated users to execute arbitrary code - as root via the network settings page.
• Equipment model: D-Link DSL-3782
• Firmware version: DSL-3782_A1_EU_1.01
• Manufacturer's official website: http://www.dlink.com.cn/
• Firmware address: https://media.dlink.eu/support/products/dsl/dsl-3782/driver_software/dsl-3782_a1_eu_1.01_07282016.zip

Tasks

In order to exploit any firmwares, there are following steps:

• Obtain the firmwares. There are 2 ways: extract them directly from the hardware (camera, router, printer, etc.) or you can get them from the manufacturer's website. This will be discussed in another document.
• Analyze the firmware and find any vulnerabilities
• Emulate the firmware.
• Build gdbserver statically in order to debug.

Firmware analyze

Usually a firmware binary file contain a bootloader (uBoot), a Kernel File, Kernel Header for bootloader (uImage) , a compressed file system (Generally in SquashFS format), A CRC/MD5 table(To verify File integrity) and other miscellaneous files.

Find a way to analyze the firmware first, do some research, got some resources:

• Binwalk to analyze, extract the firmware
• How to stimulate: https://boschko.ca/qemu-emulating-firmware/

Extract important files

Extract firmware using binwalk: binwalk -Me DSL-3782_A1_EU_1.01_07282016.bin

Got the extracted squashfs-root folder and some weird files.

Bonus: If you dont see squashfs-root folder, you use unsquashfs on any ".squashfs" files you see. They are just like zip files 😅.

Analyze how the firmware works

Check the firmware architecture and endiane. This can be checked by checking some binaries extracted from the firmware. Check the architecture and firmware: file <binary>

Here we can almost confirm that the firmware runs on MIPS 32-bit MSB architecture. The reason for "almost" is because some firmware may run on different architecture with MIPS Compatible such as Lexra.

Check the squashfs-root folder and found some interesting files:

• usr/etc/init.d/rcS => This is the script that runs when the firmware boots up
• usr/etc/passwd => This is the file that contains the user information
• userfs/romfile.cfg => There is a credential admin:admin

Check the rcS file and found some interesting code:

echo "admin:$1$$iC.dUsGpxNNJGeOm1dFio/:0:0:root:/:/bin/sh" > /usr/etc/passwd

• This code is used to write the user information to the passwd file
• Run a webserver called boa server. Boa is an ancient webserver, mainly used in embedded devices like routers back in the 2000’s. However, boa server has already stopped it’s development back in 2005! Even though Boa server is dead almost 20 years ago, it still lives to this day thanks to our vendor.

Full system firmware emulation

I recommend using Debian based OS for the emulation process such as Ubuntu or Kali. There is another OS that centers around firmware hacking called AttifyOS. In this document, I used Kali Linux. Start with stimulation process, there are 2 tools:

• QEMU => Don't reinvent the wheels 🙏 🛐
• FAT- Firmware-analysis-toolkit => It works, you can read source code to know what it does.

Let's go through how to use FAT to fully emulate a firmware. First off, we clone the repo from github to your Kali machine. And go through setup process. You need to change the fat.config file too, otherwise it won't work.

git clone https://github.com/attify/firmware-analysis-toolkit.git

cd firmware-analysis-toolkit

./setup.sh

vi fat.config # Modify to your sudo password.

Then we copy the firmware binary (the one we downloaded from the manufacturer) to the folder of FAT on our Kali machine and run it.

./fat.py DSL-3782_A1_EU_1.01_07282016.bin

Note: During setup process of FAT we may encounter errors. It may say no libmagic.

Just simply run

pip unistall python-magic
pip install python-magic

This should fix your problem, then we run the build command again. It should work like a charm now.

Press Enter to run. The emulation process should work nicely as you can browse to http://192.168.1.1 (on Kali machine) to check if it works or not.

You can also login to the console if you got the credentials. Here is admin:admin.

If you decide to turn off the emulated firmware, just press Ctrl+A X. When you need to run again, do not run fat.py again because the firmware has already been built into an image. You only need to run the script which has already been generated.

cd firmadyne/scratch/<Image-ID>
./run.sh

Debugger

Build gdbserver for debugging purpose. There are many ways to build gdbserver. You can also download statically built server. There is a repo that stores some statically built. However I prefer to built the gdbserver myself as the ones in the github repo are pretty old, it may encounter some compatibility issues.

Refer to this blog post for references https://sheran.sg/blog/cross-compile-gdb-for-mips/. The blog was uploaded in 30 July 2024, just right before this project, so it works perfectly. Note: The blog built for MIPS x32 LSB however we need MIPS x32 MSB. We need to change mipsel-linux-gnu to mips-linux-gnu.

Build steps

We need to install tool chain for MIPS. Luckily, Debian package already has it.

**apt update && apt upgrade -y
apt install -y build-essential m4 gcc-mips-linux-gnu g++-mips-linux-gnu**