How Not to IoT:Lessons in Security Failures

How Not to IoT: Lessons in Security Failures

Speakers: Zoltan "zh4ck" Balazs

Conference: DEF CON

YouTube: https://www.youtube.com/watch?v=TTdK1lbM5VI

Overview

In "How Not to IoT: Lessons in Security Failures," Zoltan "zh4ck" Balazs dissects a litany of pervasive security vulnerabilities found in common Internet of Things (IoT) devices, from smart doorbells and vacuum cleaners to Android TV boxes and IP cameras. The talk serves as a stark reminder of the abysmal state of security in many commercially available IoT products, highlighting how fundamental security principles are routinely overlooked or deliberately bypassed by manufacturers. Balazs emphasizes the importance of learning from these past mistakes, not only for consumers to make informed purchasing decisions but also for developers to build more secure and resilient devices.

Balazs, a seasoned offensive security researcher with a history of uncovering significant vulnerabilities, uses real-world examples from his personal research to illustrate the dangers. He reveals how simple flaws, such as cleartext credential transmission, unauthenticated access, and command injection, continue to plague devices, making them easy targets for botnets and other malicious actors. Beyond merely identifying problems, the talk also looks forward, proposing a vision for a more secure IoT ecosystem built upon open standards, robust operating systems, and privacy-centric design principles, offering a glimmer of hope amidst the current landscape of widespread insecurity.

The talk is particularly relevant in an era where smart devices are increasingly integrated into homes and critical infrastructure. As more aspects of daily life become connected, the security vulnerabilities in these devices pose significant risks, ranging from privacy breaches and data exfiltration to their weaponization in large-scale Distributed Denial of Service (DDoS) attacks. Balazs's presentation underscores the urgent need for a paradigm shift in how IoT devices are designed, developed, and deployed, advocating for security and privacy to be foundational rather than afterthought.

Background

▶ Watch: Talk introduction and speaker's past security work (0:00)

Zoltan Balazs's journey into IoT security began long before the term became a household name. With a career spanning over a decade in offensive security, he proudly recalls presenting a hardware firewall bypass tool at DEF CON 11 years prior, a testament to his long-standing engagement with cutting-edge security research. His practical experience is further underscored by a notable incident where a piece of his code, initially developed to exploit an authenticated command injection vulnerability in IP cameras, was repurposed by a botnet. This occurred after an easy authentication bypass was discovered, leading to his code running on an estimated 600,000 IP cameras, an accidental contribution to the botnet ecosystem that solidified his focus on the real-world impact of IoT vulnerabilities.

Initially, Balazs admits he was not a fan of smart home devices, aligning with the sentiment that "tech workers only have a printer and keep a shotgun next to it." However, a humorous "Alexa intruder alert" playbook, which involved turning off lights, playing Doom Eternal soundtracks, and releasing Roombas, sparked his interest in the potential, albeit often poorly secured, world of home automation. This personal evolution from skeptic to critical observer provides a unique perspective on the challenges and opportunities within IoT security.

The persistent problem Balazs addresses stems from several factors: the rapid proliferation of cheap devices, often developed by manufacturers prioritizing speed and cost over security; a lack of awareness or disregard for basic security hygiene among developers; and an ecosystem that often forces users into insecure practices. Many of the vulnerabilities he discusses, such as default credentials, unpatched software, and insecure communication protocols, are not new. They are the same classes of vulnerabilities that have plagued traditional IT systems for decades, now manifesting in a new, more pervasive, and often less manageable form within the IoT landscape. This talk builds upon a foundation of prior work, including other researchers' investigations into devices like the Eovox vacuum cleaners, providing a continuous narrative of the ongoing struggle against insecure IoT.

Key Findings

▶ Watch: Doorbell sends Wi-Fi password in cleartext debug logs (4:00)

Balazs’s research reveals a consistent pattern of severe security failures across various IoT device categories, demonstrating a systemic lack of security by design. His key findings, drawn from hands-on analysis of several devices, include:

• Cleartext Credential Transmission: Multiple devices, including a cheap doorbell and an Eovox Deebot vacuum cleaner, were found transmitting sensitive information like Wi-Fi passwords in cleartext. The doorbell sent it over HTTP to unknown cloud servers, while the Deebot transmitted it over an open Wi-Fi access point during the initial pairing process. This exposes critical network credentials to anyone with local network access or the ability to intercept traffic.
• Deceptive Firmware and Malware Distribution: A cheap Android smart TV box was found to be deliberately deceptive, advertising a non-existent Android version (11.1) while running an outdated OS with a security patch date from 2017 (Android 11 was released in 2020). Worse, it distributed malware via its firmware update mechanism, turning user devices into part of a botnet without their knowledge.
• Pervasive, Long-Standing Vulnerabilities in IP Cameras: An older IP camera model, which Balazs acquired in 2015, exhibited a shocking array of vulnerabilities, many stemming from the GoAhead web server first reported in 2004. These included Telnet enabled by default with default credentials, UPnP automatically exposing the device to the internet, unauthenticated access to configuration files containing cleartext admin and Wi-Fi passwords, and multiple command injection and stack overflow vulnerabilities. Despite being reported to the vendor, these issues remained unpatched for over a decade, with millions of such devices still online and vulnerable.
• Basic Command Injection on Authentication Pages: A Zyxel Network Attached Storage (NAS) device, despite being a more recent product (2020 research), featured a "plain vanilla command injection" vulnerability directly on its login page. This allowed attackers to execute arbitrary commands by manipulating user-supplied strings that were unsafely concatenated with system commands (cut, grep) operating on sensitive files like /etc/password.
• Challenges in Memory Corruption Exploitation: While command injection remains the primary attack vector for IoT botnets due to its simplicity and effectiveness, Balazs highlighted the inherent difficulties in achieving stable memory corruption exploits on diverse IoT hardware. The absence of modern exploit mitigations like stack canaries, ASLR (Address Space Randomization), and NX (No Execute) bits, coupled with varying memory layouts across device versions and models, makes Return-Oriented Programming (ROP) highly unstable and labor-intensive to develop universal exploits.
• Poor User Experience and Vendor Lock-in: The proliferation of proprietary mobile apps, mandatory registrations, frequent password resets, and often nonsensical End User License Agreements (EULAs) contribute to a frustrating and insecure user experience, pushing users away from engaging with security features.

These findings collectively paint a grim picture of an industry struggling with basic security principles, often at the expense of user privacy and device integrity.

Technical Deep Dive

▶ Watch: Eovox vacuum robot's incredibly complex setup process (6:00)

The technical details uncovered by Balazs reveal a consistent pattern of fundamental security design flaws and poor implementation practices across various IoT devices.

Starting with the cheap doorbell, the primary issue was its chatty debug log being transmitted over HTTP to unspecified cloud servers. Crucially, this log included the user's home Wi-Fi password in cleartext. This vulnerability bypassed even basic encryption protocols, making the password easily interceptable by anyone monitoring network traffic or by compromise of the vendor's cloud infrastructure. The inability to contact the vendor for remediation further highlights the common problem of unsupported and unpatchable devices.

The Eovox Deebot vacuum cleaner presented a different, yet equally critical, Wi-Fi credential leakage. During its notoriously complex setup process, the device created an open Wi-Fi access point. The user's phone would connect to this unencrypted network and then transmit the home Wi-Fi password to the vacuum cleaner via HTTP. This meant any local attacker sniffing traffic on the open Wi-Fi network could intercept the password. Balazs contrasted this insecure method with more robust alternatives like using Bluetooth for initial pairing or displaying a QR code on the mobile app for the device's camera to scan and decrypt credentials, a method he observed in some cheap IP cameras. The fact that the Eovox Deebot had a camera but didn't utilize this more secure method underscores a lack of security-conscious design. Despite vendor acknowledgment, a subsequent fix was not apparent upon re-testing, illustrating the often-slow and incomplete remediation efforts in the IoT sector.

The cheap Android smart TV box demonstrated outright deception and malicious intent. Advertised with "Android OS version 11.1" (a non-existent version), the device's build.prop file revealed an actual security patch date of 2017, significantly older than Android 11's 2020 release. This misrepresentation hid an underlying issue: the device was configured to receive firmware updates that installed malware, leveraging the always-on nature of TV boxes for botnet operations. This type of compromise turns user devices into resources for attackers, often without noticeable performance degradation, making it a lucrative target for malicious manufacturers or supply chain attackers.

Balazs dedicated significant attention to an IP camera based on the GoAhead web server, which he described as an "IoT good" for penetration testing due to its numerous vulnerabilities. Key issues included:

• Default Telnet Access: The camera ran a Telnet daemon on its default port with default usernames and passwords, making it immediately vulnerable to local attackers. Balazs attributed this widespread issue in IP cameras to the popular Rawink SDK, which likely enables Telnet by default, a setting rarely disabled by manufacturers.
• UPnP Exposure: The device's web server, running on port 81, used UPnP (Universal Plug and Play) to instruct home routers to open this port to the internet. This effectively bypassed network address translation (NAT) and exposed the camera to global attackers, turning a local vulnerability into a remote one.
• GoAhead Web Server Vulnerabilities (CVE-2004-1075 and others): The ancient GoAhead web server was rife with authentication bypasses and information disclosure flaws. These included manipulating URL paths (e.g., deleting, changing to backslash, or encoding forward slashes in GET requests) to bypass authentication.
• Unauthenticated Configuration File Download: A critical vulnerability allowed unauthenticated users to download the system.ini configuration file. This file contained cleartext passwords for the admin user, Wi-Fi network, FTP, and SMTP settings, providing a complete compromise of the device and potentially other networked services. The specific exploit involved sending an HTTP GET request with the parameter s missing or malformed for login_use and login_pass.
• Command Injection: The talk demonstrated an authenticated command injection vulnerability. An attacker could inject Unix commands into certain parameters, which would then be written to an SH file and executed, often on a schedule. Balazs's anecdote about using reboot as a test string, leading to a persistent reboot loop due to the script's execution on startup, highlighted the severity and persistence of these flaws.
• Stack Overflow: The source code analysis revealed strcpy functions used without length checks, particularly when handling usernames and passwords, leading to easily exploitable stack overflow vulnerabilities.
• Cloud Connection as an Attack Vector: The camera's mandatory cloud connection, which could only be disabled via Telnet and IPtables rules, was merely a wrapper for the existing web port vulnerabilities. This meant all local vulnerabilities were also accessible remotely via the cloud service, further expanding the attack surface. Researchers had even figured out how to enumerate millions of these devices via their device IDs through the cloud.

The Zyxel NAS device exemplified a "plain vanilla command injection" on its login page. The authentication logic involved reading the contents of /etc/password and another file, then piping them through cut and grep with user-supplied input. Crucially, this user input was not sanitized, allowing an attacker to inject arbitrary shell commands directly into the login process, achieving immediate root-level compromise without authentication. Balazs noted the irony of such a fundamental flaw appearing in a 2020 device, especially on a critical authentication surface.

Regarding memory corruption exploits, Balazs explained why they are less common in IoT botnets compared to command injection. While IoT devices often lack modern exploit mitigations (no stack canaries, ASLR, NX, everything running as root), the challenge lies in the diversity of hardware and firmware versions. Each version typically has a different memory layout, making Return-Oriented Programming (ROP) gadgets specific to that version. Developing a stable ROP chain requires extensive effort, often involving hardcoding gadget offsets for numerous versions, as seen in a Netgear exploit he displayed. He debunked the "blind ROP" research from Stanford, stating it doesn't work as described, further solidifying the difficulty of universal memory corruption exploits on IoT.

For the demo, Balazs showcased hacking the vulnerable IP camera. He used Metasploit to generate a Meterpreter payload for the MIPS architecture (little endian). After setting up a Metasploit listener, he first exploited an information disclosure vulnerability to retrieve the admin username and password. Then, using an authenticated command injection, he started a Telnet daemon on a custom port. A key challenge was transferring the Meterpreter binary, as the camera lacked common tools like wget, curl, or netcat. Balazs demonstrated a clever technique using echo and hexaw to "copy-paste" the malware to the device, ultimately establishing a Meterpreter session. He also revealed a trick for external access: using the UPNC binary found on the device to instruct the router to open the custom Telnet port, bypassing typical firewall restrictions.

Demo / Proof of Concept

▶ Watch: Vacuum robot transmits Wi-Fi password over open access point (8:00)

Zoltan Balazs provided a compelling live demonstration of exploiting a vulnerable IP camera, illustrating the practical implications of the technical flaws he discussed. The demo focused on achieving remote code execution and establishing a Meterpreter session, a powerful Metasploit payload for post-exploitation.

The process began with the attacker leveraging Metasploit Framework to generate a custom payload. Given the specific architecture of the target IP camera, Balazs specified a MIPS (little endian) architecture for the reverse TCP Meterpreter payload. This ensures compatibility with the device's CPU.

Once the payload was generated, a Metasploit listener was set up to await incoming connections from the compromised camera. The first step in the actual exploitation involved using an existing vulnerability (likely an information disclosure or authentication bypass related to the GoAhead web server) to extract the admin username and password from the device. This provided the necessary credentials for subsequent authenticated attacks.

With authenticated access, Balazs then exploited a command injection vulnerability. He used this to execute a command that would start a Telnet daemon on a non-standard port, specifically 4444. This provided an alternative, more direct command-line interface to the device, which could be accessed without the previous authentication hurdles if the attacker was already authenticated to set it up.

A significant hurdle in the exploitation chain was the absence of common utilities like wget, curl, or netcat on the embedded Linux system of the IP camera. These tools are typically used to download malicious binaries to a target. To overcome this, Balazs employed an ingenious method: he used echo commands combined with hexadecimal representation (hexaw) to slowly "copy-paste" the Meterpreter binary directly onto the device's filesystem. This involved echoing hex-encoded chunks of the binary, converting them back to their raw form, and appending them to a file until the full executable was reconstructed.

Once the Meterpreter binary was successfully transferred and executed, a Meterpreter session was established, granting the attacker comprehensive control over the IP camera. This included file system access, process management, and the ability to pivot to other systems on the network.

Balazs also highlighted a crucial post-exploitation trick: using the UPNC binary found on the device itself. With command injection, an attacker could instruct this binary to ask the router to open port 4444 (or any other desired port) to the internet. This effectively bypassed the router's NAT and firewall, making the Telnet session (or any other service the attacker chose to expose) accessible from anywhere on the internet, even if the initial exploit required local network access or a cloud connection. This demonstrates how even seemingly minor utilities on an embedded device can be weaponized to enhance attacker persistence and reach.

The demo vividly illustrated the ease with which these devices can be compromised, from initial information gathering to full remote control, underscoring the severe security posture of many commercially available IoT products.

Defensive Implications

▶ Watch: Android TV box ships with a non-existent OS version (10:30)

The pervasive vulnerabilities highlighted by Balazs demand immediate attention from both consumers and IoT developers to mitigate risks and foster a more secure ecosystem.

For Consumers and Network Defenders:

1. Be Skeptical of Cheap IoT Devices: The adage "you get what you pay for" often holds true for IoT. Cheap devices are frequently developed with minimal security considerations. Prioritize reputable brands known for security updates and robust practices, even if they cost more.
2. Isolate IoT Devices: Place all IoT devices on a separate VLAN or guest network. This network segment should be isolated from your primary home or corporate network to prevent compromised devices from accessing sensitive data or other critical systems.
3. Disable UPnP on Routers: Universal Plug and Play (UPnP), while convenient, is a significant security risk. It allows devices on the local network to automatically open ports on the router to the internet without user intervention. Disabling UPnP prevents devices like the vulnerable IP camera from exposing themselves to global attacks.
4. Change Default Credentials: If a device ships with default usernames and passwords (especially for services like Telnet or web interfaces), change them immediately during setup. Better yet, avoid devices that rely on easily guessable or hardcoded credentials.
5. Monitor Network Traffic: Tools like Wireshark or network intrusion detection systems can help identify devices transmitting data in cleartext (e.g., Wi-Fi passwords over HTTP). If such behavior is observed, discontinue use of the device.
6. Regular Firmware Updates (from trusted sources): While some devices, like the Android TV box, can push malicious updates, legitimate firmware updates are crucial for patching known vulnerabilities. Ensure updates come directly from the vendor's official channels and verify their authenticity if possible.
7. Consider Open-Source and Local-First Solutions: Platforms like Home Assistant offer greater transparency, control, and privacy by keeping data local and relying on open standards. These solutions often empower users to manage their devices without reliance on potentially insecure cloud services.
8. Physical Security: For devices like doorbells, physical access can lead to compromise (e.g., factory reset to add an attacker's account). Ensure physical security measures are in place where appropriate.
9. Dispose of Insecure Devices Responsibly: Simply trashing insecure devices isn't enough, as someone else might retrieve and reuse them. Balazs's humorous, yet serious, recommendation to "burn them in hell" underscores the need for secure disposal to prevent their reintroduction into the ecosystem.

For IoT Developers and Manufacturers:

1. Security by Design: Integrate security considerations from the very beginning of the product lifecycle, not as an afterthought. This includes threat modeling, secure coding practices, and regular security audits.
2. Secure Credential Handling: Never transmit sensitive information like Wi-Fi passwords in cleartext. Utilize TLS/SSL for all network communication and implement secure pairing mechanisms like Bluetooth Low Energy (BLE) or QR code scanning with strong encryption for initial setup.
3. Input Validation and Sanitization: Implement rigorous input validation and sanitization for all user-supplied data to prevent command injection, buffer overflows, and other common vulnerabilities. Avoid dangerous functions like strcpy without length checks.
4. Disable Unnecessary Services: By default, disable all unnecessary services, ports (e.g., Telnet, debug ports), and accounts. If required for debugging or support, these should be securely authenticated and only enabled when absolutely necessary.
5. Secure Firmware Updates: Implement robust, cryptographically signed firmware update mechanisms to prevent the installation of malicious or compromised firmware. Ensure updates are delivered securely and users can verify their authenticity.
6. Avoid Roll-Your-Own Cryptography: Do not attempt to implement custom encryption schemes. Rely on well-vetted, industry-standard cryptographic libraries and protocols (e.g., TLS 1.3).
7. Embrace Open Standards and Secure Platforms: Adopt modern, secure standards and platforms like Zephyr RTOS, Matter, and Thread. These offer features like secure boot, memory protection, and standardized, secure application layers, significantly reducing the attack surface.
8. Long-Term Support and Patching: Commit to providing long-term security updates and patches for devices. Establish clear channels for security researchers to report vulnerabilities and respond promptly to identified issues.
9. Privacy-Centric Design: Design devices to function fully without mandatory cloud connectivity where possible. Give users control over their data and connectivity, aligning with principles of privacy by design.

By addressing these defensive implications, the IoT industry can move towards a future where connected devices enhance convenience without compromising security and privacy.

Key Takeaways

• Pervasive, Fundamental Security Failures: Many commercially available IoT devices suffer from basic, easily exploitable vulnerabilities such as cleartext password transmission (via HTTP or open Wi-Fi), default credentials, unauthenticated access to sensitive data, and widespread command injection flaws.
• Command Injection is King for Botnets: Despite the theoretical possibility of memory corruption exploits, command injection remains the dominant attack vector for IoT botnets due to its simplicity, reliability, and the ease with which it can be leveraged to gain immediate control over devices.
• Insecure Pairing and Updates are Critical Weak Points: The initial device pairing process often exposes Wi-Fi credentials to local attackers, while insecure or malicious firmware update mechanisms can turn devices into malware-laden botnet nodes. Secure pairing (e.g., Bluetooth, encrypted QR codes) and cryptographically signed firmware updates are essential.
• Vendor Negligence and Lack of Support: Many manufacturers demonstrate a profound disregard for security, failing to patch known vulnerabilities for years (or ever), misrepresenting product security features, and making it difficult or impossible for researchers to report issues.
• Memory Corruption is Harder, but Not Impossible: While IoT devices often lack modern exploit mitigations, the diversity of hardware and firmware versions makes universal memory corruption exploits (like ROP) complex and unstable, requiring significant effort to tailor to specific device versions.
• A More Secure Future is Possible with Open Standards: Emerging technologies and standards like Zephyr RTOS (secure, no shell), Matter (interoperable application layer), Thread (efficient, mesh networking for battery devices), Home Assistant (open-source, privacy-focused server), and RISC-V (open instruction set CPU) offer a promising path toward a more secure, private, and user-controlled IoT ecosystem.

About the Speaker(s)

Zoltan "zh4ck" Balazs is a distinguished offensive security researcher with a deep passion for creating tools that push the boundaries of cybersecurity. His extensive experience includes developing a hardware firewall bypass tool, which he proudly presented at DEF CON over a decade ago. Balazs is known for his practical approach to security, even having a piece of his code inadvertently adopted by a botnet that compromised 600,000 IP cameras after he published an authenticated command injection vulnerability that was later combined with an authentication bypass.

Initially, Balazs approached smart home technology with skepticism, aligning with the sentiment of tech workers who prefer minimal smart devices. However, his journey into IoT security research has evolved his perspective, leading him to appreciate the potential of a truly secure and private smart home. He currently works for a company that is a member of the alliance behind the Matter and Thread standards, though he emphasizes that his recommendations for a secure IoT ecosystem are his personal and professional opinion. Balazs actively shares his research and insights on his blog, accessible at zambbalage.com.