Hacking the dlink DIR-615 for fun and no profit Part 5: Multiple RCE’s

Its been a while since i last did some iot hacking and i missed it. So i decided to try it again with my trusty target, dlink dir-615. And in this writeup, i will show you multiple bugs that i found

CVE-2020–10216

First bug on the list is a remote code execution.

Here, it get the value of the parameter date and store it to the $s0 register.

And down below, this $s0 register is used as an argument to _system in the format string date -s %s making it vulnerable to remote code execution. The vulnerability exists in system_time.cgi

Now lets try it in burp suite, i tried sending the payload $(reboot), and

And after sending it, my emulation rebooted, just like what we expected

CVE-2019–9122 & CVE-2020–10214

Next bugs are two bugs in the same parameter. One is an rce (CVE-2019–9122) and the other one is a buffer overflow (CVE-2020–10214). While reversing, i found this parameter called ntp_server.

Here, it gets the value of the parameter and passed it to sprintf as an argument.

Then, the result of the sprintf is used into _system making it vulnerable to rce. This bug exist in ntp_sync.cgi

Now lets try to replicate it

After sending a request with the payload $(reboot), the emulation rebooted as we excpeted

If you remember, our input is passed an argument to sprintf and sprintf is widely known as a cause of buffer overflow due to the lack of length check. So, if we supplied a very long input, it should cause a buffer overflow overwriting the return address and crashing the program. Now to replicate it

I sent a very long string of A’s, looking at the emulation

We can see that we overwritten the return address $ra, with 414141 which is the equivalent of A in hex.

This is the end of the writeup, even though i didnt found any new bugs and get a new cve, we still found some pretty interesting bugs.

Join The bug hunting discord server: https://discord.gg/bugbounty