After my previous adventures with a Wavlink router led to Remote Code Execution, I decided to pivot my focus. I started by looking at what else was exposed on the router, and then purchased two other Wavlink devices to see if they had the same issues. I got two Wifi extenders, the WL-WN579G3 and the WL-WN579A3. What I found was not a surprise – they were just about as vulnerable as the router I started with. In fact, with the exception of the page that had the plaintext username/password, every single live_(string) page seemed almost exactly alike across all three devices. Some of the wording or specific information was different, but the meat and potatoes was always the same when comparing the page on all three devices
One of the first things I noted on the Wavlink router was the repeated calls to live_(string) endpoints. After I discovered that they could be accessed without any authentication, I decided to go through each page one by one to see what could be accessed.
Many of the pages I could not find a rhyme or reason for – there is a lot of duplicate information that I feel could be easily retrieved without serving it on a web page. Perhaps it was the developers intent to make all this information accessible to the world, or maybe they just forgot to clean some things up. Who knows? But enough of the speculation – lets get into the good stuff. Just a reminder – every screenshot below is of a web page that is externally accessible without requiring authentication and contains sensitive data.
Lets start with the basics. If you recall CVE-2020-10971 aka my previous post, you can achieve RCE if there is an authenticated user at the time. Instead of having to guess if there is a user logged in, you can get that information yourself by simply going to a web page.
The “userlogin” piece corresponds to how many active sessions there are at the point in time – as you can see, when I viewed this page I did not have an active session.
Another page gives specific device info, such as model, IP address, and MAC address
But it gets better. Want a summary of of the slabinfo of the device? Look no further then the output of a script on one of these pages.
But wait… theres more! How about a summary of the nearby networks, including name, BSSID, Security, and signal strength?
Not impressed? Check out this set of more in depth information that I didn’t do anything with.
You know what, that one was boring. Lets make up for it by looking at my home devices with their hostname, IP, and MAC address thanks to their DHCP leases.
Want to get more in depth and look at every running process on the device? Say no more.
The best part is, the functionality to backup the configuration of the device does not use any authentication. For the router, it at least encrypts the backup file before sending it. However, you can achieve full RCE on the router without the backup file, and once you have access to the back end you can find out for yourself that it was encrypted with a hard coded, very short key.
For the extenders though its open season. The backup functionality works differently on the backend and also has no encryption whatsoever. With a simple post request, you can retrieve the entire configuration of the device (hundreds of options that I didnt bother playing with). The most important lines are right near the top, where it gives you the username and password in plain text.
So while the path is slightly different, we still have a way to get the username and password without any authentication, which can be combined with CVE-2020-10971 to achieve Remote Code Execution by creating a session. The various information disclosure vulnerabilities that I mention in this post are all included in CVE-2020-10973, CVE-2020-10974, and CVE-2020-12266. Once again, Wavlink did not respond to any of my attempts at communication. After just a small amount of testing, the main thought I have about my Wavlink devices is that Im looking forward to never plugging them in again.
Timeline:
2/19/2020 – Initial discovery and notification
2/29/2020 – Follow up notification after no response
3/23/2020 – Follow up notification after no response indicating plans to submit for CVE
4/3/2020 – Additional communication attempts failed to get response, CVE request submitted
5/7/2020 – CVE published
6/30/2020 – Additional details published
James Clee 