Have we forgotten what the ancients taught us in building defense systems?
October 06, 2017
I find the multilayered defense system built into many ancient forts fascinating. Fort D?n Aonghasa in Ireland is a great example of how a multilayered defense system was used.
I find the multilayered defense system built into many ancient forts fascinating. Fort Dún Aonghasa in Ireland (pictured below) is a great example of how a multilayered defense system was used to increase security by making it very difficult for an attacker to gain access to the "inner circle". The attacker would have to overcome several barriers, including first having to climb up a cliff, then penetrate huge boulders while being shot at with arrows, and then climb over three walls.
Just as many of the old forts like Fort Dún Aonghasa used a multilayered defense system, so can a modern IoT solution. However, the reality is that many modern IoT solutions completely lack any type of defense system against hacking.
The lack of defense systems or the limited set of defenses found in many modern IoT devices and solutions, in many cases, stems from engineers and designers lacking awareness of the vulnerabilities that may exist in certain IoT protocols. We will explore some of the typical weaknesses found in IoT devices/solutions and how IoT devices and the IoT infrastructure can be designed to be more resilient by deploying a multilayered defense system.
Hacked and enslaved IoT (server) devices operating in a botnet
Some time ago we received the following email from our hosting provider:
Event Summary: A software anomaly was corrected that caused excessive outbound routing announcements to be withdrawn in response to a Denial of Service attack.
Distributed Denial of Service (DDoS) attacks are on the rise, and the origin of these attacks are increasingly coming from hacked Internet of Things (IoT) devices. KrebsOnSecurity.com was recently hit with a record DDoS attack, and analysis of the attack traffic suggested that the assault was around 620 Gbps of traffic. The attack originated from a botnet of thousands of hacked and enslaved IoT devices such as IP cameras and DVRs from all over the world.
These hacked IoT devices have one thing in common: they all operate as servers by providing services such as web-server, telnet server, and/or SSH server. Unfortunately, publicly accessible servers can easily be found by port scanners such as Shodan. A hacker can create automated tools that scan and probe for weaknesses such as easy to guess passwords, default product passwords or simply performing brute force password attacks. Hackers then upload code to the compromised devices, thus enslaving them by integrating these devices into their botnet. For this reason, IoT devices that include services are much more vulnerable than IoT devices that provide no form of publicly available service.
First line of defense: IoT devices should operate as clients, not servers
Devices operating as network clients, as opposed to operating as network servers, cannot be found by port scanners. In addition, when devices operate as clients, it is impossible for an outsider to directly connect to the devices. However, devices that operate as clients need an online server that enables the users to control their devices via the online service.
When all devices and human machine interfaces operate as clients, an online server is required for proxying the traffic between the users and the devices. The online server operates as a service/server to the human machine interfaces (HMI) and to the connected devices. For example, a home owner with a cloud enabled thermostat can control the thermostat via a web interface provided by the online server.
Although a proxy server can be designed by, for example, using the WebSocket protocol and by designing server side code for routing (proxying) the messages between users and their devices, an easier solution may be to use one of the many IoT protocols designed for this purpose. Publish/subscribe (pub/sub) protocols, such as AMQP, XMPP, and MQTT, are popular choices.
An online proxy server is typically referred to as a broker when using pub/sub protocols. The broker is in charge of routing messages between publishers and subscribers.
IoT pub/sub protocols and the hidden pinholes
Pub/sub protocols are great choices for controlling devices indirectly via an online server. Pub/sub protocols make it possible for any connected client to subscribe to topics. Some IoT protocols, such as MQTT, also enable what is known as wildcard subscriptions. A wildcard subscription lets a client subscribe to topics without knowing the exact topic name, thus a potential pinhole. It is in fact possible to subscribe to any topic in MQTT making the protocol inherently insecure since an attacker that has gained access to a broker can eavesdrop on all messages sent from other devices. The attacker can then learn the details of all messages used by the IoT solution and use this information to indirectly compromise all connected devices by publishing specially crafted messages.
A DEFCON MQTT paper was recently released by a white hat hacker. The paper reveals how one can find and access MQTT brokers on the Internet and perform actions such as open prison doors, change radiation levels, and so on. The online brokers that the hacker refers to are not requiring the MQTT clients to authenticate. The hacker then goes on to create a script that subscribes to all messages handled by the brokers by using wildcard subscriptions.
Needless to say, a protocol such as MQTT cannot be used without client authentication. However, since MQTT sends passwords from the client to the broker in clear text, the communication must also be protected by TLS to protect from eavesdropping. Note that using client authentication may not be as secure as you may think. We will explore the authentication security issues in the next two sections.
Second line of defense: Authentication
IoT devices operating as clients should use the TLS protocol for authenticating the server at connection time. When the client connects, the online server's X.509 Certificate provides assurance that the device is in fact connecting to the correct server and not to a spoofed system.
As mentioned previously, pub/sub protocols such as MQTT should not be used without client authentication since this would compromise the IoT solution. Client side authentication in combination with server side authentication is known as mutual authentication. Server authentication is normally provided by the TLS protocol and the server's certificate. However, a client can authenticate itself by using anything from a plain text password to anX.509 Certificate.
All forms of authentication mechanisms are based on keeping a secret. Keeping secrets in IoT devices such as headless edge nodes (a device that lacks a graphical user interface) is problematic for these devices are usually out in the wild, thus enabling a hacker to potentially extract the hardcoded credentials from the device. For example, a cloud enabled thermostat that is designed to connect to an online cloud server can be purchased by a hacker, who may then extract the credentials (password or X.509 Certificate) from the device, thereby gaining access to the thermostat's online ecosystem. This is particularly concerning for IoT solutions based on pub/sub protocols that enable wildcard subscriptions.
Authentication shortcomings
When using a pub/sub protocol such as MQTT, a hacker that manages to extract the credentials (password or X.509 certificate/private key pair) from a device can use the credentials for either eavesdropping on the IoT solution's communication or performing a direct exploit by publishing specially crafted messages.
Unique credentials per device makes it possible to disable the exploited device including use of the device's credentials; however, this requires that the IoT solution can detect the exploit and remove the exploited credentials from the solution. A solution that uses X.509 certificate/private key pair for client authentication is even more complicated since compromised X.509 certificates must be managed by using a certificate revocation list (CRL).
The complexity in extracting the credentials from a device greatly depends on the device type and the components used in the device. A device based on a high-level operating system where the credentials are stored on a file system in an external flash memory module makes it much easier for a hacker to extract than the credentials for a device using internal microcontroller flash memory and where the JTAG fuse is blown. Having said that, even the most hardened device can be exploited and the credentials can be extracted. For this reason, designing an IoT solution that only relies on using credentials as the one and only defense mechanism is going to be much more vulnerable than an IoT solution based on a multi layered defense protection system.
Third line of defense: Authorization
Authorization protects the IoT solution against compromised devices when the credentials have been extracted and used by a hacker and for IoT solutions designed to be used without password protection. Authorization can also be used to detect abnormalities in the communication pattern and report such incidents to an operator.
Authorization is particularly important for protocols, such as pub/sub, that provide the one to many message model. Authorization is even more important for pub/sub protocols that enable wildcard subscriptions.
Authorization is product specific and can come in many flavors such as providing a method for controlling an Access Control List (ACL). IoT solutions based on pub/sub protocols that enable programmatic authorization on the server side, by for example providing a plugin system where you can use your own computer code for analyzing the traffic, can be made more secure than a broker solution that only enables authorization via configuration files.
In an upcoming article, I will provide an example of how one can use programmatic authorization as an extra line of defense.
Summary
The ancients taught us that a multilayered defense system improves overall security. If one defense fails, another takes over. We should take this as a history lesson and apply it to modern day IoT and network design.
First, devices should operate in stealth mode, making them invisible for automated hacker bots searching for devices. A device operating as a network client has stealth mode property. As an added security feature, an IoT solution that also operates the online server in stealth mode is more secure because an attacker would have a hard time finding the online service. The WebSocket protocol has this property for it is difficult to differentiate a WebSocket server from a regular web server, especially if the entry URL for the WebSocket server is nonpublic since a nonpublic URL cannot be found by an automated port scanner. Protocols that only provide one type of service and that listen on a specific port number do not have stealth mode property.
Second, IoT servers should use X.509 certificate authentication to prevent man in the middle attacks. In addition, some IoT protocols should not be used without client side authentication since they include features such as wildcard subscriptions that may jeopardize the security of the entire solution.
As a third line of defense, the server/broker should include authorization to protect the IoT solution. Servers that enable custom and programmatic analysis of the messages include additional security that makes it possible to provide fine grained authorization and detection of non-conforming messages.
To enable developers to easily design multilayered defense systems, we developed SMQ, a light weight IoT pub/sub protocol like MQTT. In addition, the SMQ protocol behaves similarly to WebSockets, with the initial HTTP and HTTPS connection upgraded to a persistent SMQ connection, making the broker difficult to detect, essentially operating in stealth mode. The SMQ clients can use salted password hashing, making it possible to securely authenticate clients using a non-secure (non TLS) connection. Secure connections are initiated over HTTPS, enabling clients to connect out to the Internet and bypass any firewall/proxy. For security reasons, the protocol does not allow wildcard subscriptions, thus an attacker that has gained access to the broker cannot easily subscribe to and detect the message flow. The SMQ broker includes a plugin system that enables the developers to programmatically analyze all traffic managed by the broker (authorization). The secure SMQ client, called SharkMQ, is suitable even for the tiniest microcontroller. Our tests indicate that the complete protocol overhead, including TLS, TCP/IP stack, and drivers, can be as small as 38Kb ROM and 13Kb RAM.
Whatever protocol you choose, a good understanding of the protocol will help you design a better defense system for your IoT ecosystem. Many protocols include a wealth of features, however, these features, used or not, may lead to pinholes that can be used by attackers attempting to compromise your solution. A recommendation is to choose a protocol with the right set of features designed with security in mind rather than a protocol supporting everything that is more attack-prone
