Hacking the dlink DIR-615 for fun and no profit Part 2: CVE-2020–10215
Hi. This is my second writeup on my hacking the dlink dir-615 series as i try to get my first cve. I found more vulns and will also make a writeup on it soon so stay tuned. So lets get started
I started up by reversing the httpd server of the dlink dir 615 firmware https://www.dlink.com.ph/dir-615/. What im doing when reversing, is following all user inputs. The function for getting the value of a post parameter is get_cgi so i just viewed all the cross references to get_cgi. While doing so, i found an interesting function sub_412e2c .
What it does is it takes the user input is the post parameter named dns_query_name using get_cgi then store it to the register $s4
Then this $s4 is used as an argument to _system
For those who dont know, _system is like a mixture of system and sprintf. It combined formatting and system in one command. Here, we can see that our input in $s4 is directly inserted into the format string making it vulnerable to command injection. Now we know that the parameter dns_query_name is vulnerable but we still dont know the vulnerable endpoint.
If we look at the top, we can see that it called the function __assert with one of the arguments being do_dns_query_cgi
I am not sure yet what __assert do but looking on other calls to it, i think it is the function responsible for getting the endpoint. For example
Here, it calls __assert with one of the argument being do_log_first_page_cgi. We can see that there is an endpoint called log_first_page.cgi
Another example is here
It calls __assert once again and an argument ping_response_cgi and we can see that there is indeed an endpoint called ping_response.cgi
So in our vulnerable function, it is safe to assume that the vulnerable endpoint is dns_query.cgi
So now, lets test it out. I emulated the firmware using firmware analysis toolkit and tried the bug that we found.
So we now know, that we should make a post request to dns_query.cgi, and we should add a parameter called dns_query_name which is vulnerable to command injection.
So i tried it up with burpsuite, i used the command ;echo poc > /tmp/test;. What this will do is that this will add a file in /tmp and echo poc into it. Lets test it out
And it worked
We successfully echoed out poc in the file /tmp/test meaning we have a command injection.
BONUS BUG: POST BASED REFLECTED XSS:
On the same function, i also found another bug. It is a post based reflected xss.
We can see that it get the value of html_response_page and store it to the register $s2. Then it is used as an argument to wprintf
Its value is formatted the the response with no filtering. The text where our $s2 is formatted is <html><head><script>function redirect(){document.location.href = ’%s’;}</script></head><script>redirect();</script></html> . So lets test it out
We can see that our input is reflected. Lets try to escape the string and inject our own xss
It works. Now lets make a csrf poc for this and test it in real browser
It works. Now we have a post based reflected xss. In my opinion, this is pretty useless since there is no cookies to steal. But it is there so we’ll take it
So in this writeup, we found a os command injection and a reflected xss. After googling it, i found out that the os command injection is already a cve for dir-825. CVE-2020–10215, so we cant get a cve from it :sad: . The other bug, xss, cve.mitre.org dont accept xss except for stored xss on their cve so we cant get a cve from that too. So no cve for me
Thanks for reading. I will make writeup on my other findings in the future.
Join the discord server: https://discord.gg/bugbounty
