Root Shells via Shell Scripts: Anatomy of the BulletLTE-NA2 Vulnerabilities

TLDR: This research exposes how industrial IoT devices often rely on fragile, insecure shell scripts for core management functions, leading to trivial remote code execution. By analyzing the BulletLTE-NA2, the researcher demonstrated multiple post-authentication command injection flaws and a buffer overflow that bypasses basic security controls. Pentesters should prioritize auditing the underlying shell-based CGI scripts on similar embedded devices, as these are frequently overlooked by automated scanners.

Industrial IoT security remains a graveyard of poor design choices, where the convenience of rapid development often overrides basic security hygiene. When we look at devices like the BulletLTE-NA2, we are not just looking at a piece of hardware; we are looking at a collection of legacy components held together by shell scripts running with root privileges. This specific device, used across critical infrastructure sectors like oil and gas, serves as a perfect case study for why "security through obscurity" is a failed strategy. When a device’s entire management interface is essentially a wrapper for shell commands, any input sanitization failure becomes a direct path to a root shell.

The Fragility of Shell-Based Management

The core issue with the BulletLTE-NA2 web management portal is its architectural reliance on shell scripts to handle system configuration. The device uses uhttpd to serve a web interface that triggers backend scripts for tasks like network configuration, firewall management, and service monitoring. Because these scripts execute directly in the shell, they are inherently susceptible to Injection attacks if user input is not rigorously validated.

During the audit, it became clear that the developers attempted to sanitize input for specific parameters, such as the hostname, but completely neglected others. The diagnostic page, which implements standard utilities like ping and traceroute, is a prime example. By manipulating the count parameter, an attacker can inject arbitrary commands. Since the web server runs as root, the payload executes with full system privileges.

Consider the following command injection pattern observed during the research:

# Injecting a command into the count parameter
127.0.0.1; [command_to_execute]

This is not a sophisticated exploit. It is a fundamental failure to treat user-supplied data as untrusted. For a pentester, this means that any field in a web management portal that interacts with system-level binaries is a high-value target. If you encounter a device that allows you to trigger network diagnostics, your first step should always be to test for command injection using basic shell metacharacters like ;, &&, or |.

Authentication Bypasses and Buffer Overflows

Beyond command injection, the research uncovered a critical Buffer Overflow in the authentication header handling. The device uses a custom logout mechanism that sets a Basic authentication header. The developers, attempting to implement a specific logout string, used strcpy() to copy the decoded Base64 string into a statically-sized buffer without performing any bounds checking.

This is a classic memory corruption vulnerability. By sending a crafted Authorization header that exceeds the buffer size, an attacker can overwrite adjacent memory. While the device employs ASLR, the implementation is incomplete, randomizing only the top portion of the memory space. This allows for brute-force attempts to guess the base address of libc, eventually leading to successful code execution.

The vendor’s response to these findings, documented in CVE-2020-17406 and CVE-2020-17407, highlights a recurring problem in the industry: the "miscellaneous housekeeping" patch. The vendor removed the vulnerable AT+MBASHCMD command but failed to address the systemic issues in the underlying shell script architecture. This is why we see the same vulnerabilities reappear in subsequent firmware versions.

Practical Implications for Pentesters

When you are on an engagement involving industrial hardware, do not rely solely on automated vulnerability scanners. These tools often miss custom, script-based interfaces. Instead, perform a manual analysis of the firmware. Use binwalk to extract the filesystem and search for CGI scripts or shell scripts that handle user input. If you find a script that calls system() or popen() with unsanitized variables, you have found your entry point.

The impact of these vulnerabilities is severe. In an industrial environment, gaining root access to a cellular bridge allows an attacker to intercept traffic, pivot into the internal network, or disrupt critical operations. The fact that these devices are often deployed in remote, hard-to-reach locations makes them even more attractive targets for long-term persistence.

Defensive Strategies

Defenders must move away from the assumption that internal management interfaces are safe. If a device is reachable via the WAN, it should be treated as a public-facing application. Disable unnecessary services, enforce strict firewall rules, and monitor for anomalous traffic patterns originating from the device itself. Most importantly, demand transparency from vendors. Vague release notes that hide the nature of security patches are a red flag. If a vendor cannot explain what a patch fixes, assume the vulnerability is still present or that the fix is incomplete.

If you are working with these devices, start by auditing the AT command interface. Many of these modems have undocumented commands that provide shell-like access. If you find an AT+ command that executes shell utilities, you are likely only one step away from a full system compromise. Keep digging, and always verify the vendor's claims of "security improvements" for yourself.