Cybersecurity Awareness Month - IoT and SOHO devices

[trobinson667]

Cyber Security Awareness Month - Securing IoT devices

Earlier this month, I did a write-up on browser/web browsing security controls that can be used to help keep you and your user community secure at home, and at work.

This time around, I want to talk a little bit more about a subject that has been a focus for me for the past few months, and that is IoT device security.

IoT stands for “Internet of Things” and is a pretty broad spectrum covering just about any device that has some form of embedded hardware and software that supports network connectivity of some sort. to me, the label includes SOHO (Small Office/Home Office) devices like routers, NAS (Network Attached Storage) devices, Access Points, Wireless repeaters and just about everything in between.

In my opinion, IoT devices also encompass a lot more than that, For example, building management/monitoring suites, Multifunction printers with web management interfaces, DVRs, networked security cameras, serial to ethernet controllers to provide network access to serial-only devices, and much much more. I’m picking on these device categories in particular, since as Shodan, Censys, and other Internet Search Databases will all tell you: Their management interfaces are very often exposed to the public internet

There is a whole galaxy of exposed embedded/IoT devices out there. (Image credit: shodan.io)

In some cases, this may be an intentional configuration state that is necessary for one reason or another, and in other cases, it could be an overlooked misconfiguration.

Risks factors of unsecured IoT devices

Why am I making such a big deal out of this? Here on the Emerging Threats team, we concern ourselves with a wide array of threats out there. The threat landscape is gigantic, but more and more recently, I’ve been paying attention to the deluge of vulnerabilities for IoT devices, and writing detection for those vulnerabilities. Why? because the bad guys are using them, and here’s how:

1. Initial access - If IoT devices are plentiful, vulnerable, barely ever managed unless they go down, and connected to the public internet, bad guys interested in internal network access – including ransomware groups, or nation-state threat actors – have no problem using them for initial access. For a real-world example of this, take a look at “Phineas Fisher” and his account on how he compromised the organization “Hacking Team”. While this write-up is a little bit long in the tooth, the fact remains is that out of the options available, attacking an exposed, embedded device at the network border was the chosen method for initial access because it was the path of least resistance.

2. Bypass security controls - In general the security of desktop and server operating systems has been getting better and better. On top that, bypassing EDR (Endpoint Detection and Response) while possible, is a complicated matter. Why bother when bad guys can abuse an embedded device with very little in the way of security controls?

   • IoT devices are frequently built with older versions of the Linux kernel. Most of these devices do not benefit from newer technologies like KASLR - (Kernel Address Space Layout Randomization) and do not compile system binaries with PIC (Position Independent Code). ASLR and PIC are technologies that make it significantly harder to exploit buffer overflows by randomizing the position of kernel code, as well as the code and libraries used by executables. These technologies make it significantly harder to convert memory corruption (buffer overflow, etc.) vulnerabilities into remote code execution.

   • On top of that, common embedded device frameworks (such GoAhead Webs, and/or Boa httpd) have numerous web application vulnerabilities – Cross Site Scripting, Authentication Bypasses, and worst of all, Command Injection. Chances are, if the device is sending HTTP requests to an URI that starts with /goform or /boafrm, you’re in for a bad time. GoAhead Webs proudly displays the numerous device vendors that use their framework, while Boa HTTPd has been unmaintained in any official capacity since 2005. From my perspective as a rule writer, these are the most common, vulnerable IoT device frameworks that I see on a day-to-day basis.

   • A real-world case in which attackers used embedded devices for bypassing security controls comes somewhat recently, when a ransomware actor (Akira) compromised a network connected camera, and used its ability to connect to SMB shares to encrypt important files without ever needing access to a Windows host.

3. To build ORB (Operational Relay Box) Networks - Many different types of threat actors are utilizing IoT devices to build ORB networks, or networks of compromised devices to act as proxies in order to obfuscate the true source behind malicious activity. Depending on the community, these “ORBs” can also be referred to as “Jump Boxes”, “Residential Proxies”, “Redirectors”, “Non-Attributable Infrastructure”, etc., but the overall idea is the same: hide the true source behind malicious activity to make attribution and attack prevention more difficult.

   • Recent examples of IoT devices being used in this manner include the “PolarEdge Botnet” researched by both Censys, and Sekoia.io. Additionally, there is the case of the Chinese-aligned threat actor group “Volt Typhoon” and their “KV Botnet” ORB network, again consisting of compromised IoT devices.

This image, from this article by Team Cymru, demonstrates how ORB networks are used to obfuscate the true source of malicious activity.

4. DDoS Botnets, Coinmining botnets, and other such nuisances - Aside from being used by threat actor groups, IoT devices are often exploited to participate in DDoS botnets, or exploited to mine cryptocurrencies (though, most embedded devices are not known for having access to large amounts of CPU and/or GPU power that crypto-mining typically requires). One of the most popular cases of an IoT botnet being used in a DDOS attack was the 2016 DDoS by the Mirai botnet, that targeted the Dyn network’s DNS service, resulting in wide-spread outages for a wide variety of internet services. Since then, the number of IoT botnets, and the exploits they utilize to build their networks has only exploded.

Recommendations for Securing IoT devices

So now that we’ve established that IoT devices are vulnerable by design, and being exploited by a variety of actors for a variety of different purposes, what can you do to keep your devices at home, and in the enterprise safe? Here are my thoughts:

1. If it uses boa or goahead webs as the web server/framework for the web interface, deeply reconsider the usage of such products or have very robust mitigations in place. Boa HTTPd has been unmaintained since 2005 and yet is still used in a significant variety of IoT devices, meanwhile GoAhead webs and goform are also frequently implicated in the large number of CVEs I’ve written detection coverage for. Sometimes the purchase of devices using these frameworks is unavoidable. If that’s the case, consider the other advice here to mitigate the risk they pose. Be aware that, even if you utilize devices that don’t use either framework, IoT devices in general still represent a significant risk that needs to be carefully monitored.

2. Monitor vendor websites for firmware updates, patches, and End-Of-Life Announcements. It’s never easy, and its never fun, but with many of these devices, firmware updates are not done automatically, making it necessary for customers to keep an eye on announcements from the vendor for new firmware releases or patches that are intended to mitigate major vulnerabilities. Additionally I am not a fan of planned obsolesce, but when a vendor decides that they will no longer support a given device, it becomes necessary to upgrade the existing device to something that is supported. This is never fun to deal with, but there are a significant number of IoT botnets consisting of devices that vendors have announced as EOL (End-of-Life). This is big problem because the vulnerabilities used by those botnets will never get patched. This type of vulnerability is also referred to as a “Forever Day” and represents a serious risk to network security. Again, some networks, especially regulated IoT/SCADA networks are often tied up with regulatory red tape that requires a significant amount of time and planning to upgrade obsolete devices. The best advice I can offer in these situations is strict access control, and robust monitoring of the affected devices – network segmentation, access management, exporting logs to a central location, IDS/IPS controls, etc.

3. Stop exposing embedded devices, especially web management interfaces over the public internet. This is single biggest reason why there are so many exploited IoT devices today. If you can, ensure that the management/admin interface for your IoT devices are NOT exposed to the public internet. If there’s no exposed surface area, there is no exploited IoT device.

   • In some cases however, these IoT devices can be exposed without the user or the organization knowing it – especially on home/residential ISP networks. Some services like SSDP (Simple Service Discovery Protocol), UPnP (Universal Plug and Play), as well other network auto-discovery and auto-configuration protocols are designed to make it easier for devices on a network to find one another, and enable connectivity. However, sometimes that connectivity can allow for automatic port forwarding for particular devices or other problems that can result in accidentally exposing devices to the internet that were never meant to be exposed in the first place.

   • My recommendations include avoiding the use of these autoconfiguration protocols on home networks if you have no need for them – especially on perimeter devices. If your router or IoT device has the ability to disable UPnP or other auto-discovery/configuration options, it is highly recommend to disable these features.

   • It is also highly recommended to monitor the network perimeter (public IP address space) for unintentionally exposed services – especially from IoT devices. Services like Censys and Shodan can be used to query your public IP address space quickly to determine if there are unintentionally exposed devices very effectively. Some CERTs and organizations (like Shadowserver Foundation, or Greynoise) will handle monitoring the network perimeter for you. Finally there are popular port scanning and vulnerability scanning tools (e.g. Nmap, Massscan, etc.) that can be used to scan your network perimeter for possible exposures.

A screen capture of the results from shodan.io for my residential IP address. I run a personal blog and a minecraft server, so ports 80, 443, and 25565 are exposed. If there were other services exposed, I would definitely want to know about it!

4. Consider implementing other security controls for accessing the IoT devices over the internet - Consider implementing a VPN or another form of secure remote access. Even something like key-based SSH meets that criteria!

   • Note: This is a wonderful guide for setting up key-based authentication for SSH, including how to disable password authentication entirely. I would also consider making use of setting the AuthenticationMethods directive in /etc/ssh/sshd_config to: AuthenicationMethods publickey, To further protect against password guessing/bruteforcing. To learn more about this directive, take a look at the manual pages. Also, if you consider using SSH for remote access, consider changing the default port the server is listening on. This will reduce a lot of scan and password guessing traffic from bots. Check the man pages for /etc/ssh/sshd_config for the Port and/or ListenAddress directive.
   • More highly recommended than SSH, consider setting up a VPN connection instead. OpenVPN and Wireguard are considered some of the more well known free and open-source solutions out there, and there are numerous tutorials for setting wireguard and openvpn. Many SOHO routers support openvpn or wireguard, or if not, setting up a port forward to an internal host for the VPN or SSH connection is possible.

5. Consider using more enterprise-quality offerings, or other alternatives - With regards to networking equipment, Considering steering away from retail or home market solutions like D-Link, TP-Link, Linksys, etc., and selecting slightly more high-grade solutions that have a bigger ecosystem – Mikrotik, Ubiquiti, GL.iNet, etc. While some of these vendors may also be subject to their own problems and vulnerabilities, many have well-supported device ecosystems, and utilize their own custom operating systems, such as Mikrotik’s RouterOS, or variations of OpenWRT that come pre-installed.

   • In addition to higher-end network gear, also consider alternatives such as pfSense or OPNSense. Both of these firewall/router operation systems are extremely robust and run on a wide variety of hardware offerings out there. In my home, I run pfSense on mini-PC. The biggest caveat I will mention with both pfSense and OPNsense is that their wireless connectivity and support for wireless cards are still very lacking, so an external wi-fi repeater may be necessary. Of course another caveat to be aware of with using either of these firewall operating systems is that, unless you purchase the vendor-provided hardware, or a support contract, users will be on their own regarding troubleshooting network or configuration problems. There are community forums to go to for help, however. Additionally, both solutions offer a high degree of freedom, power, and generally more secure design.

In my household, I bought a very generic 4-port miniPC, and installed pfSense on it. After discovering the hard way that support for Wi-Fi6 and beyond is very limited on the FreeBSD-based pfSense, I purchased a GL.iNet router, and configured it as a wireless bridge. A little bit complicated, but very robust. So far, its been in-service for two years with no problems to report.

Conclusions

I hope you’ve found this post helpful for securing your IoT devices and SOHO equipment. If you I missed any recommendations for securing IoT devices, or if you have any preferred vendors and/or solutions of your own, feel free to comment.

Until then,

Happy Hunting.

-Tony