IoT security is a key issue for organisations. In all sectors and areas of activity (healthcare, industry, services, transport, energy, etc.), the IoT brings development and growth.
There are currently an estimated 15 billion IoT objects in use worldwide. This number could double by 2030. However, this proliferation of connected objects brings with it new challenges, particularly in terms of security.
IoT Security: a Key Issue for Designers of Connected Objects
However, the opportunities offered by the IoT go hand in hand with increased exposure to cybersecurity risks.
Beyond the security risks associated with servers, web interfaces and mobile applications, IoT security also relies on the communication protocols used, the embedded software – firmware – and the hardware architecture. All these components of IoT systems enable functional requirements to be met.
However, the “appropriate” design of an IoT system must not be based solely on functional requirements. It must also take into account security considerations to guard against vulnerabilities that could compromise the entire IoT ecosystem.
To guarantee the security of IoT systems against attacks, specific security measures are required: secure configurations and implementations, hardening of systems, encryption of communications, use of secure protocols, secure management of rights and accesses, and so on.
IoT penetration tests are also a good way of detecting existing vulnerabilities in connected objects.
In this article, we focus on the main IoT attack vectors that could lead to the compromise of a connected object.
What are the Main IoT Attack Vectors?
Web interfaces
Web interfaces are preferred vectors for attackers. Indeed, connected objects generally have a standard web site enabling interaction with them.
This web interface is subject to the same security requirements as any other site: password protection, resistance to DoS attacks, regular component updates, and so on.
Although it may seem simplistic, a web interface is a server in its own right and should be treated as such. Furthermore, many connected objects communicate over the Internet with backend servers, often using HTTP or websockets. Securing this traffic in both ways is crucial to guaranteeing a secure environment.
WI-FI networks
When an object is connected to a Wi-Fi network, several security aspects need to be carefully checked:
- Is the connection secured with WPA2 encryption and a strong password?
- In the event of a Man in the Middle attack, can the attacker impersonate one of the servers with which the object communicates? Is certificate pinning used to verify server authenticity?
- If the object is updated via the Internet, can an attacker impersonate an “official” server and attempt to push a malicious update onto the connected object?
If the object itself serves as a Wi-Fi access point, the same security issues arise, but it must also be protected from IoT attacks internal to its network.
Bluetooth communications
Bluetooth is also very popular in the IoT, and for good reason! It facilitates connectivity with other devices and enables an efficient communication and instruction protocol. However, several criteria must be met to guarantee its security.
Pairing must be unique, and communications must be encrypted. The GATT (Generic Attribute Profile, the Bluetooth equivalent of an API) must be rigorously monitored. Arguments supplied by the client must be treated as potentially malicious, only necessary information must be communicated, and debug functions must be disabled.
Debug ports
When it comes to disabling debug functions, JTAG and UART ports are perfect examples. These physical entry points, often in the form of solder points, can transmit crucial information and enable object reconfiguration, memory dump, data modification and so on.
Although extremely useful during the development phase, these ports must be deactivated during the production. This deactivation is generally specific to the board model hosting them, and is often the responsibility of the component manufacturer.
Hardware
In addition to debug ports, which are obvious targets, hardware can be attacked more directly by various vectors. These include:
- Connecting directly to SPI interfaces to intercept or modify data in transit.
- Checking whether the data is correctly encrypted and whether the decryption key is securely implemented (e.g. via TPM or a similar system).
- Check whether memory and code can be read or copied.
- Check if the code is signed and if the chips can be flashed to install custom software.
- Test the possibility of connecting as a peripheral (such as a sensor) and injecting data to manipulate the object’s code.
Completely securing an object’s hardware is complex, especially in the face of an attacker with unlimited access, time and the resources to carry out a large-scale attack. The aim is to make the attack sufficiently complex and costly to dissuade the attacker from continuing.
Other forms of communication
In this article, we’ve only covered the main means of communication, but there are many others.
Whether at the network layer (such as Bluetooth, Wi-Fi, Zigbee, LoRa, LoRaWAN, Z-Wave, Thread, or even traditional cellular networks) or the application layer (such as HTTP, websockets, MQTT, AMQP, XMPP, DDS), each protocol has its own specific features, weaknesses, strengths and possible vectors for IoT attacks.
Each of these protocols must be analysed and secured individually to guarantee optimum protection.
Conclusion
This article is only a very general introduction to the subject. Others will follow to detail each of these attack vectors.
In the meantime, remember this: as mentioned above, a connected object should be considered in the same way as any other computer connected to your network. It is a collection of hardware and software components, each of which is a potential entry point for an attacker.
Seemingly harmless, a connected object can become a target of choice, often neglected from a security point of view, which can make it more vulnerable.
Author: Renaud CAYOL – Pentester @Vaadata