Botnets bring battles in IoT: revisiting embedded security

The rise of botnets targeting the Internet of Things (IoT) has emerged as a clear and present danger for rapidly growing new industries such as home automation, smart cities, and industrial networking. While botnets unleashing distributed denial-of-service (DDoS) attacks have been known for quite some time, botnets specific to the IoT aren’t necessarily new either.

However, what is new about IoT botnets is the realisation of how devastating they can be, and the fact that inadequate security can blow up the IoT party at a time when embedded systems are being hooked up to the Internet in droves. This article explores botnets in terms of IoT device security vulnerabilities, as well as identifies key ways to secure devices against them.

Botnets and their potential exploits

A botnet is a collection of connected devices that have been infected with malware allowing an attacker to gain remote control and coordinate actions like launching a DDoS attack. Botnets, also known as zombie armies, can also be used to send spam emails, sniff out sensitive passwords, and spread ransomware.

The IoT botnets differ from their Windows-based counterparts in that they’re built from compromised IoT devices, and they can spread to a huge number of devices using the vast IoT network. Moreover, unlike common botnets, which are mostly used to spam, IoT botnets can cause far greater damage by impacting the physical environment around IoT devices.

For instance, an IoT botnet attack on traffic lights can create chaos across an entire town and ravage smart city infrastructure. Likewise, hackers can increase the heat levels in smart homes and artificially boost the demand for oil or gas.

Another stark difference is that unlike personal computers and servers, which are protected by safety features such as malware detection and firewall filtering, IoT devices are becoming attractive targets for botnets because they generally don’t use such advanced security features.

The rise of IoT botnets was predicted to become a threatening cybersecurity trend in 2016, but the IT security community dismissed the threats posed by these IoT botnets. At that time, the threat was generally perceived as being fairly limited, though before long, toolkits became available that enabled botnets to take advantage of vulnerabilities in unsecured IoT devices. The Mirai attack in October 2016 was a key turning point.

Mirai — and another IoT botnet called Bashlight — exploited the vulnerability in a pared-down version of the Linux operating system used in embedded devices like IP cameras and digital video recorders (DVRs). By doing so, these IoT botnets took advantage of a known vulnerability in devices such as webcams and then downloaded malware from a command-and-control (C&C) server.

Next, they began spreading this malware to other vulnerable devices by continuously scanning the default or hard-coded usernames and passwords. That’s how they launched DDoS attacks by infecting a vast number of connected devices. More than 150,000 IP cameras were used by the Mirai bot malware.

Botnets highlight flaws in embedded system design

Mirai delivered the wake-up call on the dangers of unsecured networked devices at time when Internet-connected devices is at an all-time high and still growing. Mirai also showed how hackers could take control of any vulnerable IoT device and enslave it into a botnet. Mirai and other IoT botnets raised the profile of embedded security and highlighted the key flaws in embedded systems design:

• The quest for simplistic IoT designs and the choice of low-cost components inevitably makes embedded security an afterthought.
• IoT devices have just enough processing power and memory space for the bare minimum functionality, thus pushing security considerations to the back seat.
• Strict deadlines and time-to-market pressures sometimes lead IoT developers to bypass security design components altogether.
• Many IoT designs are based on the reuse of software and hardware components to simplify design and lower cost. However, it also exposes default credentials in entirely different classes of IoT devices.
• Detecting infection of embedded devices is inherently difficult because they lack OS transparency and easy access; rather than accessing the OS itself, monitoring and detection are done through cumbersome access points like web browsers or smartphone apps.
• The majority of embedded systems run on some variant of Linux, which is not secure unless it’s properly patched, configured, and hardened. Hackers have mostly been exploiting Linux loopholes in routers and set-top boxes.
   

IoT botnets have already impacted IP cameras, Wi-Fi routers, webcams, and set-top boxes, and they have been used to launch DDoS attacks against online gaming services. Hackers have also unsuccessfully attempted to use Deutsche Telekom’s routers as devices for a botnet.

What’s next? Smart fridges, light bulbs, door locks, and connected cars? These botnets and their creators could cause devastation on a much larger scale when unleashed on banks, hospitals, and smart city infrastructure.

Robust, multilayer security protection is key

So how do we build robust levels of security in connected products against this wildcard? How do we implement security at multiple levels — from sensors to IoT nodes all the way to the cloud — in order to secure multiple entry points in the IoT network? Cornerstones of secure embedded systems include:

• Developing multilayer security protection in embedded system design, including securing nodes, storage, the network, and the ecosystem as a whole.
• Designing secure embedded hardware.

Implementing multilayer security protection

As Figure 1 shows, developing multilayer security protection in embedded system design includes securing nodes, storage, the network, and the ecosystem as a whole.

Figure 1: Threats such as IoT botnets demand multi-layer security for network-centric embedded systems. (Source: Microchip). For a clearer image click here.

These best practices for protection against IoT botnets are intrinsically tied to a security framework embedded into the product development lifecycle:

Node:

• Use a secure boot process with a hardware-based ‘root-of-trust’ to ensure that IoT devices operate in a known and secure state and that their content remains confidential. Secure boot — a cornerstone of embedded device security — is the first line of defence against security breaches like botnets.
• Update firmware; however, remember that hackers can use over-the-air (OTA) updates to push their own malicious bots. Therefore, authentication should be applied to ensure that IoT devices retrieve the code from only approved systems.
   

Network:

• Connect IoT devices only in environments that use firewalls. These inspect incoming traffic and identify threats through behaviour, signature, IP history, and cross-examination of information consolidated from the IoT endpoints.
• Use DDoS mitigation services and tools that employ robust content delivery networks to take on the initial brunt.
• Secure connectivity between the IoT device and other systems like cloud services, using encrypted links based on protocols like Transport Layer Security (TLS). This prohibits man-in-the-middle attacks by capturing and analysing the data in transit.
• Harden TLS implementation stacks such as OpenSSL. Hardening eliminates software vulnerabilities by creating additional hardware security layers.
   

Secure storage:

• IoT systems demand a strong authentication in order to determine and verify the node and device identity. People generally equate encryption with security, but when it comes to protection against cyber-threats like botnets, authentication is a major pillar in the IoT security realm.

Designing secure embedded hardware

The premise of embedded security being developed into connected devices from the ground up is long overdue, and that begins with designing tamper-proof hardware that offers complete security solutions, not a mere collection of patches and fixes.

Traditional hardware security can include multiple security points:

• A Hardware Security Module (HSM), which requires a database to store, protect, and manage keys. This, in turn, mandates upfront investment in infrastructure and logistics.
• A Trusted Platform Module (TPM), which integrates cryptographic keys into device hardware; however, these are not well positioned for lower-price IoT applications.
• A security stack built on top of the microprocessor or microcontroller; however, this design requires many CPU cycles to accelerate authentication of applications and firmware. Therefore, security hardware built around the central MPU or MCU has seen limited success in IoT designs because compute-intensive operations like authentication burden the overall system and slow down the chipset performance.
   

For these reasons, traditional hardware security solutions do not transfer well to embedded systems. Instead, using dedicated security processors in embedded hardware designs close the software vulnerability gap with hardware key storage and cryptographic acceleration in IoT designs. They also facilitate hardening for well-known Transport Layer Security (TLS) implementation stacks such as OpenSSL, and they allow IoT nodes to automatically authenticate communications with the cloud.

For a start, these low-cost security co-processors, connected to the host MPU or MCU over an I2C link, facilitate the secure boot feature for protection against rogue firmware. Maxim’s MAXREFDES143 Reference Design is a good example of embedded security for IoT. It protects an industrial sensing node by means of authentication and notification to a web server. It features DeepCover Secure Authenticator with 1-Wire SHA-256 and a 512-bit user EEPROM, enabling data authentication at all levels from sensor node to web server.

These crypto elements (Figure 2) — smaller MCUs — are equipped with hardware cryptographic acceleration to carry out strong authentication so they can safeguard private keys, certificates, and other sensitive security data and thus ensure protection against a botnet invasion. Moreover, they simplify mutual authentication with cloud services like Amazon Web Services (AWS) by taking out the complexity associated with software-centric security implementations. It’s worth noting that the TLS standard has traditionally performed authentication and stored private keys in software.

Figure 2: Security MCUs like Microchip’s ATECC508A provide authentication to the IoT nodes and thus restrict botnets from entering the system. (Source: Microchip). For a clearer image click here.

Conclusion

The IoT industry, a proliferation of Internet-connected embedded electronics, is at a crossroads. For now, IoT botnets have mostly been targeted at web and application servers. But they can potentially be used to carry out far more destructive attacks than we’ve seen already. For example, they could impact the physical dimensions in a smart building by interfering with surveillance operations. Or they could create chaos on the streets by disrupting a system of traffic lights.

Developing embedded security in connected devices from the ground up is long overdue, especially when there are tens of millions of vulnerable IoT devices out there, with these numbers growing by the day. IoT enthusiasts are just discovering the darker side of Internet connectivity. The IoT is already moving toward a colossal scale. The time to take action and revisit embedded security is now.

Top image: ©stock.adobe.com/au/Nicolas Herrbach