There seems to be no end to the number of well-publicized security challenges in the Internet of Things – and no market segment has been spared. 

Automotive security has been in the headlines recently, but lighting systems, white goods, home automation devices, medical equipment, airplanes, and industrial automation systems have all had their unfortunate turn in the vulnerability spotlight. 

Because high profile cyber-attack headlines are now a weekly occurrence, companies, whether OEM or end-user, are finally getting serious about IoT security.

Building a secure IoT device should be no different than meeting any other system requirement. Device security requires a solution targeted for the types of threats the device will be exposed to and, more importantly, designed to run on specialized, low cost hardware usually found powering IoT devices.

By design, IoT devices are highly connected and therefore provide broad attack surfaces for hackers to exploit. Securing these devices requires a comprehensive security framework providing enterprise level security for small footprint devices.

Examples of Application layer attacks

Security researcher Craig Heffner discovered a backdoor within the firmware common in a number of D-Link routers. The HTTP server in these routers included a backdoor bypassing the standard authentication process. 

The web server examined the browser user agent, and if it matched “xmlset_roodkcableoj28840ybtide”, required authentication checks were skipped. The string, read backwards, “edited by 04882 joel backdoor” showed the backdoor was intentionally planted. The backdoor provided access to the device’s configuration capabilities.

Beginning in January 2000, Vitek Boden waged a three-month war against the SCADA (Supervisory Control and Data Acquisition) system of the Australian Maroochy Water Services, which resulted in millions of gallons of sewage spilled into waterways, hotel grounds, and canals around the Sunshine Coast suburb. 

It is an interesting case study because not only did the perpetrator cause pumps to stop, he was also prevented alarms from reporting the failure. This example also shows the danger of insider attacks, as Boden was a former contractor of Maroochy Water Services.  Securing the perimeter, a favorite IT defense, would’ve been useless.

System layer attacks

While application layer attacks are prominent in embedded devices, attacks against system layer services are also increasingly common. The Industrial Control Systems Cyber Emergency Response Team (ICS-CERT) issued an advisory regarding Wind River VxWorks TCP Predictability Vulnerability for Industrial Control Systems. 

Researches also discovered a remote code execution (RCE) vulnerability in VxWorks. These are both network based vulnerabilities. A common mistake among real-time system designers is the assumption of “security through obscurity”. The VxWorks vulnerability shows assumption is no longer true, if it ever was.

The now well-publicized Chrysler Jeep Hack is another system level attack against an embedded device – this one involving reprogramming the firmware on a vehicle ECU to enable control of the vehicle over the network.

The Heartbleed bug is a vulnerability in the OpenSSL cryptographic libraries widely used in embedded devices.  Mark Schloesser, a researcher at security firm Rapid7, says it’s not clear if similar problems are widespread, but believes it’s safe to assume “quite a few embedded devices use vulnerable library versions”.

Given the typically long upgrade cycles for firmware in deployed embedded devices, it is likely many vulnerable devices still exist in the field, even though a patch has been available since April 2015.

Hackers will probe, and if possible exploit, any interface available on a device. Embedded devices are just as likely to be susceptible to common vulnerabilities resulting from buffer overflows and similar bugs as their enterprise counterparts. 

However, embedded devices differ from the enterprise in that they are not typically located within the physically secure confines of a data center. 

As such, they are much more likely to be subject to physical attacks using USB ports, serial ports or even physically intrusive attacks where hackers attempt to read data directly from flash memory or even from communication buses during operation of the device.

Security features – a framework for device security

The first step towards IoT security is ensuring appropriate security is built into the device itself. With the diverse nature and deployment of IoT devices, and the realization security perimeters will be penetrated, it is no longer sufficient to assume the device will be deployed only within a secure network.

No single security solution is appropriate for embedded devices. Choosing the appropriate security strategy must take into consideration the cost of a security failure (economic, environmental, social, etc.), the likelihood of attack, available attack vectors, and the cost of implementing a security solution. The likelihood of attack is higher than you might think.   

Features needing consideration are:

• Secure boot & secure firmware updates
• Secure communication
• Data-at-rest protection
• Embedded firewall & intrusion detection
• Key and certificate management
• Authentication
• Integration with security management systems
  • Security policy management
  • Security event reporting

Secure Communication

When most engineers consider security, they typically think of secure communication protocols such as SSL/TLS, SSH, and IPSec. While these protocols are a critical element of security they do not provide complete security.  They only protect against protocol specific attacks, but a secure device requires protection of all attack surfaces.

Security protocols provide protection against packet sniffing, man-in-the-middle attacks, replay attacks and, if strong authentication is used, unauthorized attempts to communicate with the device.  Use of these protocols is common in IoT devices and is an absolute component of secure devices.  

Small IoT edge devices are adopting wireless protocols such as ZigBee, Bluetooth Low Energy (BLE) and other wireless and mesh networking protocols. While these protocols have some built-in security, it is relatively weak and exploits are recognized.  These devices typically run on very low cost, lower power processors not supporting the security protocols common in TCP/IP networks. 

Two options to increase security in these types of devices are DTLS, (TLS over UDP) or implementing application level security.  Application level channel encryption, the use of session tokens, and the use of packet sequence numbers provide important additional security measures to protect against common attacks.   Updates to these protocols, such as the BLE 4.2 privacy features, significantly improve the security of the underlying protocol.  If these features are not yet supported in the intended protocol, the application layer security features can still be used.  Even if the protocol features are supported, the application security features still provide additional security and can be part of a defense-in-depth strategy.

Secure Boot and Secure Firmware Updates

Secure boot and secure firmware update capabilities are used to ensure an IoT device is running authorized code from the device manufacturer.  Properly implemented, this eliminates an entire class of vulnerabilities. 

Secure boot begins with a first stage bootloader programmed into a protected or non-writable storage location on the device. The first stage bootloader calculates the hash value of the second stage bootloader and verifies the hash is correct by comparing it to a stored, signed hash value for the bootloader or, depending on the system architecture, for the OS itself. 

The second stage bootloader, which can be more complex and may be stored in reprogrammable flash memory, repeats this process verifying the operating system and applications are valid.  If a monolithic RTOS is used, this is performed in a single step. In a Linux device with separately loadable applications, the process can be repeated to validate each application in the system before loading.  Once each layer is validated, it is trusted and can proceed to validate the next high layer in the chain.

Secure boot relies on signed code images to enable validation of the image during the boot process.  The images are signed by the device OEM using their private key.  The OEM’s corresponding public key must be programmed into the device during manufacturing or provisioning so the device can validate the signature for the firmware image using this key. 

Secure firmware update, like secure boot, validates new code images were signed by the OEM during the upgrade process.  If downloaded images fail the validation process, they are discarded and the upgrade is not performed.  Only images passing validation are accepted and saved to the device.  The new images are written to flash, replacing the previous image.   The Heartbleed vulnerability described earlier, provides a compelling case study for secure remote firmware update.  Without remote update capabilities, there is no way to update the devices without sending a technician onsite, returning the device to the manufacturer, or requesting customers to upgrade the firmware on the device.

Data at Rest (DAR) Protection

IoT devices, unlike enterprise servers, are not locked away deep in a data center. Many are located in the field with risk of theft or physical attack.  Any sensitive data stored on these devices should be encrypted to protect it from physical attacks or data thieves attempting to read data from the device.

Data at Rest (DAR) protection is the encryption of sensitive data on the device. Most IoT devices don’t have the computing power to support full disk encryption, but sensitive data should be protected. The specifics will vary, but data like credit card numbers or patient information should always be encrypted.  Care must be taken to store the encryption key in protected memory on the device or in a secure location like a USB drive or network server.

The DAR solution should ensure unencrypted data is never stored on the hard drive.  Protected data should be encrypted before it is written to a file. Encrypted files should be encrypted in memory and remain in RAM, never written back to the file system without being encrypted.  This ensures data cannot be leaked due to a power failure.

Intrusion Detection

Most embedded devices lack basic security features, making them tempting targets for hackers.  As a result, hackers have specifically targeted embedded devices, exploiting these weaknesses.  

Most cyber-attacks develop over time, beginning with hackers probing a network finding and exploiting a vulnerability, then leveraging the exploited device to move deeper into network.  The cycle then repeats from this new beachhead.  Stopping the attack before it start begins with detecting the attack is happening.  Intrusion Detection Systems and Intrusion Detection Software (IDS) are commonplace in enterprise networks and PCs. IDS, as the name implies, detects when a system is under attack or being probed.  These solutions can take many forms and detect many different types of attacks, but regardless of form, are in the main, largely absent for embedded devices.

Adding IDS capabilities to embedded devices is critical to provide early warning of a cyber-attack. The ability to detect and report potentially malicious activity enables system administrators to block attacks, quarantine compromised systems, and protect their networks. If embedded devices can support basic IDS they will no longer be such easy targets for hackers.

Summary

Securing IoT devices against today’s cyber threats as well as emerging future threats during the lifetime of the device is a critical challenge for embedded developers.  Low-end IoT devices require a custom solution, designed to meet the memory and performance requirements of these resource constrained environments.  Windows and Linux based solutions are too big, power hungry and slow to support low-end IoT devices.  A security framework such as Icon Labs’ Floodgate Security Framework, integrated with the MCU, provides IoT developers with the tools needed to secure their devices.

                                                          ———–

David West is the Director of Professional Services at Icon Labs, a leading provider of security solutions for embedded devices.  You can reach him at [email protected]

---

Filed Under: M2M (machine to machine)

 

---