Wavlink Quantum D4G Zero Day — Part 01
So I have been advertising I will be releasing some zero-days and here we go with the first of a few; Before I go into this let me go over a little bit of background on this. So I found this authentication problem which I will toss in the CWE-294: Authentication Bypass by Capture-replay bucket back in May 2022. I attempted proper disclosure by not informing anyone of this problem and I sent information including the issue, the logic behind the issue, and the binary that holds this vulnerability (login.cgi) to the vendor. It took a few attempts to get communications flowing properly, but eventually, they had gotten all the information needed, confirmed it was sent to their team, and then basically said thanks and ended communications. Well, I have been following their updates and watching listings and it does not seem like it’s gotten anywhere, unfortunately, so here we are. I would like to note, that I do not promote any form of unethical behavior with this kind of information, and while this is not a highly rated vulnerability, in my opinion, there are some other vulnerabilities I will be releasing in the upcoming weeks for this device that when chained together can increase the overall rating.
The main issue really comes down to a lack of HTTPS being utilized and an alternative form of encryption being utilized to handle authentication. The device upon login on the client side will create a random key in which the user supplied password is concatenated with, an MD5 hash is then computed from this string and sent to the device for authentication as the password parameter of the POST request (the MD5 hash is, not the password itself), and the key is sent as the key parameter of the POST request, as shown below.
It all sounds fine until you realize the device does not supply the key, so it cannot check if the request is a replay or not. Upon receiving the login POST request, the device essentially performs the same steps that are performed client side. Here we can see the POST request parameters getting pulled from the request the device receives.
Next, the MD5 hash is generated by concatenating the user supplied key and the password saved on the device, then running md5sum on the value. A little below the screen shot shown below, the device runs the command placed in the variable STACK, I just cut it off because there's a lot going on between it and this chunk of code. Remember, the key is not supplied by the device, so it does not perform any form of checks to see if this request is a replay, it only cares that the user supplied MD5 hash and the computed hash it calculates using the user supplied key and the devices stored admin password match, which if the password hasn't changed, any captured POST request’s MD5 and key will work when used together to log in.
And finally, we compare strings to see if we are granted access to the admin console.
So that's a brief overview of this security issue I came across when analyzing this device, there are more to come in the upcoming days. If you have any questions let me know, as always I hope this was fun and you learned something.
