Home Hacking the dlink DIR-615 for fun and no profit Part 3: CVE-2020–10213?
Post
Cancel

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

This post is licensed under CC BY 4.0 by the author.