www.malbytes.net
Open in
urlscan Pro
2a00:1450:400e:800::2013
Public Scan
URL:
https://www.malbytes.net/2022/07/wavlink-quantum-d4g-zero-day-part-01.html
Submission: On September 21 via api from US — Scanned from DE
Submission: On September 21 via api from US — Scanned from DE
Form analysis
1 forms found in the DOMhttps://www.malbytes.net/search
<form action="https://www.malbytes.net/search" target="_top">
<div class="search-input">
<input aria-label="Search this blog" autocomplete="off" name="q" placeholder="Search this blog" value="">
</div>
<label>
<input type="submit">
<svg class="svg-icon-24 touch-icon search-icon">
<use xlink:href="/responsive/sprite_v1_6.css.svg#ic_search_black_24dp" xmlns:xlink="http://www.w3.org/1999/xlink"></use>
</svg>
</label>
</form>
Text Content
Skip to main content Search SEARCH THIS BLOG MALBYTES A cyber operations blog Share * Get link * Facebook * Twitter * Pinterest * Email * Other Apps Labels * vulnerability * zeroday July 05, 2022 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 recieves. 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 theres 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 hasnt 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 thats 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. Share * Get link * Facebook * Twitter * Pinterest * Email * Other Apps Labels: vulnerability zeroday COMMENTS POST A COMMENT POPULAR POSTS May 11, 2022 SELF MUTATING CODE: OBFUSCATION FUN - PART 02 Share * Get link * Facebook * Twitter * Pinterest * Email * Other Apps Post a Comment Powered by Blogger Corey Ph.D. Student, MSCS, Software Dev Visit profile ARCHIVE * September 20221 * August 20221 * July 20224 * June 20222 * May 20221 * April 20223 LABELS * code1 * CVE1 * obfuscation3 * other2 * vulnerability6 * zeroday5 REPORT ABUSE Diese Website verwendet Cookies von Google, um Dienste anzubieten und Zugriffe zu analysieren. Deine IP-Adresse und dein User-Agent werden zusammen mit Messwerten zur Leistung und Sicherheit für Google freigegeben. So können Nutzungsstatistiken generiert, Missbrauchsfälle erkannt und behoben und die Qualität des Dienstes gewährleistet werden.Weitere InformationenOk