Where Do Internet of Things Security Vulnerabilities Really Come From?

IoT security issues get a lot of attention these days. From firmware vulnerabilities to open backdoors, security can be tenuous in the “wild west” atmosphere of the IoT. Thousands of new devices are coming on the market; but, so far, there are no official standards or oversights to assure security best practices.

Why is Securing an IoT Device So Difficult?

Decades of evolution in security and networking have established strong principles to govern device security. It’s not rocket science—at least in theory. But to make it work, you have to maintain complete control of the device’s design, manufacturing, and deployment, and then regulate its network connection.

When you lose control of even one aspect of execution—for example, a different company is doing the manufacturing or running the network—ensuring security gets complicated.

Imagine deploying thousands of IoT asset tracking devices around the world. How will you keep the firmware up to date? How will you monitor all the devices for anomalous usage? How will you ensure that the networks they join as they move around the globe are secure?

At IoT scale, the straightforward process of securing a single device on a known network becomes far more complex. It’s harder to monitor, update, and audit all the devices to make sure they’ve been installed correctly. You need powerful tools to facilitate communication between teams and coordinate processes at scale, because a single person can’t do it all.

IoT Hacks in Action

To get a sense of what can happen when IoT devices are launched with security vulnerabilities, let’s take a look at a few well-known hacks.

TRENDnet Security Cameras

Back in 2012, hackers discovered a major security flaw in TRENDnet streaming IP cameras: a backdoor that allowed unauthorized users to access live video feeds from the connected home security cameras. Most of the cameras were located outside and inside people’s homes, with some used as baby monitors. Between 2010 and 2012, TRENDnet transmitted users’ sensitive information (such as login credentials) over the internet in readable, unencrypted text.

The Jeep Cherokee

In 2015, two hackers remotely took control of a Jeep Cherokee using vulnerabilities in the car’s entertainment system to access its dashboard functions. The two hacker-researchers commandeered the car while a journalist was behind the wheel, initiating a series of unexpected disturbances and finally disabling the brakes, causing the driver to swerve into a ditch. The experiment demonstrated just how serious—and life-threatening—IoT security vulnerabilities can be.

St. Jude Cardiac Devices

In 2017, the FDA issued an alert announcing security flaws in more than 465,000 connected pacemakers. While there were no reports of hackers harming patients, the pacemakers contained vulnerabilities that could allow bad actors to gain access and change settings, potentially posing a threat to the patient’s health.

What Can These Hacks Teach Us?

In each of these cases, vulnerabilities resulted from inconsistencies between different layers of the IoT stack. A lack of communication between design teams, engineers, and operators can lead to major problems.

In the case of the Jeep hack, engineers neglected to close an open port between the multimedia system and the CAN bus, which links the car’s key systems. While the entertainment system and the CAN bus weren’t directly connected, the open port acted as a hallway between them, allowing hackers to infiltrate the car’s main system.

With the St. Jude devices, the transmitter was the culprit. Vulnerabilities in the Merlin@home external transmitter could permit unauthorized users to take control of the implanted cardiac devices. And in the case of the webcams, TRENDnet left a backdoor open, allowing hackers to enter without a password and spy on their neighbors.

When you have one team programming and testing an IoT device and another team deploying it, they must stay in constant communication to ensure that the device remains secure throughout the process. Network operators should also implement multiple firewalls to detect and block anomalous traffic or unexpected port access attempts—and sound an alarm so users can respond without delay.

Layers of Possibilities for Hackers

Like a house with many doors, a cellular IoT device with multiple components presents numerous opportunities for hackers to uncover vulnerabilities. These possible points of entry are called attack surfaces, and their weaknesses typically originate from the engineering design and update processes. Even if different engineers secure their components, the system as a whole might remain vulnerable if there’s not a comprehensive security plan in place. Let’s take a closer look at possible vulnerabilities at each layer of the IoT stack:

SIM

Software running inside the SIM can create an attack vector. For example, some SIM cards contain a web browser called S@T Browser—and while it hasn’t been useful for decades, some connectivity providers continue to install it on their equipment by default. According to recent research, the browser contains vulnerabilities that allow hackers to extract location information without the subscriber’s awareness.

Module

Vulnerabilities at the module layer can allow hackers to access the device and implant malware, as a security researcher recently demonstrated with the ESP32 IoT chip. In this case, the module was found to be vulnerable to a “forever-hack,” which causes irreversible damage to the chip.

Firmware

Firmware presents numerous possibilities for security vulnerabilities, including unauthenticated access, default passwords, backdoors, insufficient data encryption, and open source code. Even if firmware is secure at the point of release, it’s essential to stay current with security patches and updates to prevent new vulnerabilities from surfacing.

OEM Wired and Wireless Interfaces

Whether the interface is on the device or in the cloud, vulnerabilities could exist in the source code, presenting another opportunity for hackers to gain access to the device.

Server

Most IoT deployments utilize cloud servers to manage devices. While cloud-based computing offers many benefits, it also introduces possible security risks, including insecure APIs or data breaches.

Targeted vs. Non-Targeted Attacks

Targeted attacks, e.g. advanced persistent threats (APTs), seek to penetrate a specific network or device. For example, someone wants to break into your network or device, so they try every trick they can think of to gain access. Like a burglar casing a house, they will inspect every attack surface in hopes of finding a vulnerability—an open window—through which to enter. The best protection against these types of attacks is achieved through a multi-layer approach, including intrusion and anomaly detection systems at the network level. These systems give you fair warning to lock down your devices before they’re compromised.

Non-targeted attacks, on the other hand, originate when hackers are searching far and wide for vulnerabilities to exploit. They don’t have you in mind, but your network and devices are still at risk. Botnets and worms are designed to exploit a single vulnerability across a wide breadth of systems. There are several ways to protect against these types of attacks, such as maintaining a private network, keeping firmware and software updated, and using strong passwords.

Connectivity Providers Can Build Security Into the IoT Stack

A number of IoT security measures fall under the domain of your connectivity provider. Here’s what you should expect them to do:

• Provide Three Layers of Firewalls
  Connectivity providers should firewall devices from the outside internet, customers from one another, and individual devices from one another so a single compromised device can’t be used to attack the rest of the customer’s fleet. These three layers of firewalling should be the minimum standard.
• Enforce the Principle of Least Privilege
  An IoT device on your network shouldn’t have access to other devices on your network by default. Those unnecessary links create additional attack surfaces. Connectivity providers should enforce the Principle of Least Privilege to restrict access between devices. They should also enable role-based control for network and account access that could affect devices.
• Hold a Stringent Change Management Policy
  Change Management is the art of developing systems of approval and record that prevent unauthorized changes from occurring. Change management reduces the risk caused by the human element, which can include errors as well as social engineering. It creates a standard process that must be followed strictly for any changes to network access control or device management.
• Offer Private IPs
  If your connectivity provider uses firewalls, you’ll have access to private IPs inside that ring of protection. A private IP is part of a private network, meaning that an internet destination cannot send traffic to it directly. The firewall intercepts the traffic and makes decisions on whether it goes through or not.
• Provide Secure Tunneling Options
  When you need inbound access to a device, the correct solution is not a public IP address—it’s having a private IP address behind your provider’s firewalls, and then using a product (such as Hologram Spacebridge (/blog/hologram-spacebridge-tunnel-sims)) that allows you to tunnel into the security domain associated with your own devices.

Security Best Practices for IoT Device Designers

While connectivity providers are responsible for a number of safeguards, IoT designers must also support security from their end. Here are a few best practices:

• Close any unnecessarily open ports.
• Eliminate any unneeded trusted interfaces.
• Enforce the Principle of Least Privilege within your device infrastructure and design team.
• Disable default passwords.
• Use encryption thoroughly and properly.
• Depending on the use case, consider using secure hardware.

Here’s the ultimate key to IoT security: Operate under the assumption that attackers are everywhere. Every device, every new network, and every layer of your stack introduces more attack surfaces and vulnerabilities—so approach your project with an eye toward identifying risks, eliminating vulnerabilities, and keeping everyone informed along the way.