Last Updated: 2021-01-06 14:09:24 UTC
by Johannes Ullrich (Version: 1)
It was the day (or two days actually) before Christmas when Niels Teusing published a blog post about a back door in various Zyxel products . Niels originally found the vulnerability in Zyxel's USG40 security gateway, but it of course affects all Zyxel devices using the same firmware. According to Zyxel, the password was used "to deliver automatic firmware updates to connected access points through FTP" . So in addition to using a fixed password, it appears the password was also sent in the clear over FTP.
Zyxel products are typically used by small businesses as firewalls and VPN gateways. ("Unified Security Gateway"). There is little in terms of defense in depth that could be applied to protect the device, and in ssh and the VPN endpoint via HTTPS are often exposed. The default credentials found by Niels are not just limited to ftp. They can be used to access the device as an administrator via ssh.
So yet again, we do have a severe "stupid" vulnerability in a device that is supposed to secure what is left of our perimeter.
Likely due to the holidays, and maybe because Niels did not initially publish the actual password, widespread exploitation via ssh has not started until now. But we are no seeing attempts to access our ssh honeypots via these default credentials.
The scans started on Monday afternoon (I guess they first had to adapt their scripts in the morning) initially mostly from 220.127.116.11. On Tuesday, 18.104.22.168 joined in on the fun and finally today, we have 22.214.171.124. The last IP has been involved in scanning before.
What can/should you do?
- If you are using affected devices: UPDATE NOW. See Zyxel's advisory here. Please call Zyxel support if you have questions.
- If you are using any kind of firewall/gateway/router, no matter the vendor, limit its admin interface exposure to the minimum necessary. Avoid exposing web-based admin interfaces. Secure ssh access best you can (public keys...). In the case of a hidden admin account, these measures will likely not help, but see if you can disable password authentication. Of course, sometimes, vendors choose to hide ssh keys instead of passwords.
- Figure out a way to automatically get alerts if a device is running out of date firmware. Daily vulnerability scans may help. Automatic firmware updates, if they are even an option, are often considered too risky for a perimeter device.
- If you are a vendor creating these devices: get your act together. It is ridiculous how many "static keys", "support passwords" and simple web application vulnerabilities are found in your "security" devices. Look over the legacy code and do not rely on independent researchers to do your security testing.
And as a side note for Fortinet users. See what the new year just got you: