Who Left the Door Open? Investigating the Causes of Exposed IoT Devices in an Academic Network

Who Left the Door Open? Investigating the Causes of Exposed IoT Devices in an Academic Network

Speakers: Takayuki Sasaki; Takaya Noma; Yudai Morii; Toshiya Shimura; Michel van Eeten; Katsunari Yoshioka

Conference: IEEE S&P

YouTube: https://www.youtube.com/watch?v=br7UE-5fg3o

Overview

This talk, "Who Left the Door Open? Investigating the Causes of Exposed IoT Devices in an Academic Network," delves into a critical and pervasive security challenge: the widespread exposure of Internet of Things (IoT) devices on institutional networks. Presented at the prestigious IEEE S&P conference, the research meticulously dissects the root causes behind vulnerable IoT devices, particularly focusing on the presence of risky services like Telnet and FTP. The team, comprising Takayuki Sasaki, Takaya Noma, Yudai Morii, Toshiya Shimura, Michel van Eeten, and Katsunari Yoshioka, conducted a comprehensive investigation within their university's Class B campus network, revealing a concerning landscape of insecure devices.

The core premise of the research is to ascertain whether the primary responsibility for these exposed devices lies with the device owners or the manufacturers. By employing a multi-faceted methodology that includes network scanning, owner surveys, manual analysis, manufacturer surveys, and penetration testing, the researchers systematically addressed five key research questions. The findings unequivocally point towards manufacturers as the predominant contributors to the problem, highlighting systemic issues in device design, default configurations, and inadequate security documentation. This work is crucial for understanding and addressing the fundamental security flaws plaguing the rapidly expanding IoT ecosystem, advocating for a shift in accountability to those who design and produce these devices.

The implications of this research are far-reaching, extending beyond academic environments to any network where IoT devices are deployed. The continued proliferation of IoT devices, often integrated without proper security considerations, poses significant risks to data privacy, network integrity, and overall cybersecurity posture. By shedding light on the mechanisms through which these vulnerabilities arise and persist, the talk provides valuable insights for both security professionals striving to defend networks and policymakers aiming to mandate higher security standards for IoT manufacturers.

Background

▶ Watch: Identifying exposed IoT devices and the core question (0:00)

The rapid proliferation of Internet of Things (IoT) devices has introduced a new frontier of cybersecurity challenges. From smart sensors and cameras to network-connected printers and home automation systems, these devices are increasingly integrated into various environments, including academic institutions. University networks, characterized by their open nature and the presence of a diverse array of faculty and student-owned devices, often represent a microcosm of the broader internet, making them particularly susceptible to the security risks posed by insecure IoT deployments.

The problem of exposed IoT devices is not new; numerous studies have documented the widespread availability of vulnerable devices on the public internet, often accessible via services like Telnet and FTP. Telnet, a legacy network protocol, transmits data, including authentication credentials, in plaintext, making it highly susceptible to eavesdropping and unauthorized access. FTP, while more secure variants exist, often suffers from similar plaintext credential issues and misconfigurations, allowing unauthorized file access. The continued presence of these risky services, often enabled by default, on modern IoT devices is a significant concern. Previous research has largely focused on identifying how many devices are exposed and what types of vulnerabilities they possess, but there has been a notable gap in understanding why these devices remain exposed and who is primarily responsible for their insecure state.

This research specifically addresses this gap by investigating the underlying causes within a real-world academic network. The choice of a Class B campus network provides a rich and representative dataset, encompassing a wide range of IoT devices brought in by individuals with varying levels of technical expertise and security awareness. The inherent challenges in securing such a dynamic and heterogeneous environment—where devices are often unmanaged by central IT, lack standardized security policies, and receive sporadic updates—exacerbate the risks. The project commenced with a proactive security investigation, scanning the university's Class B campus network, which revealed 220 hosts running either Telnet or FTP. A significant majority of these, 185 hosts, were identified as IoT devices, underscoring the scale of the problem and setting the stage for a deeper inquiry into its origins. The core question guiding their investigation was: "Who left that door open—device owners or device manufacturers?" This question frames the entire research, seeking to assign responsibility and thereby identify effective points of intervention for improving IoT security.

Key Findings

▶ Watch: Most owners unaware of risky services running (2:00)

The research team systematically investigated five core research questions to pinpoint the causes of exposed IoT devices. Their findings provide a comprehensive picture, largely attributing the problem to manufacturers rather than device owners.

Research Question 1: Are device owners aware of their devices running risky services?

To answer this, the researchers conducted a questionnaire survey targeting owners of devices with Telnet or FTP enabled. The results indicated a significant lack of awareness: only 2% of owners of Telnet-enabled devices and 12% of owners of FTP-enabled devices were aware that these services were running. This clearly demonstrated that most owners were unaware of the risky services operating on their devices, suggesting that the exposure is not due to intentional configuration by users.

Research Question 2: Are they willing to take measures if they are not willing, why not?

Following the awareness survey, the team conducted security notifications to device owners and measured the remediation rate. For Telnet-enabled devices, 37% of owners were willing to take measures, and for FTP-enabled devices, 47% of owners were willing. The researchers confirmed that most of these devices were indeed remediated. However, for those unwilling or unable to take action, the most common reason cited was "insecure device specification," meaning the device's design did not provide an option for owners to turn off the risky services. This finding is crucial, as it highlights a fundamental design flaw imposed by manufacturers.

Research Question 3: Do device manuals inform device owners about the presence of these risky services?

To investigate this, the team analyzed device manuals for descriptions of Telnet and FTP, as well as general security advice. They identified that many device models lacked any description of Telnet or FTP in their manuals. Furthermore, most manuals also failed to provide adequate security advice. The answer to this question was a definitive "no," indicating a failure by manufacturers to properly inform users about potential security risks.

Research Question 4: What are the manufacturer's intentions for including insufficiently disclosed services?

A questionnaire survey was conducted with device manufacturers to understand their perspective. Manufacturers were indeed aware of the inclusion of Telnet and FTP services. They stated that Telnet was typically used for device management, while FTP was included in devices like printers for uploading files. Despite this awareness, the manufacturers failed to provide security information about these services, either in their manuals or through other channels. This points to a conscious decision to include risky services without adequately addressing their security implications for end-users.

Research Question 5: What risks are posed to the devices running and undisclosed risky services?

To assess the practical risks, the team performed penetration tests against seven IoT devices. The tests revealed critical vulnerabilities:

• Both Telnet and FTP services could often be accessed using the same default password as the device's web interface, signifying a weak security posture and poor credential management.
• Via Telnet, devices allowed for configuration changes, which could lead to unauthorized alterations of device settings.
• Most alarmingly, one specific device allowed the reading and writing of arbitrary files with root privileges through Telnet. This represents a severe vulnerability, potentially allowing complete compromise of the device and lateral movement within the network.

These findings confirmed that the exposed services posed actual, significant risks, ranging from unauthorized access to full system compromise.

In conclusion, the cumulative evidence from network measurements, owner surveys, manual analysis, manufacturer surveys, and penetration testing strongly points to the responsibility of manufacturers rather than device owners for the widespread exposure and insecurity of IoT devices.

Technical Deep Dive

▶ Watch: Device manuals lacked risky service descriptions (3:10)

The technical depth of this research is rooted in its multi-pronged investigative methodology, designed to systematically uncover the causes of exposed IoT devices. The study began with a foundational network scan of a Class B campus network, which is a critical initial step for any large-scale security assessment. A Class B network, with its capacity for over 65,000 hosts, represents a significant attack surface and a diverse collection of devices. The scan specifically targeted the presence of two legacy, yet commonly found, risky services: Telnet (TCP port 23) and FTP (TCP port 21). The identification of 220 hosts running these services, with 185 confirmed as IoT devices, immediately highlighted the scale of the problem. Telnet, transmitting data in plaintext, is notorious for exposing credentials and session information, making it a severe security risk. FTP, while useful for file transfer, often suffers from similar plaintext credential issues or insecure configurations allowing anonymous or weakly authenticated access.

Following the initial discovery, the research moved into a detailed analysis phase:

1. Device Owner Surveys (RQ1 & RQ2): For the devices identified with Telnet or FTP, the researchers conducted questionnaire surveys with the device owners. This qualitative data collection was crucial for understanding user awareness and intent. The low awareness rates (2% for Telnet, 12% for FTP) underscore a significant information asymmetry: users are largely unaware of the underlying services running on their devices. This immediately shifts the focus away from user negligence as the primary cause.

1. Security Notifications and Remediation Rate Measurement (RQ2): To further assess owner agency, the team issued security notifications to owners. This practical intervention measured their willingness and ability to remediate the vulnerabilities. The remediation rates (37% for Telnet, 47% for FTP) demonstrate that a substantial portion of owners are willing to take action when informed. However, the critical insight came from those who could not remediate: the most common reason was "insecure device specification." This points to firmware or hardware limitations where manufacturers simply do not provide the option to disable these services, effectively locking users into an insecure state. This is a profound technical limitation imposed by design.

1. Device Manual Analysis (RQ3): The researchers then undertook an analysis of device manuals. This involved systematically reviewing documentation provided by manufacturers to see if they disclosed the presence of Telnet or FTP, or offered any security advice. The finding that "many models did not have descriptions of Telnet or FTP in the manuals" and "most of devices did not have descriptions of security advice" reveals a significant failure in manufacturer responsibility. From a technical communication standpoint, this omission directly contributes to user unawareness and inability to secure their devices.

1. Manufacturer Surveys (RQ4): To understand the manufacturers' perspective, the team conducted a questionnaire survey of device manufacturers. This revealed that manufacturers were aware of including Telnet and FTP. Telnet was typically for device management, suggesting an internal or administrative backdoor often left open. FTP was used for specific functions like file uploading on printers. Critically, manufacturers "failed to provide security information about the services," indicating a conscious decision to prioritize functionality or ease of internal management over user-facing security disclosure. This highlights a deliberate, albeit insecure, design choice.

1. Penetration Testing (RQ5): The most direct technical deep dive involved penetration testing against seven IoT devices. This hands-on assessment validated the practical exploitability of the exposed services. Key technical vulnerabilities identified included:

• Shared Default Passwords: The discovery that Telnet and FTP could be accessed using the same default password as the device's web interface is a severe security misconfiguration. This means a single compromise of the web interface (e.g., via a brute-force attack or credential stuffing using common default credentials) immediately grants access to other, often more powerful, services. This violates the principle of least privilege and robust credential management.
• Configuration Changes via Telnet: The ability to perform "configuration changes" via Telnet exposes devices to unauthorized modifications of operational settings, potentially leading to denial-of-service, redirection of data, or further compromise.
• Arbitrary File Access with Root Privileges: The most critical finding was on one device that allowed "reading and writing of arbitrary files with root privileges" via Telnet. Root privileges grant full control over the operating system, allowing an attacker to install malware, exfiltrate sensitive data, modify firmware, or use the device as a pivot point for attacking other systems on the network. This represents a complete system compromise and highlights an egregious security flaw in the device's design and default configuration.

The culmination of these technical investigations definitively demonstrated that the insecure state of these IoT devices is primarily a consequence of manufacturer design choices, poor documentation, and a lack of secure defaults, rather than user error or negligence.

Demo / Proof of Concept

▶ Watch: Manufacturers aware but failed to provide security info (3:40)

While the talk description doesn't explicitly mention a live "demo" in the traditional sense, the research included a critical phase of penetration testing that served as a robust proof of concept for the vulnerabilities identified. This practical demonstration of exploitability is crucial for validating theoretical risks and highlighting the tangible dangers posed by exposed IoT devices.

The researchers conducted penetration tests against seven distinct IoT devices that had been identified with risky services. This hands-on, ethical hacking approach allowed them to move beyond simply detecting open ports to actively attempting to exploit the services and understand the potential impact.

The findings from these penetration tests served as a direct demonstration of the security risks:

1. Shared Default Credentials: The tests consistently revealed that Telnet and FTP services could often be accessed using the same default password that was used for the device's web interface. This is a critical security flaw. An attacker who discovers or guesses the web interface password (which are often weak or publicly known defaults) would immediately gain access to other, potentially more powerful, services like Telnet and FTP. This demonstrates a fundamental breakdown in credential separation and secure default configurations. For example, if a device's web admin panel defaults to "admin/admin," the penetration test showed that these same credentials could grant access via Telnet, providing a command-line interface to the device.

1. Unauthorized Configuration Changes via Telnet: The penetration tests successfully demonstrated that, once authenticated (often with default credentials), an attacker could initiate configuration changes via Telnet. This capability allows an adversary to alter device settings, potentially disabling security features, changing network parameters, or redirecting traffic. For instance, an attacker could change DNS settings, modify firewall rules, or even reset the device to factory defaults, causing disruption or further compromise.

1. Arbitrary File Access with Root Privileges: The most severe finding from the penetration tests was the discovery that one specific device allowed the reading and writing of arbitrary files with root privileges through Telnet. This is a critical remote code execution (RCE) vulnerability, effectively providing an attacker with complete control over the compromised device. With root access, an attacker could:

• Install malicious software: Deploy backdoors, botnet agents, or ransomware.
• Exfiltrate sensitive data: Access configuration files, user data, or other proprietary information stored on the device.
• Modify firmware: Permanently alter the device's operating system, making it difficult to detect or remove the compromise.
• Pivot to other systems: Use the compromised IoT device as a beachhead to launch attacks against other devices or networks within the academic environment.

These findings from the penetration tests serve as concrete proof-of-concept for the severe risks associated with exposed and insecure IoT devices. They move beyond theoretical concerns to demonstrate the real-world impact of manufacturers' insecure design choices, validating the necessity of addressing these foundational security flaws.

Defensive Implications

▶ Watch: Conclusion: Manufacturers, not owners, are responsible (4:20)

The findings of this research carry significant defensive implications for various stakeholders, from individual device owners and network administrators to the broader cybersecurity community and IoT manufacturers. The primary takeaway is a necessary shift in focus from solely blaming end-users to holding manufacturers accountable for their role in the IoT security crisis.

For Network Administrators and Security Teams:

1. Proactive Network Scanning: Network administrators, especially in environments like academic institutions or enterprises with diverse device populations, must regularly scan their networks for exposed risky services like Telnet and FTP. Automated tools and regular vulnerability assessments are essential to identify these "open doors."
2. Network Segmentation: Implementing robust network segmentation is paramount. IoT devices should be isolated into dedicated network segments (e.g., VLANs) that are separate from critical infrastructure and sensitive data. This limits the blast radius of a compromised IoT device, preventing it from being used as a pivot point for attacks on other parts of the network.
3. Strict Egress Filtering: Even if Telnet or FTP are necessary for specific devices, outbound connections from IoT segments should be strictly controlled via egress filtering. This prevents compromised devices from phoning home to command-and-control servers or launching attacks outwards.
4. Default Credential Management: Implement policies to enforce the change of all default passwords immediately upon device deployment. Utilize strong, unique passwords for each device and service. Regular audits should check for the presence of default or weak credentials.
5. User Education and Awareness: While manufacturers bear primary responsibility, user education remains important. Inform users about the risks of IoT devices, the importance of changing default passwords, and the need to report suspicious device behavior. However, acknowledge that many devices offer no user control over risky services.
6. Incident Response Planning: Develop specific incident response plans for compromised IoT devices, including procedures for isolation, forensic analysis, and remediation, especially considering the potential for root-level compromise.

For IoT Device Owners:

1. Research Before Purchase: Prioritize purchasing IoT devices from manufacturers with a strong reputation for security, clear privacy policies, and a commitment to regular firmware updates.
2. Change Default Passwords: Always change default usernames and passwords immediately after setting up a new device. Use strong, unique credentials.
3. Disable Unnecessary Services: If the device allows, disable any services like Telnet or FTP that are not explicitly required for its functionality.
4. Check Manuals and Support: Review device manuals for security information. If manuals are inadequate, contact manufacturer support to inquire about security best practices or ways to disable risky services.
5. Network Configuration: If technically capable, configure your home router or network to block inbound access to your IoT devices from the internet, and consider guest networks for IoT devices if available.

For IoT Manufacturers (Primary Responsibility):

1. Secure by Design: Adopt a "security by design" philosophy, making security a foundational requirement from the earliest stages of product development, not an afterthought.
2. Disable Risky Services by Default: Telnet and FTP (especially insecure variants) should be disabled by default. If essential for specific functions, they should be explicitly enabled by the user with strong warnings, or replaced with secure alternatives (e.g., SSH, SFTP, HTTPS).
3. Separate Credentials: Implement separate, strong, and unique default credentials for different services (e.g., web interface, Telnet, SSH). Never use the same default password across multiple interfaces.
4. Clear Security Documentation: Provide comprehensive and easily understandable security documentation in device manuals and online resources. This includes disclosing all running services, explaining their purpose, outlining potential risks, and providing clear instructions on how to secure or disable them.
5. Enable User Control: Design device specifications that allow owners to easily manage and disable unnecessary services. Do not lock users into insecure configurations.
6. Regular Firmware Updates: Establish a robust process for delivering regular firmware updates that address newly discovered vulnerabilities and improve security features.
7. Threat Modeling and Penetration Testing: Conduct thorough threat modeling and independent penetration testing of devices before release to identify and remediate vulnerabilities, especially those that grant root access or arbitrary file manipulation.

By addressing these defensive implications, particularly by pressuring manufacturers to adopt more secure practices, the overall security posture of IoT ecosystems can be significantly improved, reducing the widespread exposure and risks highlighted by this critical research.

Key Takeaways

• Widespread IoT Exposure: Academic networks, and likely other diverse environments, exhibit a significant presence of exposed IoT devices running risky services like Telnet and FTP, with 185 IoT devices found among 220 vulnerable hosts in one Class B network scan.
• Low Owner Awareness: Most device owners are largely unaware (only 2% for Telnet, 12% for FTP) that their devices are running these insecure services, indicating that user negligence is not the primary cause of exposure.
• Manufacturer Responsibility: The research conclusively points to manufacturers as the primary culprits, due to insecure device specifications that prevent owners from disabling services, inadequate security documentation in manuals, and the inclusion of risky services for management or functionality without sufficient security disclosures.
• Insecure Device Specifications: A significant portion of devices (37% Telnet, 47% FTP remediation rates, with "insecure device specification" as the main reason for non-remediation) do not allow owners to turn off risky services, forcing them into an insecure default state.
• Critical Vulnerabilities Demonstrated: Penetration tests revealed severe risks, including the use of shared default passwords for web interfaces, Telnet, and FTP, allowing for easy compromise. Most alarmingly, one device allowed arbitrary file reading and writing with root privileges via Telnet, enabling complete system takeover.
• Urgent Need for Secure by Design: There is an urgent need for IoT manufacturers to adopt "security by design" principles, disabling risky services by default, providing clear security documentation, implementing separate credentials, and allowing users granular control over device security settings to prevent such widespread vulnerabilities.

About the Speaker(s)

The research presented was a collaborative effort by Takayuki Sasaki, Takaya Noma, Yudai Morii, Toshiya Shimura, Michel van Eeten, and Katsunari Yoshioka. While specific titles and affiliations beyond their names are not provided in the talk metadata or transcript, their presentation at the IEEE S&P conference, a premier venue for computer security and privacy research, indicates that they are highly regarded researchers and experts in the field of cybersecurity, likely affiliated with academic institutions or research organizations focusing on network security, IoT security, and related areas. Their work demonstrates a deep understanding of practical network security challenges and a rigorous scientific approach to investigating complex cybersecurity problems.