Many thanks to Jon Hart, who collaborated on this research.

Last week, a critical configuration weakness in Cisco® routers used in home/small-office environments as a way of connecting local networks to central office networks was responsibly disclosed on the Full Disclosure mailing list. If the web-based interface is enabled on these devices, attackers can obtain complete configuration information of the device, including the device username, hashed password, details of the internal network, and potential VPN connection secrets.

Cisco® has issued a patch for these RV320/RV325 routers, and organizations are encouraged to apply this patch to all affected devices as soon as possible, as Rapid7 Labs has detected 35 malicious sources performing opportunistic probes for these devices via Project Heisenberg. You can tell if your devices are exposed by performing an unauthenticated access to http://aa.bb.cc.dd/cgi-bin/config.exp and examining the results.

Rapid7 Labs was able to determine the possible extent of the exposure without resorting to configuring a new Project Sonar scan using the weak configuration URL exposure. Cisco® provides SSL certificates for these devices, and they are all self-signed SSL certificates with the subject and issuer containing the MAC address of the device in question and an OU corresponding to the model number:

By examining HTTP[S] scan data across all study ports and looking for markers within the certificate, as well as markers in the retrieved HTML, we have been able to determine that there are over 19,000 exposed devices on the internet, which is much higher than other researcher estimates:

The vast majority of these devices are on residential or small-business ISP networks, which is to be expected given the use case for these VPN routers. Nearly all of the exposed devices were found listening on the default HTTPS port, 443/TCP, or a common alternate HTTPS port, 8443/TCP.

Exposed does not necessarily mean vulnerable, but ideally, these web admin ports should not be exposed by default and only enabled when needed.

Pulling on a hexadecimal thread

Rapid7 Senior Security Researcher Jon Hart noticed the presence of MAC addresses in the SSL certificates and decided to pull on that thread a bit. Most of the MAC addresses in the CN field were unique (~15,000), and most belonged to “Cisco Systems, Inc”. But, we noticed there were some duplicate MAC addresses. One MAC address in particular—00:0e:a0:13:03:88—that belongs to NetKlass Technology Inc. appears on over 1,200 devices that are not isolated to a particular geographic region or autonomous network:

The NetKlass ‘About us’ page shows that they are a supplier to U.S. corporations and there is evidence that they’ve been a supplier of this class of equipment to Cisco® in the past prior to Linksys being sold to Belkin in 2013. It would appear that this exposure is perhaps due to embedded code from this legacy supply chain trail.

Duplicate MAC addresses can be a problem in a local network since it means that devices in the same network will stomp all over each other when it comes to things like ARP requests and responses. But, because this tends to be a noisy failure, it tends to be pretty easy to diagnose and fix—just unplug one of the devices or rewrite the offending MAC addresses, and the problem is solved.

Rapid7 Labs will continue to monitor our honeypot nodes and provide updates if further adversarial activity is discovered.

Cisco® is a registered trademark of Cisco Systems, Inc. and/or its affiliates in the United States and certain other countries.