Sternum has set out to debunk the myth that crypto is the be-all and end-all of IoT security, through a two-part blog series. In Part 1, we explained the difference between crypto and security, claimed that while encryption is difficult to penetrate – it is much easier to bypass, and as a result – having crypto is not nearly enough to secure a connected device.
Now, in the second part of our series, we’ll go deeper into real-world examples, explain how parsing vulnerabilities work and reveal the surprising origin of vulnerabilities in the OTA (over-the-air) update process. Let’s dive in:
From Theory to Real-World Examples
We’ve seen this in the wild: the logic that runs prior to the decryption is solid – boundaries are checked, threads use locks for synchronization, etc. However, when decryption succeeds – it’s as if the device “sighs” in relaxation, and forgets basic security measures against memory manipulation. But in the real world, even this scenario is a bit optimistic. In many cases, attackers didn’t even have to reach the encryption mechanism in order to exploit the device, and their job becomes a lot easier.
The Ultimate Example: WannaCry
WannaCry was a cyber attack that targeted vulnerable Windows systems and infected them with the WannaCry cryptoworm – a ransomware that encrypted data and demanded ransom. The ransomware attack was estimated to have affected more than 200,000 computers across 150 countries, with total damages ranging from hundreds of millions to billions of dollars. It propagated through EternalBlue, an exploit in older Windows systems.
The EternalBlue exploit took advantage of poorly handled user input in the SMB protocol, exposing the system to several buffer overflow vulnerabilities. Errors that led to the vulnerabilities were in fact within the logic which dealt with unauthenticated requests. There was no need to provide any secret keys or credentials to trigger these vulnerabilities and take control of the system. When they were exploited, the entire world was caught off guard.
And in IoT, We’ve Got BlueBorne
While WannaCry relates to Windows systems, BlueBorne is a set of vulnerabilities more relevant to the IoT world since they exist in the Bluetooth stack, commonly used by IoT devices. These vulnerabilities exposed more than 8 billion devices to cyber attacks.
The BlueBorne attack vector did not require the targeted device to be paired to the attacker’s device or even to be set on discoverable mode. The Armis research lab that exposed them revealed that those vulnerabilities were fully operational and could be successfully exploited.
These vulnerabilities put even more emphasis on the fact that encryption and authentication aren’t enough to secure an end-point device. While a device could be designed with the best security measures in mind, advanced encryption, and PKI for authentication, it could still be exposed to attacks exploiting a simple vulnerability in the Bluetooth stack.
Explaining “Parsing” Vulnerabilities
These so-called “parsing” vulnerabilities are extremely common in the IoT world in particular, though can often be found in mobile devices and PCs as well. Many of these vulnerabilities can be found in the communication stack since communication protocols are usually sophisticated and require complicated logic for the successful interpretation of data.
A lot of the parsing logic executes before any authentication or encryption takes place.
Here is a simplified example of a vulnerable mechanism. Assuming the protocol states that a chunk of data must be preceded by its length:
char* get_data_from_packet(char* packet)
{
// Allocate memory to hold the data
char* data = malloc(MAX_PACKET_DATA);
// Get the data length from the first 4 bytes
int data_len = get_data_length(packet);
// Copy characters from the packet.
// The data starts after the length we acquired, which is 4 characters
memcpy(data, packet + 4, data_len);
return data;
}
The code allocates memory to hold the data, let’s say MAX_PACKET_DATA=4096, so 4096 bytes, and copies the whole data into the allocated memory using the memcpy function. The memcpy function copies <data_len> characters.
Can you spot the error? The program allocates a constant amount of characters (4096) but the actual number of characters copied into it is controlled by the sender of the packet. An attacker could send a malicious packet, specifying 6000 in the data length field and making the memcpy function overwrite 6000 – 4096 = 1004 bytes of the program memory outside of the allocated buffer. This vulnerability is a heap buffer overflow.
This particular example is fairly common in communication protocol implementations – a lot of packets contain the length of the data that follows. If such a vulnerability exists in the device’s communication stack, the device would be vulnerable to heap buffer overflows regardless of any encryption or authentication that could have been implemented. This might occur since the encryption stage typically happens after the communication stack had finished parsing the packets.
The Surprising Origin of OTA Update Vulnerabilities
Over-the-Air update mechanisms allow updating the software of an end-point device without a physical connection to it. OTA updates are typically used to improve functionality, fix bugs and patch vulnerabilities on the device. Most IoT devices implement some sort of OTA firmware update to be able to push changes to the devices remotely.
While the update mechanism itself is important, it doesn’t necessarily increase the security of the device. In order to fix a vulnerable device, the flaw must first be identified and fixed. Unfortunately, that typically happens after some devices have already been exploited – that’s how most vulnerabilities are found. OTA updates can’t help against 0-day exploits.
By itself, the OTA update mechanism is one of the first places an attacker would look at to find flaws. It has the potential to grant an attacker with the “Holy Grail” of exploitation – the ability to flash a custom, malicious firmware onto the device. Therefore, the OTA update is an extremely delicate procedure that must be designed and implemented with the highest security measures in mind, and without a doubt – encrypted and authenticated.
Even so, most vulnerabilities in OTA update mechanisms are not directly related to encryption. Actual problems with the signing and verification procedures are, in fact, rare. In most cases, an attacker wouldn’t try to break the encryption system and gain the ability to successfully sign custom firmware. Their origin is of a more simple nature: like any other vulnerability out there, including in communication protocols implementations, update mechanisms deal with data parsing. Whether it’s for extracting and validating the key, the signature or for determining the boundaries of the signed data.
Numerous IoT vulnerabilities can demonstrate this:
- OTA update vulnerability in Yi home camera;
- Intenson hub buffer overflow during firmware update procedure;
- Circle with Disney signature check bypass vulnerability.
These examples are just the tip of the iceberg and encryption and somewhat secure OTA procedures were applied in all of them.
A lot of update mechanisms rely on external libraries, for example, for dealing with PKI. These libraries tend to be common and widely used and as such, they draw a lot of attention from hackers around the globe are attempting to find flaws in them and attack multiple devices with the same exploit. Some of these libraries are old and un-maintained, making it difficult to patch a known vulnerability even after it has been already exploited in the wild.
Conclusion
We hope that by now you’ve been convinced: crypto is not enough for security.
Crypto is an important mechanism and should be used to secure communication between the device and the outside world. This technique makes it extremely difficult for an external attacker to hijack data coming in and out of the device. As Amazon CTO, Werner Vogels, said during the last AWS summit: “Dance like nobody’s watching. Encrypt like everyone is”.
OTA updates are important too, they allow remote modification and improvement of the functionality of the device. At Sternum, we recommend designing the OTA update mechanisms with the best security measures in mind. This includes signing and verification procedures of course, but also must include an implementation of security on the code of the update mechanism itself, as it is just as delicate and critical as the firmware verification.
Nonetheless, our strongest recommendation is to secure the device from possible vulnerabilities and their exploitation, especially communication protocols and other data parsing units, since even with the most sophisticated encryption, a simple bypass vulnerability could bring the whole network to its knees. To keep it from happening, you’ll need endpoint security on your IoT device.
