Published on 11/14/2016 | Strategy
I find the multilayered defense system built into many ancient forts fascinating. The above image from Fort Dún Aonghasa in Ireland 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.
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.
All of 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.
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 homeowner 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.
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.
It should be needless to say that 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.
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.
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 particular 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.
The original article can be found here.
