Demonstration of a POC exploit created by OTORIO researchers
InHand Networks is a prominent player in the Industrial IoT industry. They specialize in offering a wide range of products such as industrial M2M routers, gateways, industrial Ethernet switches, industrial computers, and IoT management platforms. Their solutions can be found in different sectors, including Smart Grid, Industrial Automation, Remote Machine Monitoring, Smart Vending, Smart City, and Retail.
Device Manager, developed and operated by InHand Networks, is a cloud-based platform for M2M/IoT device management. It provides a user-friendly interface and simple operation steps, allowing users to conveniently manage and monitor InHand's hardware devices like industrial cellular routers and gateways. With just a few clicks, these devices can be easily integrated and managed on the Device Manager platform. Supported devices include: InRouter200, InRouter300, InRouter600, InRouter900, InGateway900, InGateway500, InVehicleG710, InVehicleG810.
“Device Manager” cloud management platform
During our research, we focused on the InRouter615-S model, which belongs to the InRouter600 series. The InRouter600-S (also known as IR600-S) is a series of IoT routers that provide support for 3G/4G, Wi-Fi, and VPN. These routers enable easy network access for field devices, utilizing 3G/4G wireless WAN and Wi-Fi wireless LAN technologies.
InRouter600 industrial cellular routers
InRouter and “Device Manager” communication
During the router's boot process, a weak registration occurs with the "Device Manager" platform, where the router's serial number is sent along a "Device Manager" cloud account. If both the account and serial number are valid, the "Device Manager" assigns the device to the account and sends MQTT credentials. The device then establishes an immediate connection to the "Device Manager" using these MQTT credentials.
The "Device Manager" MQTT Broker maintains two primary MQTT topics for each cloud-connected router:
The 'id' in the topic name (also named ‘client_id’) is a 24-character hexadecimal string that distinguishes between the topic names of different routers and changes for each new session.
InRouter device connection to “Device Manager” cloud
Upon connecting with MQTT, the "Device Manager" promptly sends the 'Get Config' task, and the devices respond by publishing their configuration files.
Use of Insufficiently Random Values (CVE-2023-22601)
To delve deeper into the registration process, we implemented a Python script to perform repeated registrations at regular intervals. Through data analysis, we uncovered an interesting pattern: the first 8 hexadecimal characters in the registration data corresponded to the timestamp of each registration, while the second part of the data incremented by 2 with each new registration.
Next, we conducted additional registrations with a 5-minute interval between each attempt. During this analysis, we observed that the second part of the device's ID increased by 4 between the second and third registration. This finding indicated the presence of a real device connected to the cloud. With a time window of 300 seconds (5 minutes) for the first part of the device's ID and the known value of 472 for the second part, we narrowed down the possibilities, making IDs for other devices easily predictable.
Double incrementation - additional device connected to the cloud
Improper access control (CVE-2023-22600)
After attempting to subscribe to all 300 available options for the 'v1/id/task/update' MQTT topic name, which the router utilizes to publish task results, we managed to hit the correct id after 175 attempts. This enabled us to access and retrieve the device's configuration file. Encouraged by this breakthrough, we further validated our capabilities by successfully modifying the hostname.
175 attempts leading to successful configuration leak and modification
OS command injection (CVE-2023-22598)
To achieve 'remote code execution,' we proceeded with an in-depth exploration of the InRouter firmware, specifically focusing on the functions responsible for parsing the device configurations. After extracting and thoroughly examining the firmware, we made a significant discovery. Within the code, we identified a critical 'command injection' vulnerability. This flaw resided in the function associated with handling the 'auto_ping' parameter of the device configuration.
Upon closer inspection, we found that when the 'auto_ping_enable' parameter is set to '1', the ping_action_start function is triggered. This function concatenates the string from the 'auto_ping_dst' parameter with a ping command, enabling the device to perform internet connectivity checks.
Exploiting the lack of IP address input validation in the 'auto_ping_dst' parameter, we appended a 'reverse shell' command, leading to remote code execution with root privileges. This exploit involved modifying the relevant parameters and transmitting the updated configuration using the 'SET config' task.
Exploitation of OS command injection
By chaining these vulnerabilities together, we were able to target a specific device using its serial number or randomly target devices connected to the cloud. However, to ensure the safety of real environments, our focus was solely on demonstrating an attack against our own device, exclusively targeting its specific serial number.
Taking advantage of the flawed registration mechanism, we developed a script that impersonates our router and initiates registration with the "Device Manager" using the router's identifiers. Throughout this process, we closely monitored the response from the "Device Manager," with particular attention to analyzing the second part of the 'id' parameter.
As a result of this operation, the original router is automatically re-registered, leading to an increase of more than 2 in the second part of the 'id' parameter compared to the previous registration. This indicates the presence of another device that has successfully registered with the cloud.
Subsequently, our script systematically subscribes to all 300 possible topics for the re-registered device until it identifies the correct topic. Once the correct topic is located, the "Device Manager" publishes the most recent message sent by the genuine router to that specific topic, which contains the configuration file. To ensure the device matches our expectations, we perform a verification step.
Upon verification, we modify the 'auto_ping' configuration parameter by adding the 'reverse shell' command, and then publish the updated configuration file back to the router using the 'SET config' task. Compromised device automatically reboots and initiates a remote shell with root privileges.
InHand Networks mitigated the cloud vulnerabilities in addition to an updated firmware version. InHand recommends users update affected device firmware to the most recent version:
The U.S. Cybersecurity and Infrastructure Security Agency (CISA) published an advisory to inform organizations about the vulnerabilities.
We appreciate the professional manner in which InHand Networks disclosed the vulnerabilities and the coordination of CISA.