Hacking the dlink DIR-615 for fun and no profit Part 3: CVE-2020–10213?
Hi. This is another writeup of my hacking the dlink series. This series is just me trying to find my first cve. So let get started
While going through all functions that accept user input, i found this interesting function called sub_40e5d0
What it does is first, it get the value of the parameter wps_sta_enrollee_pin
, then store it to register $v1
Then, the value of $v1 is stored to a global variable called enrollee
Then, the value of enrollee is passed to sprintf as a string to format to the string wsc_cfg
pin %s which is a command. Then the formatted string is stored to var_38
Then var_38
is passed to system.
So we have a potential command injection in here. So lets try it out. Looking at the top of the code, we can see these
Meaning, our vulnerable endpoint is set_sta_enrollee_pin.cgi
. If you dont know how i know that, check out my previous writeup where i explained the function __assert
So i tried it out in burp
And it worked.
We now have a command injection.
BONUS BUG: BUFFER OVERFLOW
As we know, the function used a sprintf. Sprintf is vulnerable to buffer overflow so that means this should be vulnerable to buffer overflow.
Looking at the code, we can see that the variable where our input get stored is var_38
var_38 is stored 0x18 bytes above the $sp. The value of $sp is -0x50. -0x50+0x18 is -56 so var_38
is 56 bytes below the base of the stack
Meanwhile, the value of the saved return address is stored in 0x4c bytes above $sp. -0x50 + 0x4c is -4 so the saved return address is 4 bytes below the base of the stack
56-(-4) is equals to -52 meaning there is 52 bytes between var_38
and the saved return address. Also, we know that our input is formatted to wsc_cfg
pin %s so we should also acknowledge that when knowing how many bytes is needed to overwrite the return address.
The string wsc_cfg
pin take a total of 12 bytes. So we have to deduct 12 bytes in our computed bytes between saved return address and var_38
. 52–12 is equals to 40. So lets try it out
I sent 40 bytes of A’s and 4 bytes of B’s. Now, in theory, this will overwrite the return address to BBBB and so, we can control the instruction pointer to BBBB and it will crash the system.
And it worked. We can see that we managed to control the epc(instruction pointer) to point to 42424242 which is BBBB.
So we have a bufferoverflow and we can control the epc. This may result to remote code execution but it is beyond my knowledge for now. So for now, we have a buffer overflow that will crash the server resulting to dos. If you know or have experience on buffer overflows on mips, please help me out. Thanks
So in this writeup, we managed to find a remote code execution vulnerability. After some googling, i found out that this bug is already a cve https://nvd.nist.gov/vuln/detail/CVE-2020-10213 so again, no cve for me :sad: . So thats the end of this writeup, thanks for reading.
Join the discord server: https://discord.gg/bugbounty