BLOG
9 Most Serious IoT Vulnerabilities
A growing number of consumers across all fabrics of society now have various IoT devices in their everyday personal life and at home. IoT devices are growing exponentially in numbers, but along with growth comes task for IT engineers to find a silver bullet in solving IoT security.
Known IoT vulnerabilities offer cyber-criminals an easy, relatively frictionless entry point into corporate networks, enabling them to propagate a wide range of attacks. In fact, most penetrations take the path of least resistance, and IoT vulnerabilities follow the same pattern. Once one device is compromised, it can be easy to infiltrate further connected devices. In order to protect from both known and unknown vulnerabilities, it is critical that enterprises employ a multi-layered cybersecurity strategy that protects against both established malware families cyber-attacks and brand new threats. As IoT adoption matures, manufacturers and service providers must create systems of IoT governance. When coupled with solutions for proactive response and resiliency, there’s hope for the future of IoT security.
The power, space, cost, processing and memory limitations that each IoT node is subject to means that more streamlined approaches need to be taken, that while effective do not represent to heavy an overhead.
Rudy Ramos
Here are nine IoT vulnerabilities for your personal study as a lack of knowledge creates fear, but examining potential threats builds security.
1. Missing Authentication
Authenticating a user for an IoT app is a good thing. When the app can control building access and environmental control, or provide access to audio and video devices that might spy on the occupants of a building, it seems that authentication would be considered a "must," but in some cases, even the most basic authentication is missing.
Two types of authentication become important for IoT applications. The first is user authentication. Given the complex nature of many IoT environments, the question is whether each device should require authentication, or whether a single system authentication is sufficient for every device on the network. Ease-of-use considerations persuade most system designers to opt for the latter, which makes strong authentication to the hub or control surface critical.
Single sign on for the system also makes another type of authentication — device authentication — much more important. Since the user is not authenticating at each device interface, the devices in the IoT network should require authentication between themselves so that an attacker can't use implied trust as a malicious gateway into the system.
As with Web interface security, the foundation for closing this security hole is to treat the IoT as a "real" application network. There will be special issues of "how" because many of the devices don't have native user interfaces — depending on browser UIs or apps for human interaction — but the lack of authentication for any device makes security at the IoT perimeter even more critical.
2. Bad Web UIs
Everybody loves a friendly Web user interface! For IoT applications, they make controlling features and functions, setting up devices, and integrating devices into systems faster and easier tasks than they might otherwise be. The trouble is, they often bring to criminals the same ease of use.
There is no new thing under the sun. The problems that plagued IoT Web interfaces are the same that have crippled and crashed enterprise Web applications. While SQL injection is somewhat less of an issue in IoT applications, command injection, cross-site scripting, and cross-site request forgery are all programming flaws that can hand criminals ready access to devices and complete systems for controlling, monitoring and accessing real-world operations.
Fortunately, the remedies for most of the Web UI security issues are the same as what has been preached to Web developers for years. Validate input, require strong passwords and don't allow the default password to be used beyond the first stages of initial setup, don't expose credentials, limit password retry attempts, and make sure that password and username recovery routines are robust.
3. Firmware Failure
Firmware, like bacteria and peas, evolves. Developers note what has gone wrong, where vulnerabilities can be found, and how things could be better, and release new firmware that is an improvement over the original. The problem for many IoT devices is that there's no way to load it. And that makes firmware a serious vulnerability.
Among the advantages of constantly evolving firmware is that updates make the system a moving target. When the firmware on a device is fixed and immovable, attackers can dissect it at their leisure, develop exploits in their own sweet time, and launch attacks confident in the knowledge that they will work on every example of the device. The VPNFilter attack, launched in May, is an example of what can happen when an entire category of devices is unable to update — or, in the case of updatable devices, users are unable or unwilling to apply the available updates.
Obviously, if a device can be updated, then best security practices demand it be kept up to date on patches and revisions. If the device cannot be updated, then keeping up with known vulnerabilities is critical, as is making sure those vulnerabilities are blocked by another layer of environmental security.
4. Locked-In Defaults
You know that default username and password that comes with the IoT device? So does everyone who can put together a Google search. And that's a real problem for the devices and systems that don't allow for the possibility of changing default settings.
Default user credentials (and, let's be honest, the user who really matters here is named "admin") are the giant, flashing warning signal on IoT security settings, but they're not the only settings that matter. Network parameters that include ports used, setting every user with admin privileges, logging (or not), and event notifications (or not) are among the security-focused settings that should be changeable to meet individual deployment needs.
Beyond allowing for security settings that mesh more completely with an environment's existing security infrastructure, modifications to default settings make the IoT attack surface a more jagged, less welcoming place for intruders. This is not something easily changed by the user. However, defaults that can't be changed provide another point for additional scrutiny from the security infrastructure that will be overlaid on the IoT deployment.
5. Bad Network Security
A poorly written IoT device app can poke holes in your firewall from the inside out — holes that an attacker can use to climb into your systems and launch attacks on IoT devices and general-use computers. The same tricks that allow naive users to install IoT devices on their home networks without configuring their firewalls create connections through those firewalls that attackers can use to circumvent carefully considered protections.
In many cases, firewalls are outward-facing. That is, they focus on traffic from the outside trying to get into the network. IoT devices get around this by initially calling their control server from inside the network, and then maintaining the connection with regular heartbeat transmissions. With the connection established, an attacker can exploit vulnerabilities in unencrypted and unauthenticated traffic to send malicious traffic back into the network on the open connection.
Some might say that an attacker would have to know about the connection and the type of device in order to exploit vulnerabilities, and they're right, but those people might not have heard of Shodan. With a simple Shodan search, it's possible to find all kinds of devices, communications, and open ports without expending much energy or time. Once found, simple scripts automate the process of exploiting the issues. Taking advantage of bad network security is then a task of gathering, not hunting, vulnerable IoT systems.
6. Leaky Cloud Interface
Just a few commercial automated systems function without relying on the cloud for some part of their processing power and command knowledge base. That's especially true if voice processing or command translation is in use, whereby the connection to the cloud can become a significant vulnerability.
Think about the types of messages that can go back and forth between an IoT instance and the cloud on which it rests. Simple control packets flow, certainly, but so might be with recorded voice and video, task lists, calendar events, and instructions to DevOps frameworks and tools. Are those sensitive data streams traveling through encrypted tunnels? Are you sure?
As with so many other aspects of IoT security, the real issue is that most of the time, users have no say in how the interface to the cloud is secured. Add to that the fact that most users have no idea where the cloud foundation is located, and you're left with a situation that can be a security (and regulatory) nightmare. The lesson here is to understand the capabilities of IoT devices, where they're sending their data, and what you can do with wrappers, firewalls, intrusion-prevention system (IPS) appliances, and other security tools to make up for the holes in a leaky cloud interface.
7. IoT devices as proxies
It is possible to use IoT devices as proxies or intermediaries for anonymity or requests to route malicious traffic for cyber-attacks and computer network exploitation. IoT proxy servers are attractive because they provide a layer of anonymity by transmitting all Internet requests through the victim device’s IP address. IoT devices are particularly attractive targets because they allow spoofing identity and access to many business websites that block traffic from suspicious or foreign IP addresses.
8. DDoS Botnet
Smartly engineered distributed denial of service (DDoS) can easily slow down or fully stop the internet traffic either within the targeted company network, or a large geographical area covered by internet providers. The botnet is able to scan big blocks of the internet for open Telnet ports and log in to them using a sheer number of username/password combos that are frequently used as the default for these devices. Using this strategy it is possible to amass a large botnet army.
Given that many IoT hardware devices require both low power and low cost, putting adequate security in place is often difficult. Each IoT node will only have processing and memory resources needed to cover the function for which it’s been deployed, with little or no additional headroom available. Such nodes are not armed with the same degree of protection that would be featured in a PC or network server
Employing a secure boot process and establishing a hardware-based root-of-trust is pivotal in ensuring that IoT nodes maintain long-term operation in a known and secure state and that any data that they hold is not accessible to unauthorized parties. Also, appropriate authentication mechanisms must be put in place to safeguard against the threat posed by invalid over-the-air (OTA) firmware updates, as this can be a way for hackers to compromise an embedded system.
9. The MQTT Issue
Finally, when a system designer or developer forgets about security entirely, issues abound. In the case of MQTT, a communications protocol from the world of industrial control, tens of thousands of deployed systems lack even the most fundamental security.
For years, the industrial control security model was simple and twofold. First, the systems were rarely connected to any wider area network. Next, who would want to attack and industrial control system? There's nothing of value there!
Now, of course, the systems depend on the Internet, and all sorts of attackers want to gain access to or control over the IoT devices because of the data they can generate and the launch pad they can provide to other systems. It's important to note that with MQTT and other protocols, vulnerabilities may not lie in the protocols themselves but in the way those protocols are implemented.
The key to securing IoT deployments is knowledge: knowledge of what is actually deployed in the IoT network, knowledge of what those devices are doing on the networks, and knowledge of the data flowing back and forth between local devices and the cloud systems they depend on for data analysis and control.