Best Practices for IoT Vulnerabilities

In 2020, security researchers discovered a critical vulnerability in U-Tec’s Ultraloq smart locks. The vulnerability was in the cloud API, which allowed for remote control of the lock. Attackers could exploit the API to remotely unlock doors, without requiring the user’s password or direct access to the device. This vulnerability stemmed from weak authentication and improper authorization checks in the API. Once attackers identified a valid device ID or user ID, they could send crafted requests to manipulate the lock. One can only imagine the adverse effects of exploiting this vulnerability.

While IoT devices have led to massive increases in convenience, efficiencies, and lifestyle improvements, even altering user behavior in many cases, vulnerabilities like the above one pose a serious risk to their mass adoption. As developers in the IoT space, it is critical to understand these vulnerabilities, how attackers exploit them, and what you can do to protect your devices. This article will explore all these aspects, with several real examples embedded throughout.

Summary of Key IoT vulnerabilities concepts

The table below summarizes the four high-level IoT vulnerability concepts this article will explore in detail. 

Your single pane of glass for
IoT security management

Learn More

• 

  Monitor the health of physical IoT devices and receive alerts in real-time

• 

  Automate firmware upgrades, password rotations & certificate management

• 

  Generate ad hoc and scheduled compliance reports

Why are IoT devices vulnerable?

We cover IoT security in depth in this article. Let’s look at three key takeaways that explain why IoT devices are vulnerable.

Resource constraints

IoT devices typically have memory, power, and computation limitations that discourage the use of computationally intensive and energy-hungry encryption algorithms. Similarly, they can’t afford to host security software and features to easily address new and emerging threats while in service.

External dependencies

IoT devices are also dependent on external components, such as sensors or associated user interfaces, like websites or mobile apps, to offer value. Vulnerabilities in these external components or in the communication between the device and the component can make a potentially secure IoT device insecure.

Limited oversight and scrutiny

IoT devices don’t enjoy the luxury of intensive scrutiny from customers (do you spend as much time reviewing the security of your smart speaker as you do with your smartphone?) and are often competing in a highly price-elastic market. Therefore, security isn’t always at the top of the priority list for manufacturers.

Types of attacks against IoT devices

The attacks that exploit IoT vulnerabilities in practice depend on threat actor sophistication, opportunity, and motivation. Let’s explore attacks against IoT devices from the perspective of threat actors with different motivations. 

Threat actors looking to gain control devices

The Mirai botnet attack is a prime example, where attackers attempted to gain control of IoT devices to execute Distributed Denial of Service (DDoS) attacks on popular websites, such as Twitter. Another example is the Hajime malware that affected over 300,000 IoT devices.

Threat actors may also attempt to gain control of security devices (e.g., by exploiting camera vulnerabilities) as part of a larger security attack on a sensitive location, such as a bank or financial institution.

Threat actors aiming to extract sensitive information

IoT devices often store and/or process a lot of sensitive information, the most common example being your WiFi password. Other devices like smart locks usually process more sensitive information like your biometrics. Some devices, such as cameras and voice assistants, even capture your private moments. Threat actors can use this data to help carry out sophisticated attacks.

Threat actors that want to make devices nonoperational 

As a counter to the Mirai botnet attack discussed above, one developer created the BrickerBot malware. This malware permanently disabled (bricked) insecure IoT devices, affecting more than 10 million devices before it was retired in 2017. Over here, the intent was in the gray: to limit the damage of the Mirai botnet attack. However, it is clear that malicious intentions behind such attacks are not difficult to conceive.

Ransomware attacks are also an excellent example of this category, where the attacker attempts to render the system dysfunctional (or at least lose control) and only restores it after a ransom is paid. Ransomware attacks in the healthcare space are well-known, with a notable example being the BlackCat ransomware attack in February 2024 against Change Healthcare (where a $22 million ransom was paid). 

Types of IoT vulnerabilities

Having examined the types of attacks that threat actors commonly carry out, let’s now review the vulnerabilities that attackers typically exploit. 

Insecure Storage

CVE-2025-2189 is one example of such a vulnerability that affected Tinxy smart devices. It involved the plaintext storage of security credentials in the firmware, and an attacker with physical access to the device could extract the credentials by analyzing the binary firmware.

A very similar vulnerability in Philips lighting devices (CVE-2024-9991) allowed an attacker with physical access to the devices to extract the WiFi credentials by analyzing the binary firmware.

Unsecured components

CVE-2023-50129 describes one such vulnerability, where the NFC tags of the Flient Smart Door Lock v1.0 were unencrypted. This allowed attackers to create a cloned tag by briefly bringing it into physical proximity with the original tags, thereby accessing the smart lock.

Hardcoded credentials

CVE-2019-17098 affected August Connect WiFi bridge. The app and the firmware used a hardcoded cryptographic key for communication, allowing an attacker to decrypt an intercepted payload containing the WiFi network authentication credentials

CVE-2023-1748 describes a more severe instance of this vulnerability. Certain Nexx smart home devices used hard-coded credentials. An attacker with unauthenticated access to the Nexx Home mobile application or the affected firmware can view credentials and access the MQ Telemetry Server (MQTT) server, allowing them to control garage doors or smart plugs for any customer remotely.

Buffer overflow

CVE-2023-27127 affected Belkin Smart Outlet V2 F7c063. Devices having firmware version firmware_2.00.11420.OWRT.PVT_SNSV2 were vulnerable to a stack-based buffer overflow in the ChangeFriendlyName() function, which allowed attackers to cause a Denial of Service (DoS) attack via a crafted UPNP request.

Improper/weak authentication and authorization

CVE-2023-1751 describes a cloud-side vulnerability that affected Nexx smart home devices. These devices use a WebSocket server that does not validate if the bearer token in the Authorization header belongs to the device attempting to associate. This security weakness could allow any authorized user to receive alarm information and signals meant for other devices, which leaks a device ID.

CVE-2014-7279 affected Konke Smart Plug K. It does not require authentication for TELNET sessions, which allows remote attackers to obtain “equipment management authority” via TCP traffic to port 23.

Default passwords

CVE-2023-0896 describes a default password vulnerability in the Lenovo Smart Clock Essential with Alexa Built-In that could allow unauthorized device access to an attacker with local network access.

Feature vulnerabilities

CVE-2018-11567 demonstrates that sometimes seemingly harmless features of your product can prove to be the perfect vulnerability for a diligent attacker. Alexa learned this the hard way in 2018. Before April 27, 2018, the re-prompt feature in Amazon Echo devices was prone to misuse by a custom Alexa skill. The re-prompt feature is designed so that if Alexa does not receive an input within 8 seconds, the device can speak a reprompt, then wait an additional 8 seconds for input; if the user still does not respond, the microphone is then turned off. 

The vulnerability involves empty output-speech reprompts, custom wildcard (“gibberish”) input slots, and logging of detected speech. If a maliciously designed skill is installed, an attacker could obtain transcripts of speech not intended for Alexa to process, but simply spoken within the device’s hearing range. 

Improper input validation

Locus Energy Meters before (and including) LGate 320 were affected by CVE-2016-5782. These meters use a PHP script to manage the energy meter parameters for voltage monitoring and network configuration. he PHP code does not properly validate the information sent in the POST request. This could allow an attacker to take control of LGate, which has its web server port publicly exposed.

Improper access controls

CVE-2018-20007 describes an access control vulnerability in Yeelight Smart AI Speaker 3.3.10_0074. These devices have improper access control over UART,, allowing physical attackers to obtain a root shell. The attacker can then exfiltrate the audio data, read cleartext WiFi credentials in a log file, or access other sensitive device and user information.

Similarly, CVE-2024-41624 states that incorrect access control in Himalaya Xiaoya nano smart speaker rom_version 1.6.96 allows a remote attacker to have an unspecified impact.

Unencrypted communication

CVE-2017-18642 states that Syska Smart Bulb devices from August 8, 2017, and earlier receive RGB parameters over cleartext Bluetooth Low Energy (BLE), which can lead to sniffing, reverse engineering, and replay attacks.

CVE-2019-189080 describes a similar vulnerability in Philips bulbs. On Signify Philips Taolight Smart WiFi Wiz Connected LED Bulb 9290022656 devices, an unprotected API lets remote users control the bulb’s operation. Anyone can turn the bulb on or off, or change its color or brightness remotely. There is no authentication or encryption to use the control API. The only requirement is that the attackers have network access to the bulb.

Best practices to mitigate IoT vulnerabilities

Having understood the attacker’s methods and the vulnerabilities they exploit, let us now examine best practices for protecting IoT devices against these vulnerabilities.

1. Assess the context-specific risk

Not all vulnerabilities are worth losing sleep over. Some may as well be enabling more benefits than the harm caused by their exploitation. For example, unauthenticated control of smart bulbs over local networks might be provided and promoted willingly by you as a developer, allowing tech-savvy customers to build custom solutions around the smart bulb. The risk-weighted assumption would be that an attacker trying to alter the brightness or color of a household smart bulb is an unlikely scenario, as it would hardly yield any benefits for the attacker.

2. Follow password/certificates related best-practices

Basic security hygiene for IoT passwords and certificates can go a long way in mitigating IoT vulnerabilities. Four ways organizations can reduce IoT vulnerability risk include:

• Don’t use default or hardcoded credentials
• Encrypt passwords in storage and in transit
• Rotate passwords periodically
• Enforce strong password policies

3. Perform IoT device firmware updates regularly 

Perform regular firmware updates where possible. If you read about the various CVEs mentioned in the above section, you’ll notice that most of the vulnerabilities were fixed by the manufacturers via a firmware update. Regularly updating the firmware ensures that you are always protected against the known vulnerabilities. As a developer, you can strive to provide auto-update features for your devices wherever possible. Where user intervention is required, ensure that sufficient nudges are provided to users to proceed with the update.

4. Implement strong IoT device access controls

Administrators should always provide access based on the principle of least privilege (PoLP) to reduce the blast radius of damage a single compromised device or account can create. Additionally, the risk of human error should also be considered when designing for security.

5. Review available guidelines

Read about the security recommendations for your domain/industry and try to implement the fail-safes against the top vulnerabilities. This IoT Security Best Practices article provides a comprehensive overview of available IoT security standards. A quick scan of known CVE codes for your product or technology keywords on https://www.cve.org can also help you stay up-to-date with common vulnerabilities reported recently.

6. Use IoT security management software

For enterprise fleets, it is worthwhile investing in an IoT security management software, like SecuriThings. A platform like this can significantly reduce your administrative burden and automate tasks such as device discovery, firmware updates, and password rotation, providing a single dashboard view of your entire fleet. It can also handle compliance management on your behalf, wherever required, and provide you with an actionable list of visible vulnerabilities.

Features of IoT security management software. (Source)

Your single pane of glass for
IoT operations management

Learn More

• 

  Monitor the health of physical IoT devices and receive alerts in real-time

• 

  Automate firmware upgrades, password rotations & certificate management

• 

  Generate ad hoc and scheduled compliance reports

Conclusion

IoT devices are vulnerable due to the limited resources (memory, power, computation) available to IoT devices, dependence on external sensors and user interfaces, and limited user mind-share. Attackers exploit these vulnerabilities to gain control of devices, extract sensitive information from them, or render them dysfunctional. The vulnerabilities are of various types and found across the spectrum of devices. However, following the best practices ensures sufficient protection against most of the common vulnerabilities. Enterprise fleets can benefit significantly from IoT security management software like SecuriThings.