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
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
Now lets try it in burp suite, i tried sending the payload
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
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
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