MicroHard More Like MicroEasy to Exploit

MicroHard More Like MicroEasy to Exploit

Speakers: Ricky Lawshae, Principal Security Researcher, Keysight Technologies

Conference: DEF CON 32

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

Overview

In "MicroHard More Like MicroEasy to Exploit," Ricky Lawshae, a Principal Security Researcher at Keysight Technologies, dissects the significant security vulnerabilities present in Microhard's Bullet LTE-NA2 cellular bridge. The talk exposes a range of critical flaws, from easily forgeable firmware to a chatty discovery protocol that leaks sensitive device information. This presentation serves as a stark warning regarding the security posture of devices often deployed in critical infrastructure and industrial control environments.

The Microhard Bullet LTE-NA2 is marketed as a robust solution for adding cellular connectivity to legacy and modern serial and Ethernet devices, enabling remote management in diverse sectors such as power utilities, unmanned vehicles, and other industrial installations. Lawshae's investigation, initially prompted by a security audit for a utility company, revealed that despite its critical applications, the device harbors fundamental security weaknesses that could allow attackers to gain deep control, compromise operations, or exfiltrate sensitive data.

The implications of these findings are substantial. For organizations relying on Microhard devices, or similar IoT/OT hardware, the talk underscores the urgent need for comprehensive security assessments and robust defensive strategies. It highlights how seemingly minor security oversights in device design can lead to widespread exposure and potential operational disruption, making "Microhard" indeed "Microeasy to Exploit" for determined adversaries.

Background

▶ Watch: Introduction: Microhard, Microeasy to Exploit (0:00)

Microhard, a Canadian-based manufacturer, specializes in cellular bridges designed to provide remote access for Ethernet and serial devices across various industries. Their products are positioned for use in environments where reliability and remote management are paramount, including critical sectors like power utilities and unmanned vehicle operations. The specific device under scrutiny in this talk is the Bullet LTE-NA2, a North American variant of their LTE bridge line, intended to connect any device, old or new, to cellular networks for remote monitoring and control.

Lawshae's journey into auditing the Bullet LTE-NA2 began during a security assessment for a utility company considering deploying a large number of these devices. His findings were so concerning that he ultimately recommended against their field deployment. This context is crucial, as it highlights the real-world impact of insecure IoT devices on critical infrastructure and the necessity of proactive security vetting.

From a hardware perspective, the Bullet LTE-NA2 is built around a 32-bit ARM Cortex-A5 processor. It features 128MB of expansion flash firmware storage, notably with the entire filesystem being read-write, and 256MB of RAM. The device also integrates a Quectel EC25-AF modem and offers various connectivity options including a SIM card slot, Power over Ethernet (PoE), standard Ethernet, USB, and serial ports, alongside programmable I/O.

The firmware architecture contributes significantly to the device's vulnerability. Firmware updates are completely unsigned and unencrypted, allowing for easy forging and flashing of custom firmware. Lawshae noted that the firmware images were also easily extractable using tools like Binwalk, revealing a full SquashFS file system, the Linux kernel, and the bootloader. This level of access means the entire system can be readily emulated for analysis and exploit development.

The device's operating system is loosely based on OpenWrt, running an older Linux 3.6.9 kernel. The version demonstrated by Lawshae utilized UHTTPD for its web interface, though subsequent versions reportedly switched away from it, implying security concerns with UHTTPD were identified. For remote access, the device employs Dropbear for SSH and TelnetD for Telnet. Interestingly, when users log in via these services, they are dropped into a "jailed debug environment," an attempt to limit system access, though the effectiveness of such jails often varies. This combination of an old kernel, an implied vulnerable web server, and easily modifiable firmware creates a fertile ground for exploitation, underlining why such a device posed a significant risk for the utility company.

Key Findings

▶ Watch: Bullet LTE-NA2 device and failed security audit (2:00)

Ricky Lawshae's deep dive into the Microhard Bullet LTE-NA2 uncovered several critical security vulnerabilities and design flaws that collectively render the device highly susceptible to compromise. These findings underscore a significant lack of security best practices in its development and deployment.

1. Unsigned and Unencrypted Firmware Updates: Perhaps the most egregious vulnerability is the complete absence of cryptographic signing or encryption for firmware updates. This means an attacker can easily forge malicious firmware, modify existing legitimate firmware, and flash it onto the device without any integrity checks. This capability grants an attacker full control over the device's operating system and functions, enabling persistent backdoors, data exfiltration, or complete device bricking.

1. Easy Firmware Extraction and Analysis: The firmware images are readily extractable using common tools like Binwalk. Once extracted, they reveal the full SquashFS file system, the Linux kernel, and the bootloader. This ease of access allows attackers to thoroughly analyze the device's internal workings, identify further vulnerabilities, and even fully emulate the system, significantly accelerating exploit development.

1. Entire Filesystem is Read-Write: The device's 128MB flash storage allows for the entire filesystem to be read-write. While this might simplify certain administrative tasks, it also means that if an attacker gains even limited access (e.g., through a web vulnerability or an insecure service), they can achieve persistence by modifying system files or injecting malicious code directly onto the filesystem.

1. Insecure and Chatty Discovery Protocol: The device implements a proprietary UDP-based broadcast discovery protocol that operates on specific ports: 20777 (for 3G devices), 20877 (for IP-based devices), and 20977 (for LTE devices, relevant to the Bullet LTE-NA2). When probed with a "magic probe" packet, the device responds with a wealth of sensitive information, including its MAC address, IP address, hostname, SSID (if applicable), model name, and crucially, its firmware version. It also leaks the NMS (Network Management Software) domain and password hash, though this specific aspect was not the focus of Lawshae's talk. This information leakage provides attackers with valuable reconnaissance data, enabling them to identify vulnerable devices and tailor attacks.

1. Outdated Software Stack with Implied Vulnerabilities: The device runs on an older Linux 3.6.9 kernel, which was released around 2012. Such an old kernel is highly likely to contain numerous unpatched vulnerabilities that could be exploited for privilege escalation or remote code execution. Furthermore, the use of UHTTPD for the web server in the demonstrated version, with the speaker noting its replacement in later versions, strongly implies that UHTTPD was found to have security flaws or was replaced due to general security concerns, presenting another potential attack vector.

1. Jailed Debug Environment: While intended as a security feature, the "jailed debug environment" for SSH and Telnet users often presents its own set of challenges. Such environments, if not implemented perfectly, can be susceptible to jailbreaking techniques, allowing an attacker to escape the restricted shell and gain full root access to the underlying Linux system.

These key findings paint a picture of a device with significant foundational security weaknesses, making it a prime target for adversaries and posing considerable risk to any critical infrastructure deploying it.

Technical Deep Dive

▶ Watch: Hardware vulnerability: Entire filesystem is read-write (2:50)

The technical vulnerabilities identified in the Microhard Bullet LTE-NA2 stem from a combination of hardware design choices, firmware implementation oversights, and an outdated software stack. Understanding these details is crucial for grasping the full extent of the device's insecurity.

The device's core is a 32-bit ARM Cortex-A5 processor, a common choice for embedded systems. It includes 128MB of flash storage for firmware and 256MB of RAM. A critical detail here is that the entire filesystem on the flash storage is read-write. This is a significant security flaw; in many secure embedded systems, the root filesystem is mounted read-only to prevent unauthorized modification and maintain system integrity. A read-write filesystem, especially without robust integrity checks, means that any vulnerability leading to arbitrary file write access can be used to achieve persistent compromise, such as injecting malicious scripts into startup routines or replacing critical binaries.

Firmware management is a major area of concern. Firmware updates for the Bullet LTE-NA2 are unsigned and unencrypted. This means there are no cryptographic checks to verify the authenticity or integrity of the firmware image before it is flashed. An attacker can download legitimate firmware, modify it (e.g., add a backdoor, change default credentials, disable security features), and then upload the modified firmware to the device. The device will accept and flash this malicious firmware as if it were legitimate. This vulnerability bypasses almost all other software-level protections, as the attacker effectively gains control over the entire operating system. Lawshae confirmed that the firmware images are easily extractable using tools like Binwalk, revealing the bootloader, Linux kernel, and a complete SquashFS file system. The ability to extract and analyze these components offline allows for comprehensive vulnerability research and the development of custom malicious firmware. The speaker also mentioned that this ease of extraction allows for full system emulation, which significantly aids in exploit development and testing without needing physical access to multiple devices.

The software stack further compounds the security risks. The OS is based "loosely" on OpenWrt, running an antiquated Linux 3.6.9 kernel. This kernel version dates back to 2012, meaning it predates a decade's worth of security patches and vulnerability disclosures. It is highly probable that publicly known vulnerabilities affecting the Linux kernel (e.g., privilege escalation exploits, remote code execution flaws in network stacks) are present and exploitable on this device. For the web interface, the version demonstrated by Lawshae used UHTTPD. The speaker's remark that Microhard "changed to that in the subsequent version and you'll see why they why they decided to change it" strongly suggests that security flaws were discovered or implied in UHTTPD, making it a likely vector for web-based attacks such as command injection, cross-site scripting (XSS), or authentication bypasses. Remote access is provided via Dropbear for SSH and TelnetD for Telnet. While Dropbear is generally more secure than Telnet, the device's configuration drops users into a "jailed debug environment." While this is an attempt to limit access, such jails are frequently found to have bypasses, allowing a determined attacker to escape into a full root shell.

The discovery protocol is another critical technical finding. It's a proprietary UDP-based broadcast mechanism that listens on specific ports:

• UDP port 20777 for 3G devices.
• UDP port 20877 for IP-based devices.
• UDP port 20977 for LTE devices, which is the relevant port for the Bullet LTE-NA2.

An attacker can send a "magic probe" broadcast packet (the content of which is consistent across device types) to these ports. The device then responds, leaking a significant amount of reconnaissance information. This includes the device's MAC address, IP address, hostname, SSID (if wireless is enabled), model name (e.g., "Bullet LTE-NA2"), and its precise firmware version. The firmware version is particularly valuable, as it allows attackers to cross-reference with known vulnerabilities (e.g., CVEs) for that specific version or kernel. Additionally, the response includes the NMS (Network Management Software) domain and password hash, a direct information disclosure of credentials, although Lawshae explicitly stated he would not delve into NMS itself in this particular talk. Lawshae noted an "annoying" aspect for scanners: the device responds from a random source port on its side to the broadcast address, making correlation of responses slightly more complex but not preventing data collection. This broadcast behavior means any device on the local network segment can easily discover and profile Microhard devices, providing a low-effort entry point for targeted attacks.

Demo / Proof of Concept

▶ Watch: Jailed debug environment for SSH and Telnet (4:40)

During the talk, Ricky Lawshae presented a clear demonstration of the Microhard discovery protocol's vulnerability by showcasing a custom scanner he developed. This proof of concept effectively illustrated how easily these devices can be identified and how much sensitive information they readily disclose.

The demonstration involved Lawshae's scanner, written to interact with the proprietary UDP-based discovery protocol. The scanner's function is straightforward: it sends broadcast UDP messages to the specific ports that Microhard devices listen on. As detailed in the technical deep dive, these ports are 20777 for 3G devices, 20877 for IP-based devices, and 20977 for LTE devices (the Bullet LTE-NA2 falls into this category). The scanner transmits the "magic probe" packet, which is consistent across Microhard's product line.

Upon receiving the broadcast probe, any Microhard device on the network segment responds. Lawshae presented a screenshot of his scanner's output, which clearly displayed the wealth of information gleaned from a responding device. This included:

• The device's MAC address, providing a unique hardware identifier.
• Its IP address, essential for direct targeting.
• The device's hostname, often indicative of its role or location.
• Any configured SSID, if wireless capabilities are in use.
• The specific model name (e.g., "Bullet LTE-NA2").
• Crucially, the exact firmware version, which is invaluable for identifying known vulnerabilities.
• Details about the NMS (Network Management Software) domain and password hash, though Lawshae noted he would not be discussing NMS in detail during this specific presentation.

The demonstration highlighted that while the Microhard device responds from a random source port to the broadcast address, which might complicate correlation for some network tools, it does not prevent an attacker from successfully gathering all the disclosed information. The ease with which this reconnaissance could be performed underscored the severity of this information leakage for any organization deploying these devices. While the talk did not include a live demonstration of flashing malicious firmware or exploiting a web vulnerability, the discovery protocol PoC effectively laid the groundwork, showing how an attacker could quickly identify targets and gather the necessary intelligence for subsequent, more sophisticated attacks based on the other identified vulnerabilities.

Defensive Implications

▶ Watch: Discovery protocol and leaked device information (5:00)

The vulnerabilities exposed in the Microhard Bullet LTE-NA2 carry significant defensive implications, particularly for organizations operating in critical infrastructure, industrial control systems (ICS), and operational technology (OT) environments. Defenders must implement a multi-layered security strategy to mitigate the risks posed by these devices.

1. Firmware Integrity and Supply Chain Security:

The lack of signed and encrypted firmware updates is the most critical flaw. Defenders must understand that any Microhard device in their network could potentially be running compromised firmware if an attacker gains network access.

• Vendor Engagement: Urge Microhard to implement robust firmware signing and encryption. Without this, the devices remain fundamentally insecure.
• Network Segmentation: Strictly segment networks to prevent unauthorized access to device management interfaces. Firmware updates should only be possible from highly trusted, isolated management networks.
• Source Verification: For any new deployments, critically assess the supply chain for integrity. The findings highlight the importance of independent security audits before deploying any IoT/OT device in sensitive environments.

1. Network Segmentation and Firewalling:

The chatty discovery protocol, which leaks sensitive device information, makes network segmentation paramount.

• Isolate OT/ICS Networks: Microhard devices, and all other OT/ICS hardware, should be strictly isolated from corporate IT networks and the internet. They should reside in dedicated network segments with controlled ingress/egress.
• Block Discovery Ports: Implement strict firewall rules at network boundaries to block UDP traffic to ports 20777, 20877, and 20977. This prevents external adversaries from discovering and profiling devices. Internal segmentation can further limit lateral movement and discovery within the OT network.
• Disable Unnecessary Services: Review device configurations to disable the discovery protocol if it's not strictly required for operational purposes. If it cannot be disabled, ensure it's restricted to trusted network segments.

1. Patch Management and Vulnerability Remediation:

The use of an outdated Linux 3.6.9 kernel and the implied vulnerabilities in UHTTPD necessitate a robust patch management strategy.

• Regular Updates: Ensure Microhard devices are kept up-to-date with the latest vendor-provided firmware. Given the vendor's past security posture, critical scrutiny of patch contents is advised.
• Vulnerability Scanning: Regularly scan OT/ICS networks for devices running outdated software versions or presenting known vulnerabilities.
• Compensating Controls: Where patching is not feasible due to operational constraints or vendor limitations, implement strong compensating controls such as intrusion detection/prevention systems (IDPS) and strict access controls around the devices.

1. Access Control and Authentication:

While not explicitly detailed in the talk snippet, the existence of SSH, Telnet, and a web interface implies the need for strong access controls.

• Strong Passwords/Authentication: Enforce strong, unique passwords for all device accounts and ensure multi-factor authentication (MFA) is used where available.
• Disable Telnet: Telnet is an insecure protocol that transmits credentials in plaintext. It should be disabled in favor of SSH.
• Review "Jailed" Environments: If SSH/Telnet access is required, scrutinize the "jailed debug environment" for potential bypasses. Limit user accounts to the absolute minimum necessary privileges.

1. Monitoring and Incident Response:

• Network Monitoring: Continuously monitor network traffic for unusual activity on the discovery ports, attempts to access management interfaces, or signs of unauthorized firmware updates.
• Logging: Ensure devices are configured to log security-relevant events and that these logs are collected and analyzed by a centralized security information and event management (SIEM) system.
• Incident Response Plan: Develop and regularly test an incident response plan specifically for OT/ICS environments, addressing scenarios involving compromised IoT devices.

Ultimately, the findings emphasize that security cannot be an afterthought for devices deployed in critical environments. Organizations must treat these devices with the same, if not greater, scrutiny as their traditional IT assets, implementing a defense-in-depth strategy to protect against exploitation.

Key Takeaways

• Microhard Bullet LTE-NA2 devices contain critical security vulnerabilities, including unsigned firmware and an insecure discovery protocol, making them "Microeasy to Exploit" in critical infrastructure.
• The complete lack of signed and encrypted firmware updates allows attackers to easily forge and flash malicious firmware, gaining full control over the device.
• A proprietary UDP-based discovery protocol (on ports 20777, 20877, 20977) leaks extensive sensitive information, including MAC address, IP address, firmware version, and NMS password hash, enabling efficient reconnaissance.
• The device runs on an outdated Linux 3.6.9 kernel and previously used UHTTPD for its web server, indicating a high likelihood of unpatched kernel vulnerabilities and web-based exploits.
• Comprehensive security audits, like the one conducted by Ricky Lawshae for a utility company, are essential to identify and mitigate significant risks in IoT/OT devices before widespread deployment.
• Defenders must implement robust network segmentation, strict firewall rules (blocking discovery ports), regular patching, and strong access controls to protect Microhard and similar devices in critical environments.

About the Speaker(s)

Ricky Lawshae, also known by his handle Headless Zeke, is a Principal Security Researcher at Keysight Technologies. Based out of Austin, Texas, Lawshae specializes in offensive IoT research, bringing a wealth of experience to the field. He has been professionally involved in security since 2009 and is a regular fixture on the conference circuit, having spoken at DEF CON five times on the main stages. This particular talk marked his first appearance at the IoT Village. Beyond his professional endeavors, Ricky Lawshae enjoys several hobbies, most of which, as he humorously notes, involve drinking whiskey.