|
|
Within five years, some suggest there will be over 30 billion IoT devices worldwide, and these “things” will generate 79.4 zettabytes of data. The explosion of connected devices in the home, enterprise and industrial environments increase the attack surfaces of these entities many times over. Moreover, many of these devices are insecure by nature, and others, although possessing reasonable security mechanisms, are left exposed due to poor cyber hygiene and lack of IoT security know-how. In this post, we look at some of the dangers posed by IoT devices and how they can be addressed.
Enhanced DDoS Attacks with CallStranger
The quest to make connected devices cheap and easy to install and operate has resulted in the creation of less-than adequate security mechanisms – such is the case with the IP Cameras made by China-based HiChip, for example, which has sold around a 100,000 wireless cameras in the UK, all of which are vulnerable to hacking. But even if a device is made according to desired security standards, the protocols it relies on are sometimes seriously flawed.
Earlier this year, Turkish researcher, Yunus Çadırcı, identified a new vulnerability in UPnP (Universal Plug and Play), a set of networking protocols that permits devices to seamlessly discover each other’s presence on a network and establish functional services for data sharing. The vulnerability – CVE-2020-12695, aka “CallStranger” – allows attackers to subscribe to devices and get them to send traffic to any IP address. This enables attackers to launch large-scale amplified TCP DDoS reflection attacks by sending a request to a third-party server, using a spoofed IP address. The response is much larger in size and is returned to the spoofed IP address of the unwitting victim, creating powerful DDoS attacks.
In addition, CallStranger allows attackers to bypass DLP and network security devices to exfiltrate data, and even scan internal network ports, those that are not otherwise exposed to the internet.
This vulnerability affects billions of UPnP devices on local networks and millions of UPnP devices on the Internet, almost all of which need to be updated. The following devices have been identified as among those that are known to be vulnerable to the CallStranger bug, although other devices could also be at risk:
- Windows 10 (Probably all Windows versions including servers) – upnphost.dll 10.0.18362.719
- Xbox One- OS Version 10.0.19041.2494
- ADB TNR-5720SX Box (TNR-5720SX/v16.4-rc-371-gf5e2289 UPnP/1.0 BH-upnpdev/2.0)
- Asus ASUS Media Streamer
- Asus RT-N66U Firmware: 3.0.0.4.382_51640-g679a7e3
- Asus Rt-N11
- Belkin WeMo
- Bose SoundTouch 10 (http://x.x.x.x:8091/QPlay/Event)
- Broadcom ADSL Modems
- Canon Canon SELPHY CP1200 Printer
- Cisco X1000 – (LINUX/2.4 UPnP/1.0 BRCM400/1.0)
- Cisco X3500 – (LINUX/2.4 UPnP/1.0 BRCM400/1.0)
- D-Link DVG-N5412SP WPS Router (OS 1.0 UPnP/1.0 Realtek/V1.3)
- Denon X3500H (LINUX UPnP/1.0 Denon-Heos/155415)
- EPSON EP, EW, XP Series (EPSON_Linux UPnP/1.0 Epson UPnP SDK/1.0)
- HP Deskjet, Photosmart, Officejet ENVY Series (POSIX, UPnP/1.0, Intel MicroStack/1.0.1347)
- Huawei HG255s Router – Firmware HG255sC163B03 (ATP UPnP Core)
- Huawei MyBox (Linux/3.4.67_s40 UPnP/1.0 HUAWEI_iCOS/iCOS V1R1C00)
- JRiver DLNA Server 19.0.163 (Windows, UPnP/1.1 DLNADOC/1.50, JRiver/19)
- LG webOS TV OLED55C9PLA (Linux/i686 UPnP/1,0 DLNADOC/1.50 LGE WebOS TV/Version 0.9)
- Linksys router (http://x.x.x.x:49152/upnp/event/Layer3Forwarding)
- NEC AccessTechnica WR8165N Router ( OS 1.0 UPnP/1.0 Realtek/V1.3)
- Philips 2k14MTK TV – Firmware TPL161E_012.003.039.001
- Samsung UE55MU7000 TV – Firmware T-KTMDEUC-1280.5, BT – S
- Samsung MU8000 TV
- Synology NAS (Linux/3.10.105, UPnP/1.0, Portable SDK for UPnP devices/1.6.21)
- TP-Link TL-WA801ND (Linux/2.6.36, UPnP/1.0, Portable SDK for UPnP devices/1.6.19)
- TP-Link Archer VR200 (Linux/2.6.32.42, UPnP/1.0, Portable SDK for UPnP devices/1.6.19)
- Trendnet TV-IP551W (OS 1.0 UPnP/1.0 Realtek/V1.3)
- Zyxel VMG8324-B10A (LINUX/2.6 UPnP/1.0 BRCM400-UPnP/1.0)
The Ripple20 Supply Chain Vulnerability
A problem that affects IoT devices in particular is the use of third-party code and libraries which may never be updated by the vendor after the device has shipped. In some cases, the vendor may not even have the means of updating such code without a device recall, which is often impossible as devices tend to remain in use for far longer than the minimal vendor support that is typically offered with cheap IoT devices.
Researchers from JSOF research lab discovered a series of zero-day vulnerabilities in a widely used low-level TCP/IP software library developed by Treck, Inc. The library, believed to have been first released in 1997, implements a lightweight TCP/IP stack. Companies have been using this library for decades to allow their devices or software to connect to the internet via TCP/IP connections. JSOF named the 19 vulnerabilities “Ripple20” (after the year 2020, not the number of vulnerabilities).
Because the flaw resides within the supply chain of hundreds of millions of IoT devices worldwide, with an unknown number either unpatchable or no longer supported by their manufacturers, this vulnerability is going to be with us for a long time to come. Attackers that discover a Ripple20 vulnerable device on a network can abuse it to achieve remote-code execution, allowing for data theft, malicious takeovers and more.
Botnets | Making The Most Out Of Insecure Devices
It’s not just specific vulnerabilities, however, that make IoT devices such a security concern. It’s also the fact that they tend to suffer from no or poorly configured security configurations, often existing on a network with known default credentials. This was famously exploited by the Mirai botnet back in 2016, which spread through 100s of thousands of IoT devices by using nothing more sophisticated than a hard coded list of known default credentials for particular devices.
In the time since the first Mirai attack, many other botnets have risen, but, even today, Mirai and its variants are still predominant. Mirai variant Echobot has 71 unique exploits, 13 previously unexploited. It surfaced a year ago and seen in the wild multiple times between October and December. Additional botnets, such as the IoTroop botnet, which shares an extensive code base with the leaked Mirai source, is also fairly active, especially in Japan, where it accounts for 87% of all botnet detections. Another botnet Dark Nexus, has also been active in the past year.
More recently, researchers at 360Netlab discovered a new IOT P2P botnet they dubbed, “HEH”. Written in Go and supporting multiple architectures, the HEH botnet is designed for destruction. While researchers say it is still very much in the early stages of development, one feature already built-in is the ability to wipe all data on the infected device. HEH spreads via brute force attacks across Telnet ports 23 and 2323.
That attackers are increasingly targeting IoT devices to recruit into botnets is evident. A recent study found a 46% increase in cyber attacks on smart homes and IoT devices in enterprise and industrial environments. Another study found that more than 50% of IoT devices are “protected” by the default password “12345”. Another research found many sellers on the darknet offering “ready to go” botnets for sale.
A Ponemon Institute study conducted in 2020 suggests that known data breaches caused by insecure devices have doubled since 2017. According to the study, an overwhelming number of security professionals – as many as 90% – expect their company to experience a cyber attack or data breach caused by insecure IoT devices or applications in the next two years. More than three-quarters of respondents in the Ponemon research said that IoT risks pose a serious threat to high-value data assets. Nearly 50% of responders reported that it was not possible to maintain an inventory of IoT devices in the workplace given their current security and auditing tools. From the devices that could have been identified, less than 50% have adequate security.
Solving the IoT Security Headache
In some cases, there are known remediations for specific vulnerabilities. For example, there is specific advice for the CallStranger vulnerability discussed above. You can also run this script to check against the CallStranger (CVE-2020-12695) vulnerability.
In other cases, there’s not much you can do other than take a vulnerable device off the network, assuming you can find it to start with, and of course, no amount of vulnerability patching is going to protect your devices from a botnet if the device configuration uses weak or default security controls.
Due to the complexity of the IoT problem and the amount of human effort required by admins to keep up with the ever-increasing load of new IoT devices joining the network, it’s essential to get some automated help from your security solution.
A solution like SentinelOne’s Ranger, for example, adds global network visibility to your armoury. It allows you to detect and alert on new IoT devices in your network, isolate device-based threats and even hunt for suspicious network devices across the entire network. Just as importantly, it can do this without needing any additional specialty hardware or software as Ranger is already built-in to the SentinelOne agent and uses protected endpoints themselves as distributed network sensors.
Conclusion
The proliferation of IoT ‘smart’ devices is only set to continue, and with a continuing lack of industry standards or government regulations for IoT device security, the risk presented by such devices on enterprise networks is similarly bound to increase. Gaining visibility into your network and having the means to control all devices on it is fundamental to your security posture. If you would like to learn more about how the SentinelOne platform and SentinelOne Ranger can help, contact us for more information or request a free demo.
