Bulletin on IoT security. Is your network ready for Internet of Things exploits?

Today's world is completely dependent on digital technologies, and in this context, the Internet of Things (IoT) is becoming increasingly important. However, like any other network connection, IoT devices can pose a threat to your network. This applies to a wide range of devices, including smartphones, iPods, smart intercoms, CCTV cameras, medical devices, smart watches, and much more.

Learn more about the threat

IoT devices tend to have a low degree of trust. This means that they often do not have modern means of protection and may be vulnerable to external attacks. In addition, due to the low cost of production, they can be cheap and, as a result, widely distributed. In the case of very cheap devices such as smart sockets and light bulbs, the buyer does not even have reason to trust the manufacturer and seller of such equipment.

Some IoT devices may even be infected with viruses or Trojans already at the stage of their production or sale. This can happen, for example, if counterfeit components, pirated firmware are used at some stages during the assembly of the device, or insufficiently strict control measures are applied. Not so long ago, the company Human Security revealed (en) an entire shadow network associated with infected devices and malicious applications. Infected were not only Android TV set-top boxes, but also tablet PCs, wearable devices and even cars.

Fragment of the encrypted config.make of the infected device

Also, some devices may be pre-created for use in attacks on other systems. For example, some Android players, which are sold at an affordable price, may be intended for implementation in botnet networks. They can be used to send spam, hack systems, or participate in other attacks.

A regular Firewall does not protect against IoT-related threats

Conventional Firewalls are designed to protect the network from threats coming from the Internet and to restrict access from different subnets. Roughly speaking, they prevent attackers from entering your network and stop attacks that have already been committed within the subnet. In the case of IoT, the potential danger is already in your network, it has the right to go online, but there is no control over its actions: there is no antivirus on these devices and it is quite difficult to control what exactly they are doing on the Network.

To implement typical attacks using IoT, an infected device initiates access to the attackers' management servers, and therefore protection against IoT threats includes two main stages: isolation of the entire fleet of these devices in separate closed subnets (so-called protection from horizontal traffic) and filtering access to Internet resources to exclude external management and malicious code downloads.

The good news is that almost all modern corporate network security gateways, including free software pfSense and OPNsense have everything you need to ensure IoT security. The bad news is that everything will have to be configured manually, and this is such a voluminous process that in this article we will only list methods of repelling and preventing attacks.

Separate VLAN

The first and most important step is to assign all IoT devices to a separate VLAN that does not have access to shared network resources. This can be implemented on access points or switches. VLAN provides an effective protection mechanism against wiretapping of network traffic and potential attacks on office computers and all network resources from the IoT side. VLAN allows you to create individual network zones for each type of device, providing simpler and more effective protection.

For example, you can create a subnet accessible only to IoT devices and set strict access restrictions for all these devices by their IP addresses. The next step may be to completely ban access to all segments of the local network for these devices, since they are controlled via the Internet and have no reason to interact with office computers or other network resources. This approach protects the organization from the introduction of sniffers and a potential attack on office computers and all network resources. If there are many homogeneous devices in your company, it makes sense to create different VLANs for different classes and manufacturers of IoT devices - this will facilitate the application of control rules in the future.

For each such VLAN, you need to create a separate interface on the Internet gateway, assigning it to a virtual network port if the gateway is running in a virtual machine or to a physical port if the gateway is a physical device. After that, you will have a whole set of tools at your disposal to control the outgoing traffic of the IoT subnet.

Protection against the introduction of malicious code into IoT devices

The peculiarity of IoT devices is that they initiate Internet access themselves, and no matter how we close access to them from the outside, this will not help in the case when the “smart socket” turns to a malicious source, downloads a virus from it and starts working as part of a botnet, harming your network and other people's resources. All the same is true for computers and laptops, but they usually have built-in protection tools: antiviruses, OS integrity control, trusted software, etc.

Restricting access to questionable Internet resources is an important measure to protect the company's network from exploits in IoT devices. However, there is one significant factor here that we cannot control - changes in the domain names that the device accesses. If all your smart sockets are issued by the same company and refer to the same domain of the form iot.philips.com over https, consider yourself lucky: close everything except this domain for the IoT subnet and don't worry about anything. If you have devices from different manufacturers accessing different servers, and even using different protocols, you will have to tinker. It is for this reason that I recommend distributing IoT devices across different VLANs and different subnets.

So, we believe that you have already allocated the IoT to a separate subnet or several subnets, closed or restricted their access to the shared local network, and now we need to prevent them from communicating with malicious servers.

The main protection of the company 's network from the introduction of exploits in IoT devices is divided into three stages:

• Restricting access to untrusted IP addresses: This stage consists in creating a list of untrusted IP addresses that are known as sources of attacks or potentially dangerous to the network. All IoT devices must be configured to block access to these addresses in order to prevent access attempts and attacks from these sources.
• Restriction to untrusted domains: At this stage, you need to create a list of untrusted domains that are also known as sources of attacks or potentially dangerous to the network. Similarly, all IoT devices must be configured to block access to these domain names.
• Prohibiting device attempts to circumvent the first two restrictions via VPN, PROXY or TOR: This stage consists in blocking attempts by IoT devices to use VPN, PROXY or TOR to circumvent the previous two restrictions.

It is important to note that we cannot restrict access only to trusted IP and domains, because outgoing requests from IoT devices may change with the update of their firmware or simply because the manufacturer intended it that way. Instead, we should restrict access to dubious domains and IP addresses that are commonly used for various kinds of attacks. This will allow us to protect our network from most known types of attacks and increase its security.

Blocking access by IP

Blocking access to questionable IP addresses is one of the simplest and most effective ways to protect a company's network from exploits in IoT devices. This approach is based on the use of "Aliases" (or lists) to identify sources that should not be communicated with. Lists of questionable IP addresses are usually made publicly available by enthusiasts and manufacturers of antivirus software and are regularly updated. The most famous free lists: CINS Army, Emerging Threats and Spamhaus. This allows you to track and block new threats and delete “corrected addresses". For an IoT subnet that needs limited Internet access, we don't need granular configuration and high accuracy – we can block spam addresses, known botnets, abuzo-resistant hosting, etc. Paid lists of questionable IP addresses are updated frequently and have a low false alarm threshold, so it is preferable for large enterprises to use commercial licenses.

To facilitate the work, do not create one huge alias of questionable addresses on the router: it is better to divide them into categories, and then block outgoing connections for the IoT subnet to these Aliases in the Firewall rules. It would not be superfluous to configure logging and notification of access from IoT subnets to such resources: so you can find out about the compromise of your IoT fleet and take action.

Why shouldn't GeoIP lock be used?

However, blocking by GeoIP (geographical localization of IP) is not an effective measure in this case. This is due to the fact that manufacturers of IoT devices can use the Content Delivery Network (CDN) with exit points in different geographical regions. This means that blocking by GeoIP can lead to blocking legitimate traffic, which is undesirable for IoT devices.

Domain Name blocking

In protecting the company's network from exploits in IoT devices, blocking access to questionable domains is a mandatory measure. The most reliable method is to deploy a separate DNS server on the network and transfer all DNS requests from IoT subnets to it, limiting any other DNS requests to the outside. Similarly, with the help of updated lists of malicious domains, we can force the DNS server to broadcast unwanted traffic to a secure IP address, for example, to 127.0.0.1 or to a specially configured web server with a stub page. If you try to access a malicious website, the smart TV will get a blank page. Check out the comparison of domain blacklists in Wikipedia (en) before selecting a list for your gateway.

There is simply no effective method of filtering DNS Over HTTPs requests originating on port 443 in the context of IoT devices. Therefore, it would not be superfluous to block DOH providers along with suspicious IP addresses, including Cloudflare public servers, such as 1.1.1.1. We do not consider the issue of MITM attacks on IoT devices with certificate substitution, since such devices do not allow changing the certificate normally. By the way, this would be a very reliable method of protection, and if some device is friendly to MITM, be sure to configure a caching proxy + ClamAV.

If it is difficult to place a DNS server on the interface for IoT, this task can be solved by a transparent proxy filtering unencrypted SNI indicators that the IoT device sends in the headers of HTTPs requests. This method is less reliable, because if the client uses encrypted ESNI (TLS 1.3), then the proxy server will either skip all such requests, that is, it will not filter traffic, or it will block them all, that is, it will not allow the IoT device to work normally.

Blocking spammed tlds - we say YES!

It is important to note that when filtering domain names, broader methods are available to us in identifying questionable domain zones, including blocking entire spammed domain zones, such as .website, .fit and .golf, as well as the national domains of third world countries that are the source of spam. We can hope that a self-respecting manufacturer will definitely choose a domain in the zone.com or in the national market area of presence, such as .de, .ru or uk.

Lock bypass blocking

In general, it would be ideal for an IoT subnet to block any outgoing connections to any ports except 443 and 80, but in some cases smart devices can “knock” on other ports, including “high" ones. A typical example of this behavior is a game console connecting to game servers at different IP addresses and with different ports. We cannot limit this behavior of the device, and in this case it makes sense to at least close to it something that can definitely pose a threat: VPN and TOR gateways. First of all, we add all known VPN ports to a separate list and block outgoing traffic from the IoT network to it.

Typical VPN ports:

• 500 - IPsec
• 4500 - IPsec
• 1701 - L2TP
• 1723 - PPTP
• 51820 - WireGuard
• 992 - SoftEther (rare thing)
• 1194 is the default port for OpenVPN

We do the same with TOR gateways as with IP addresses: we make aliases from public lists and block outgoing requests to these addresses. A free updated list of TOR nodes is available on Github.

VPN servers that can work on arbitrary ports, such as OpenVPN, will have to tinker. Here you will have to implement a DPI system that uses application-level filtering (such as Open api). On many corporate security gateways, this feature is active by subscription, but it is quite problematic to implement it on free software.

It's also not difficult to figure out the tricky services masquerading as HTTPs and running on port 443. In order to block non-HTTPs requests on port 443, we use a transparent Squid proxy on the IoT interface with the SSL Bump Peek and Splice function enabled. The Peek and Splice function looks at the TLS client's welcome message and SNI information (if any), sends an identical or similar (as far as possible) Client Hello message to the server, and then looks at the TLS server's welcome message. The final decision on connecting, overloading or disconnecting the connection can be made depending on the server settings, that is, with proper configuration, we will not have to decrypt traffic from IoT devices, but at the same time the proxy will not miss VPN and tunnels that knock on port 443.

What can't we protect?

There is a situation in which your IoT device accesses its servers on arbitrary ports to exchange service traffic in encrypted form. If an attacker installs a tunnel encryption tool, such as Stunnel, on it, he will be able to connect via VPN to a malicious site and download unwanted code. There is no effective method of protection against such an attack, so if you find such devices in your equipment park, it is better to abandon them.

There is also the simplest attack option – hacking the hardware manufacturer's servers or uploading malicious code there. In this case, there is a possibility that the domain and IP address of the server will be blacklisted by cybersecurity companies, and access to such resources will be automatically blocked on our Firewall. But in the worst-case scenario, even if an infection has occurred, potentially dangerous IoT devices in your company will be so limited in functionality that they will not be able to harm your infrastructure or anyone else.

Michael Degtjarev (aka LIKE OFF)
10/10.2023