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

Form analysis 1 forms found in the DOM

https://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