Any Zyxel Devices on Your Network? Are you Sure? CVE-2020-29583

It seems these days before you finish a cup of coffee the next headline is already popping up about something that could possibly pose a security threat to your networks or your customer's networks. Whether it be something as broad based as the Solarwinds Vulnerability, of which the total impact may not be known for quite some time, or something more specific to a certain hardware platform, there is no shortage of crisis on any given day.

Having tools to mitigate these as they arise is crucial if you plan on still performing day to day tasks not directly related to locating and putting out the next fire before it spreads. A tool providing non-intrusive, consistent and contextual visibility of networks you are responsible for is a must. Although sometimes we think we have all the visibility we need or we think we know what is attached to our networks, often that is not the case.

More times than not, when working with customers, we discover that there are devices on the network they were not aware of. This information is the first building block for a solid Cybersecurity plan because how can you plan on what policies and access you want to assign if you don't even know what is out there? Hence, a solid visibility tool that is easy to deploy and manage is non-negotiable.

Back to the seemingly non-stop stream of vulnerability announcements and fires to put out, or, at a minimum, require you to check if there is any smoke in your environment. One such recent announcement was for a hard coded, unchangeable default password that was shipped on many Zyxel devices. As noted in this NetSec article, it was a large number of devices that were shipped out:

"Cybercriminals have started exploiting the hardcoded credential vulnerability (CVE-2020-29583) in Zyxel networking products that was announced by Zyxel on December 23, 2020.

The vulnerability, identified by Niels Teusink of the Dutch cybersecurity firm EYE, affects around 100,000 Zyxel devices, including its firewalls, AP controllers and VPN gateways. The flaw was assigned a CVSS V3 score of 7.8 out of 10 (High severity).

Teusink discovered a hidden administrative account with the username zyfwp that had a password that could not be changed. The password was found in plaintext within the firmware. While Teusink did not reveal the password, it has since been publicly disclosed on Twitter"

You may be thinking to yourself, I don't have to worry about that, I don't have any Zyxel devices installed on my network. However, are you willing to bet on that if you are only using a single fingerprinting approach for device discovery? If it does exist, how easy is it to track down and how do you verify quickly and easily if it is linked to the vulnerability?

Enter Genian Device Platform Intelligence (GDPI). GDPI is included with Genian NAC to provide visibility for the NAC solution, but is also available as a stand alone product as well which includes full database purchase options or Cloud API subscription options. Let us examine some of the information provided by GDPI for Xyxel.

In the image below, we can find an example of a device linked to the Zyxel vulnerability in question. This is one of the platforms shipped with the hard coded username and password that is being exploited. Note the additional information that the platform entry in the GDPI database provides that is above and beyond typical device fingerprinting/profiling:

• Actual image of the device
• EOS/EOL data
• Manufacturer's HQ Country and Business Status (Out of Business and Acquisitions show up here if applicable)
• Any linked vulnerabilities

Note that the first vulnerability shown is the one mentioned in the NetSec article. So, now that we have seen the level of detail provided by GDPI for specific platforms, how can we be sure if any of these devices are on a network? Let's use a Genian NAC example and see how this information is represented in the UI.

As mentioned previously, Genian NAC leverages GDPI to identify platforms connected to the networks being monitored by the system. Components from the GDPI database fields are then leveraged in various ways, one of which includes the CVE view in the Genian NAC UI. In the image below, you can see the main CVE list in the UI which has various search options including an option to search by manufacturer. In this example, we have populated that field with Zyxel (it autocompletes to Zyxel Communications Corp) and clicked search. There are a total of 43 Zyxel platforms found in the database (some omitted to fit the screenshot) and of those 43, 11 of the platforms are linked to CVE-2020-29583. Of special note here is that, although 11 platforms in the GDPI database are linked to the CVE, the "Nodes" column reflects that no nodes being monitored by Genian NAC, in other words, no nodes attached to the network(s) presently, are affected.

If we wanted to drill down deeper regarding which platforms are affected, we can click on the "11" hyperlink. In the image below, you can now see the details of the 11 platforms linked to the CVE as well specific references and tools that provide more information and the information used to link the platform to the CVE.

This is just one example of how GDPI can be utilized. By combining the low level visibility provided by Genian NAC's Network Sensor passive and active technology with the GDPI database, the level of visibility required to assist with scenarios like this are provided all within a single system. Fingerprinting 1.0 simply does not provide this level of granularity and context. Additionally, by leveraging crowdsourcing from over 1600 customers globally across every vertical, the GDPI database is updated weekly with devices across all spectrums in various categories including IoT/OT.

For more information on Genian Device Platform Intelligence or Genian NAC, visit Genians today or each out to me directly.