So, here we are again with yet another fun zero-day found, and this time I wrote a little Python script to show a proof of concept for this exploit which will be provided. I am going to try to make this post short and sweet just to get to the point, but as always, I do not promote any unethical behavior with this information, it should only be utilized for educational purposes and to bring awareness to this issue.
This vulnerability I would say falls under CWE-77: Improper Neutralization of Special Elements used in a Command (‘Command Injection’), as you’ll see, this all comes down to the lack of filtering user input. So within the router, as many new devices have now a user is able to attach a USB drive and setup NAS (Network Attached Storage), so users on the network can share files and be able to access files across your LAN. I would say it seems pretty convenient, however my paranoia has always stopped me from using this feature at home as I know it opens up a larger attack surface for users. When a user of this feature sets up a device, they must input a username and password which is where this problem comes in. During the request being made for this, the device will retrieve the username which is the HTTP POST parameter “User1”, as shown below. Unfortunately what happens next is that the input of this parameter is not run through a filter, and the following occurs.
As we can see above in the image, the HTTP POST parameter “User1” is retrieved, and without a filter run on it, the input is placed into a char array and then is used as the argument for the function “system”, making whatever goes in there execute without consideration of what actually may be there. This is where we can do some nasty things. Shown below we can see a modified POST request causing the device to reboot.
Rebooting isn’t really going to hurt anything, and infact, it probably is needed on most peoples devices. This exploit does require authentication to trigger, but luckily for us, there are no CSRF tokens being checked, so this could be utilized in a CSRF style attack. Any-who, what if we did something a little more sneaky? What if we told the device to dump credentials and other information to the CGI-BIN directory where we already know a misconfigured lighttpd lives? What if for this next part, we got an administrator of the device to click a link with the modified payload we are about to present? With the “User1” parameter now set to “share; ralink_init show 2860 >> dump ;” we will have the CGI-BIN directory have a text file created containing credentials and other information available, then we can make an HTTP GET request to “http://192.168.10.1/cgi-bin/dump" and something fun happens, it allows us to download that file with no authentication required! The same information from the log dump issue we presented in part 2 is now available once again to us!
Below is a script to automate this entire process for a proof of concept, obviously no CSRF is utilized in this example, but you'll see how it could be. https://github.com/Xenios91/Wavlink-DG4-ZeroDays/blob/main/WavlinkD4G_NAS_Command_Injection.py As always, I hope this was fun and you learned something.