Claroty’s Team82 reveals critical vulnerabilities in ConnectedIO edge routers, device platform
Claroty’s Team82 researchers uncovered and disclosed critical vulnerabilities in ConnectedIO ER2000 3G/4G edge routers that act as gateways, connecting IoT (Internet of Things) devices to the Internet. These vulnerabilities impact edge routers and cloud-based device management platform as well as the communication protocol connecting devices to the cloud. The research also pointed out that an attacker could have leveraged these flaws to fully compromise the cloud infrastructure, remotely execute code, and leak all customer and device information.
“ConnectedIO has provided firmware updates that address all of the vulnerabilities uncovered by Team82,” Noam Moshe, vulnerability researcher at Claroty, wrote in a company blog post. “Users are protected automatically as these updates were made to the cloud infrastructure and edge devices.”
Moshe detailed that the vulnerabilities disclosed “affect all unpatched devices, enabling attackers to execute arbitrary code on these devices without requiring direct access to them, or exposing them to the internet. In addition, we also discovered vulnerabilities that put ConnectedIO’s cloud platform at risk.”
He added that these vulnerabilities were disclosed to ConnectedIO, which has provided firmware updates that address all of the vulnerabilities. Users are protected automatically as these updates were made to the cloud infrastructure and edge devices.
To remediate these vulnerabilities, ConnectedIO has provided firmware updates that address all of the vulnerabilities uncovered by Team82. Users are protected automatically as these updates were made to the cloud infrastructure and edge devices.
ConnectedIO offers a host of connectivity solutions, focused on 4G-capable routers aimed at enabling IoT/IIoT devices to stay connected to the Internet. In its portfolio, ConnectedIO offers various 4G routers and modems, each with different communication capabilities and specifications.
Apart from the hardware, ConnectedIO offers a cloud-based SaaS platform for managing its devices that allows asset owners to control and monitor their devices. It also enables users to view data for their devices, change configurations, perform maintenance operations, and upgrade the device firmware automatically.
Moshe clarified that “at the outset of our research, we needed to understand how users claim their devices and how devices register and identify themselves to the cloud. While there are many methods through which devices can identify themselves to the cloud, ConnectedIO chose to rely on hardware identifiers burned into the device during its manufacturing: the device MAC address and IMEI number.”
Using these two identifiers, the device connects to the cloud and informs that it wants to connect, Moshe said. “ConnectedIO cloud then checks the parameters, making sure they match an actual device manufactured by ConnectedIO, and only if these two identifiers are correct will the cloud accept the connection. After understanding how devices identify themselves in front of the cloud, our next step was to understand how users are able to claim their devices, taking ownership, and gaining full control over their devices.”
Moshe detailed that to claim devices, a user must prove to the cloud they are indeed the rightful owner of the device. “To do so, ConnectedIO’s cloud requires the user to supply ‘secrets’ known only to the owner of the device: the serial number and IMEI of the device. Since this information is printed on the device label, located on the back of the device, it should only be known to people with physical access to the device itself.”
“While it is important to authenticate and validate the device, requiring it to supply ‘secrets’ only known to it before accepting it into the cloud, we noticed a reliance of manufacturers and vendors on using hardware identifiers of MAC address and IMEI/serial number,” the post added. “These identifiers should not be used to authenticate/claim devices because they are not cryptographically secure and could be easily guessed by attackers.”
The researchers then moved on to understand how the device connects to the cloud and establishes a secure communication channel between itself and the cloud.
“We started by extracting the device’s firmware, which we managed to find inside ConnectedIO’s cloud platform,” Moshe wrote. “Extracting the firmware was straightforward because ConnectedIO did not implement a firmware packing/encryption mechanism. Instead, we simply used binwalk to extract the firmware contents, giving us access to the device’s file system.”
The team then looked for URLs and IP addresses that could be associated with ConnectedIO’s cloud. “Our goal was to understand the exact communication protocol ConnectedIO chose to implement for their device-cloud communication. We discovered a URL pointing to ConnectedIO’s cloud inside a configuration file and an executable,” the post added.
“Inside this script, the router sets up the MQTT configuration for the device, including the URL, username, and password,” the research disclosed. “Then, it starts the ‘cioClient’ binary, which handles the actual cloud communication. However, even before researching the ‘cioClient’ binary, we already can infer that the device communicates with the cloud using MQTT.”
After understanding that the device communicates with the cloud using MQTT, the next goal of the Claroty researchers was to understand which topics devices subscribe to and publish messages to. “Since the devices are scattered throughout the world, the MQTT broker must be internet-facing and accessible by all, see below. This made it an interesting target for our research,” they added.
“First, through researching the router firmware, we found the hardcoded authentication credentials used by all routers to communicate with ConnectedIO’s cloud. We then used these credentials, along with a misconfiguration in the MQTT broker, to subscribe to the status topic and listen to messages, giving us knowledge of the IMEI identifier of all connected devices,” Moshe wrote. “We then used the list we composed of all of the devices’ IMEIs to generate the DR (device receive) topic names for all of the routers, allowing us to issue these devices commands, impersonating ConnectedIO’s cloud.”
Lastly, he added, by exploiting one of the multiple vulnerabilities “we identified in the routers themselves, ranging from a simple OS-command-as-a-service API to a buffer overflow vulnerability, we had the ability to execute code on any internet-connected device.”
Summarized, the exploitation chain involves using hardcoded credentials to connect to the MQTT broker, impersonating a device, leaking all device IMEIs, generating the DR topic name, and then sending a malicious payload to exploit multiple RCE vulnerabilities, ultimately gaining full control over the devices.
These vulnerabilities, if exploited, could pose serious risks for thousands of companies around the world, allowing attackers to disrupt the companies’ business and production, along with giving them access to the companies’ internal networks.
Back in July, Claroty’s Team82 researchers and Check Point Research (CPR) conducted a joint research project that looked at the security of the QuickBlox software development kit (SDK) and application programming interface (API). The research identified a few major security vulnerabilities in the QuickBlox platform architecture that, if exploited, could allow hackers to access tens of thousands of applications’ user databases and put millions of user records at risk.
A complimentary guide to the who`s who in industrial cybersecurity tech & solutions
Free DownloadRelated
