Wavlink Quantum D4G Zero Day — Part 02

Corey Hartman
3 min readDec 22, 2022

So I have started releasing zero days for the Wavlink Quantum D4G, as I mentioned in part one of this series, I attempted to contact the vendor with issues, and while they communicated with me, it seems they just kind of ignored the issues and stopped communications. So here we are, making these issues public now so we can get awareness on these vulnerabilities. As always when I post zero day information, I do not promote any form of unethical behavior with this information, it is intended to be both educational and to bring awareness to the security issues with this device or any other devices I write about; With that said, lets get started. So this is a nasty one, I originally wanted to post another authentication bypass I had first, however, it was not nearly as dangerous as this issue, as this results in complete administration control of a device with no authentication required. For this issue, I would toss it into the CWE-284: Improper Access Control bucket. And while I think it’s more than just an access control issue, that seems to be the biggest issue leading to this problem.

The main issue this time comes down to access control as I stated, specifically how the developers of this firmware implemented lighttpds CGI authentication and access control, so here’s a question for you all… What do you get when you put bash scripts in your CGI-BIN directory and perform cgi.assign = (“.sh” => “”) with no authentication as shown below from the devices lighttpd.conf file?

You get exactly what you told the computer to do, and that is allow anyone to run the bash scripts in the CGI-BIN directory. Well, that isn’t really a big deal is it? Well it is if they shouldn’t be able to run them because of what those scripts can do. In our vulnerability being discussed here, if you go to http://192.168.10.1/cgi-bin/ExportLogs.sh we get the ability to download current system logs with no authentication required. I know, you’re thinking “Uh oh! logs can contain sensitive information, that’s not good!” Yes, you are right, they can contain sensitive information but this is much worse, in our case we not only get logs, but we get the devices environment variables, which just so happen to contain the administrators credentials.

So that’s it, a quick vulnerability to discuss that is simple and yet absolutely nasty, as now you are giving the keys to the kingdom. Anyways, as always I hope you learned something and had fun looking over this. If you have any questions feel free to reach out.

--

--

Corey Hartman

Phd candidate who researches applying machine learning to reverse engineering