🕒 Reading Time: 5 minutes
How do we move forward? We cannot force manufactures to change their practices, and we can’t inform every vulnerable user. This is hard question as it comes down to liability, which is outside the scope of this post. We can suggest some simple steps moving forward for manufacturers and users alike. Manufacturers:
The Internet of Things
Consumers are ready for their lives to be networked, and manufacturers are more than willing to provide the devices to fill this demand. The issue with many of these vendors is that they place usability above security, such as by providing insecure default configurations. These configurations are designed to be deployed by the user with minimal effort. This is not just limited to the consumer device industry, but rather it extends to the enterprise market as well. While this makes deploying devices very easy, it also presents some issues. Many of these insecure default configurations allow SSH and SNMP access to the devices from the get-go, often providing a default username and password.
Over the past few years, we here at CARI.net have seen a large increase in DDoS attacks, bruteforce attempts and linux-based malware. Early last year, I began investigating these trends and their sources, and I found a disconcerting trend. More than half of the attacks we were seeing originated from network providers primarily comprised of residential customers. As an example, in July, we encountered the r0_bot/Pnscan.2 malware that was targeting a very specific group of credentials (root/root, admin/admin and ubnt/ubnt) with incredible success. It has become readily apparent that the majority of hardware vendors are not learning from old lessons. Due to the slow response time of MITRE and constant rejection for what should be considered security vulnerabilities, we have utilized the Distributed Weakness Filing Project to assign CVEs as we find them. We have notified vendors where possible, and have withheld several vulnerabilities as we have received contact from the vendors. Many of these vulnerabilities are not fixable by patches or by firmware updates and instead must be addressed by the users of these devices. Our hope is that the manufactures of network-aware devices will change their practices, and in turn solve this growing problem. The CARI.net Security Incident Response Team’s goal is to bring as many of these to light as possible. In this initial release, we will be covering 8 of the 20 vulnerabilities that we have confirmed and felt were most important to release. Since January 20th, 2016, we have notified 43 network providers, organizations and businesses of a total of 8,000 devices that were compromised and had their passwords sold, publicized or otherwise distributed for malicious purposes. The following vulnerabilities and devices made up more than half of all the compromised devices that we have detected in the past year. We will be continuing to publish these notifications as we confirm them.Routers
Cambium Networks ePMP1000
While reviewing devices found in several password dumps, we started noticing that many of the devices were Cambium ePMP1000 devices (reviewing the web interface). Upon further review, we found several issues affecting these devices.CVE-2016-85001
SNMP Default config on Camdium ePMP1000 running versions 2.1 thru 2.3.4 has community strings “public” and “private” for read and write respectively and SNMP is enabled by default. This allows a remote attacker to potentially reboot the device using the SNMP write community. In version 2.1, we could not find a way to disable the SNMP service.CVE-2016-85002
Camdium ePMP1000 has a default user of “admin” with password “admin”. This user is allowed to access SSH, which is enabled by default. This allows a remote attacker to have unrestricted SSH access to the deviceCVE-2016-85003
Camdium ePMP1000 has three additional web-access users with default passwords: user: “installer”/”installer” — Has admin writes, “home”/”home” — with read rights, and “read-only”/”read-only” with read-only rights. This is not user specific. The number of vulnerable Cambium ePMP1000 devices is unknown, but we did create shodan report that shows ~800 devices that are vulnerable to CVE-2016-85001.Ubiquiti AirOS and EdgeMax
Ubiquiti Networks is a company that produces a wide variety of networking equipment, ranging in point-to-point wireless connectivity to enterprise level corporate switches. Their products can be found in nearly every corner of the world, the highest concentration of which are in Brazil. However, due to the poor default config, these have been targeted for embedded infections.CVE-2016-85006
This is a rather broad CVE as it covers nearly their entire product base. All current products have the default user ubnt/ubnt and have SSH enabled by default. The ubnt user also has sudo access via sudo -s. This gives remote attackers the ability to make changes unbeknownst to the average user. From there they can create additional users, change system settings, and reset the device to factory default via CVE-2016-85019 and CVE-2016-85020 (Covered below). This particularly affects the AirOS and EdgeMax series. This is very well known to attackers, and Ubiquiti devices make for a great target as they can support SOCKS proxying, and a wide variety of malware. Also, since their product base also includes devices that run from small home wireless access points through corporate routers, there are plenty of targets.CVE-2016-85019
When an AirOS device switches back to factory defaults, it copies the /usr/etc/system.cfg to /tmp/system.cfg; saves and the reboots. An attacker utilizing CVE-2016-85006 can make changes to this default config to maintain persistence on a device. We have confirmed that this affects the current version and previous two versions of the AirOS firmware.CVE-2016-85020
Similar to CVE-2016-85019, current versions of the EdgeMax EdgeOS store the factory default configuration as well as other configurations used in default-type situations are located in /opt/vyatta/etc/. An attacker utilizing CVE-2016-85006 (above) could modify these configs, thus maintaining persistence across factory resets. Also, it would very easy for a remote attacker to reset the device to defaults.Mikrotik RouterOS
CVE-2016-85005
A long standing problem in the Mikrotik RouterOS is the default username and password. All versions including the 6.34 release have default user of “admin” with no password. While some folks change this, many devices are compromised within the first few hours of it being put on line. During our tests, a device with the username “admin” and no password was compromised within 15 minutes and had 9 unique pieces of malware running within 20 minutes. While not having a password can be helpful for initial setup, it should not be allowed to complete setup nor allow SSH access without a password.Network Storage
QNAP
QNAP NAS systems are great for having large amounts of storage locally. They provide a large range of appliances with a multitude of accessories, features and applications. However, like many other devices discussed in this article, they suffer from a critical default configuration flaw.CVE-2016-85004
Many QNAP NAS software versions, including the latest, have the default user “admin” with the password “admin”. This gives attackers full access to the NAS system, including the ability to disable logging, access all information on the device, and delete and/or add data remotely. All versions including the current latest have this vulnerability. During our work on pnscan.2/r0_bot, we found that nearly 40% of the devices compromised were QNAP NAS devices. These devices make excellent targets because they are a watered-down version of Linux. Rather than using BusyBox, which is favored by most embedded devices, many QNAP systems utilize sh or bash, which allows attackers to run a much wider range of malware. I worked directly with some folks whose devices showed up in password dumps and was able to gather quite a bit of intelligence. In one case, there was 5 gigabytes of malware stored on server.The Next Steps
How do we move forward? We cannot force manufactures to change their practices, and we can’t inform every vulnerable user. This is hard question as it comes down to liability, which is outside the scope of this post. We can suggest some simple steps moving forward for manufacturers and users alike. Manufacturers:
- Do not enable SSH or telnet by default.
- Admin users should have a password change forced on initial setup
- Services such as SNMP should not have a default configuration nor be enabled by default.
- When setting up a device, make sure you disable any services that you are not using. If you plan on using SSH, move it to a non-standard port
- Treat your networked device as if it were a bank account or other sensitive password. Remember that if this is a router or other networking device for your home or office, many transactions like online banking will pass through that device..
- Keep your device up-to-date and stay informed