Team82 Research
Comprehensive research was conducted on Teltonika Networks’ IIoT products, with a focus on industrial cellular devices widely used in various industries, specifically, the Teltonika Remote Management System, and RUT model routers.
This research is the result of a collaboration with OTORIO, joining forces for disclosure and resolving major issues in the affected product lines.
The research uncovered eight vulnerabilities, affecting thousands of internet-connected devices worldwide.
Multiple attack vectors were identified during the research, including the exploitation of internet-exposed services, cloud account takeover, and cloud infrastructure vulnerabilities.
An attacker successfully exploiting these industrial routers and IoT devices can cause a number of impacts on compromised devices and networks, including monitoring network traffic and stealing sensitive data, hijacking internet connections and accessing internal services.
Teltonika Networks mitigated the vulnerabilities in coordination with CISA, which published an advisory Thursday; CISA's advisory assesses one of the vulnerabilities a CVSS v3 score of 10.
We would like to thank Teltonika Networks for fixing all the reported issues and coordinating closely with us.
Teltonika Networks specializes in manufacturing and developing networking devices, including routers, modems and industrial networking equipment.
The Teltonika Remote Management System (RMS) product is a cloud-based or on-premises platform that enables users to monitor and manage their connected devices from anywhere. The RMS platform provides real-time monitoring and control, making it easier for organizations to track the status and performance of their devices and network. The platform also offers advanced features such as device management, software and firmware updates, GPS tracking, and data visualization. The RMS platform is designed to be scalable and secure, ensuring that businesses of all sizes can benefit from the platform's capabilities.
Teltonika offers a wide range of network solutions and devices, however we’ve looked at the RUT241 and RUT955 devices in particular. These devices are part of the company’s industrial cellular routers product line and offer 4G LTE, WiFi, and Ethernet communication designed specifically for industrial environments and commercial applications. The RUT241 and RUT955 routers are equipped with advanced network routing and firewall capabilities, various VPN protocols, allowing users to securely connect to their private networks. These routers are also easy to configure and manage, making them suitable for use by businesses of all sizes.
While hundreds of thousands of Teltonika devices are deployed worldwide, a search on internet-scanning engines such as Shodan and Censys also reveals thousands of internet-facing devices, with their management ports externally exposed to the internet.
When examining the device identification process in Teltonika’s RMS platform, we noticed that the only two identifiers needed in order to claim and interact with a device are a device serial number (SN) and MAC address. These two identifiers are labeled on the back of every device, and should ensure that only users with physical access to the device can claim it.
Since we did not have our device at that time, we could not progress without research as any vector we wanted to explore required us knowing these two identifiers. Luckily for us, one of the industry trends lately is people uploading an unboxing/tutorial video to YouTube, explaining how to set up the device. In many cases, since users film their device, they are also leaking the device’s secret at the same time, images below.
Using these two identifiers, users are able to claim their devices and take control over them. Then, the device authenticates to the cloud using the same identifiers.
In our mutual research, we have focused on three threat scenarios in which remote attackers are able to compromise the Teltonika cloud-management solution and take full control over unregistered and registered devices. We’ve used different techniques and methods including direct exploitation as well as remote and cloud capabilities to manipulate remote users into compromising their accounts and devices. When exploited, these vulnerabilities could allow attackers full control over Teltonika 4G routers. Attackers could use it as a pivot point to companies’ internal networks, giving access to internal IoT and industrial devices that were never meant to be exposed, putting them at risk.
Teltonika RMS cloud-based management platform is vulnerable to an unauthorized attacker registering previously unregistered devices on the RMS, but only if the router’s RMS management feature, which is enabled by default, has not been disabled. This could enable the attacker to perform different operations from the cloud on an unsuspecting user's routers, including remote code execution with root privileges (using the Task Manager feature on RMS).
Attackers can collect the identifiers used for registration in different ways, for example by using shodan.io, register the device to their account and then compromise it. In order to demonstrate how easy it is, we’ve written a python script leveraging the shodan API for discovering Teltonika routers MAC address and serial number. Querying SNMP service of internet exposed devices, we queried the relevant OIDs, providing us with the secret identifiers required for registration. Using this method, we were able to discover hundreds of MAC and serial number pairs.
Using the collected identifiers, an attacker could register these devices to his cloud account, if they were not previously registered to any account. Since not all people necessarily use Teltonika RMS to manage their devices, we discovered that many devices are actually connected to the internet but not claimed on Teltonika’s cloud.
After a device is paired to the attacker's cloud account, the Task Manager feature in the cloud platform could allow the attacker to create a task and execute commands on the remote device.
In the example above, we created a reverse shell task using the Task Manager. Running this task on the registered router will result in remote code execution (RCE) with root privileges.
Our next goal in this research project was to understand how devices connect to the cloud, identify themselves, and create a secure communication channel.
In order to do so, we downloaded, extracted, and reverse engineered the device’s firmware, which is available for download on Teltonika’s website.
The firmware file is a big binary blob, however it contains a SquashFS filesystem inside, along with a kernel image. It is very common for vendors to ship a filesystem in their firmware, including all the files necessary for an upgrade.
When examining the filesystem inside the firmware upgrade, we discovered some interesting configuration files, setting up configurations for an MQTT broker.
MQTT is a pub-sub protocol aimed at allowing remote communication in the form of messages. As part of the MQTT protocol, two different kinds of entities reside: a client which could send and receive messages, and a broker which distributes received messages and routes them to the appropriate clients.
In order to distribute the messages to the correct clients, the broker holds a list of topics - different channels which publishers could send messages to - and in order for a client to receive messages, they need to subscribe to a certain topic. Whenever a message is sent to a specific topic, the broker distributes it to all the users who have subscribed to this topic.
MQTT supports a wide variety of security mechanisms, including encryption, client username/password authentication and even certificate-based authentication. Inside the configuration file we discovered, we saw mentions of certificates and keys that could be used to establish the MQTT connection. There was no actual client certificate and key embedded inside the firmware itself, which meant devices must receive said certificates as part of the cloud connection process.
In order to obtain a device’s certificate and connect to the MQTT broker, we reversed engineered the main binary handling cloud communication: rms_mqtt. This binary handles two main things:
Cloud Communication Handshake: the device connects to the Teltonika RMS cloud server, informing it that the device is online and ready to be managed by the cloud.
MQTT Communication: the device connects to Teltonika’s MQTT broker and registers to multiple topics in order to send status reports and receive commands from the cloud. During this communication, the device authenticates to the MQTT broker using its private key and certificate.
We discovered that during the initial cloud handshake, devices identify themselves to the cloud and request a private key and certificate for MQTT communication. This is done by sending the device information, including its model, firmware version but most importantly the device’s serial number and MAC address to the cloud.
By leaking a device serial number and MAC address, it is possible for attackers to authenticate to Teltonika’s RMS platform and receive a device certificate. Then, using said certificate, it is possible for the attackers to connect to Teltonika’s MQTT broker and communicate on behalf of the device, impersonating it.
This form of device identification and authentication is not secure, since it relies on two inherently weak identifiers: serial number and MAC address.
The serial number part of the authentication is a sequential number following a certain prefix, and is easily guessable because it consists only of numbers in specific ranges instead of being completely random. Examples:
1112XXXXX
1123XXXXX
When looking at the MAC part of the authentication, it is flawed as well. Like most other devices, the MAC address of Teltonika devices is composed of two different parts: three bytes of the organizationally unique identifier (OUI) and three unique bytes of the specific device.
An example MAC address could look like this, where the blue part is the manufacturer prefix part of the MAC, and the green part is the device suffix part of the MAC:
00:1E:42:11:22:33
This MAC composition means that the number of possible MAC addresses for each device is at most 8*3=24 bits (224=16,777,216), which is a relatively small number and is easily guessable by attackers.
While this identification method is definitely not secure, it is still not easy to exploit it in a real-life scenario, because it will require too much time to brute force all possible serial number and MAC combinations. Using this weak identification alone, an attacker would need to execute [Number_of_Possible_SNs] * [Number_of_Possible_MACs] requests, or ~100,000 * 2 ^ 24 requests in order to gain control over all cloud-connected devices, or ~100,000 requests in order to claim one device in particular.
In order to make this vulnerability (CVE-2023-32347) even more easily exploitable, we discovered another vulnerability that allowed us to leak all used serial numbers and MAC addresses, drastically reducing the range of our brute force attack.
As part of our research on the RMS platform, we discovered a feature in the platform that allows users to enumerate the serial numbers and MAC address of all cloud-connected devices. This type of vulnerability is called an information oracle, because it could be used to identify and distinguish between used and unused serial numbers and MACs.
This vulnerability (CVE-2023-32346) lies in the device claiming feature, accessible from this API route: /api/devices/import, allowing users to claim their devices. Using this route, users can try and claim devices from their serial number and MAC address. However, we noticed that only three options exist:
The serial number is already in use
The MAC is already in use
The device is successfully claimed
Abusing this oracle, we can easily create a list of all the serial numbers and MAC addresses of cloud-connected devices. This is made even more trivial when we notice that this feature accepts a CSV list of devices, meaning we could check multiple serial numbers and MACs in one request.
By abusing the CSV import feature, it is possible for attackers to retrieve a full list of all used serial numbers and MAC addresses in the RMS platform, which reduces the range of brute force necessary to find every one to [Number_of_Actual_Devices] ^ 2. Then, by performing this brute force computation, attackers can identify and impersonate every device on the platform.
After gaining the ability to impersonate devices, we explored what new attack surface was exposed. One feature that caught our interest was the ability to access the device management ports over Teltonika’s cloud, allowing users to access their device’s SSH service and web server. During usage of this feature, the device’s password is passed directly to the device, in order to authenticate the user. By impersonating the device, we managed to leak this password, and gain the credential for the device.
This, in combination with the thousands of devices that are internet-facing led us to seek out vulnerabilities in the device management web server. That’s where we discovered a few remote code execution vulnerabilities that could allow attackers to take over Teltonika 4G routers.
This vulnerability (CVE-2023-32349) stems from the tcpdump utility, allowing users to download a PCAP of filtered traffic from their devices.
In order to save the traffic, Teltonika uses the tcpdump binary. Users can also filter the traffic, only saving traffic coming from a specific interface, host etc. These filters will then be reflected in an OS command executing tcpdump.
When it comes to filter validation, Teltonika actually validates each parameter, not allowing users to supply malicious parameters thus blocking an attempt for an OS command injection.
However, when we look where these variables are stored, we notice that it comes from the UCI configuration tool, used by Teltonika devices to store and change system configurations. Behind the scenes, this is mapped to a config file containing these variables.
However, one feature that is exposed to authenticated users is the UBUS JSONRPC, which gives access to users to the UBUS utility. By using this API, which is accessible through the /UBUS API route, it is possible for users to interact with the UCI configuration utility, allowing users to both get and set configuration parameters.
Through this UBUS interface, it is possible for users to alter configurations in the system. Abusing this, we can alter the configuration for one of the parameters passed to the TCPDump utility, and then save the configuration. Then, when we invoke the TPCDump utility, it will use our parameters and will execute arbitrary code.
Then we commit the changes to the configurations:
Then, whenever we use the TCPDump utility, our malicious payload will be executed.
The first step in the attack process involves an attacker obtaining a valid MAC-serial pairing of any Teltonika router registered to a cloud account. Once an attacker has this information, the attacker can impersonate the device and make the RMS cloud platform think they are the actual router. As a result, all the information that is supposed to be sent to the router will be sent to the attacker instead.
Attackers with a MAC-serial of a registered device can send a specially crafted JSON message with an HTML object in the fw_version field to trigger the vulnerability.
By sending this JSON message, the attacker will trigger a stored-cross-site scripting (XSS) vulnerability under the “DEVICE FIRMWARE” window in the middle of the main RMS page for this router administrator (the victim). The vulnerable place is when the victim moves the mouse over the “malicious” fw_version that we inject. As it can see in the image above.
For demonstration, we inject an HTML object with the tag <u> (underline). Another example would be the HTML <embed> tag to load an arbitrary web page; by moving the mouse over the “malicious” fw_version the web page will be loaded.
This XSS could be leveraged by a malicious actor in order to leak cookies, resulting in account takeover. But, as some limitations in the XSS made it a bit more difficult, we’ve chained it with the next vulnerability, which led to easier and reliable exploitation of account takeover.
The “Device CLI/Device WEB” feature in the RMS, allows users to access managed device’s local ssh/web management services over the RMS cloud proxy. Requesting for a web proxy to our device, will result in a url in the RMS cloud subdomain leading to our device local web interface:
This URL can be shared with others and requires no RMS-level authentication. Since we are in control of our local device, we are also in control of the web pages that are served over this URL.
For example, we can redirect the traffic internally to our own web server instead of the local web service:
As the defined web policies in the domain (such as Content Security Policy) are also open, at this phase we are able to execute JavaScript code in the context of the connected client. In the image below we can see that RMS define whitelist with two sources:
rms.teltonika-networks.com
*.rms.teltonika-networks.com
The second source (*.rms.teltonika-networks.com) includes the Device WEB feature (remote proxy over the RMS).
Leveraging this issue, we managed to write a web page that will be loaded automatically when accessing the url, automatically leaking the user’s RMS cloud cookies or executing action on behalf of it, on this example, remote code execution on all managed devices in the account:
While this malicious page can be embedded on any website online or sent as part of a phishing campaign, using the stored-XSS vulnerability in the fw_version field, an attacker can target specific users, using the HTML <embed> tag to load the exploit page as part of their management panel.
Once the victim moves the mouse over this area, the exploit.html web page will be loaded, creating a reverse shell on all managed routers under this RMS user.
Another vulnerability (CVE-2023-32348), enabled us to make requests from the RMS infrastructure. This meant we were able to access everything the RMS can access, including internal API, other infrastructure etc. By exploiting this vulnerability, it is possible for attackers to access internal infrastructure used by Teltonika.
This vulnerability stems from the Device VPN Hub feature of the RMS platform, a shared VPN hub allowing cross-device communication. This feature allows users to set up a private VPN connection over Teltonika’s infrastructure to create some kind of a local network over the cloud between Teltonika routers and remote devices.
Behind the scenes, this feature uses an OpenVPN server and client in order to connect the devices to the Device VPN Hub. When users connect their devices to a specific VPN hub, RMS downloads to the device an OpenVPN configuration, including private keys and certificates, and then it executes OpenVPN client in order to connect the device to the Hub.
Then, the OpenVPN client on the device opens and creates a new virtual interface for the VPN tunnel. Finally, it can communicate with all devices connected to this VPN, over the new interface.
However, we discovered that the OpenVPN server hosted by Teltonika allows devices to route through it. This means that if we implicitly try to connect to a remote server, routing through the OpenVPN server, the OpenVPN server will route our request to the destination. This enables us to scan and access everything the OpenVPN server itself is accessible to, including internal backend services, other infrastructure and even the cloud infrastructure itself.
For example, by routing through the OpenVPN server, we were able to access both the AWS infrastructure and exfiltrate sensitive identification tokens, and internal Teltonika services.
By abusing this arbitrary routing vulnerability, attackers could be able to access Teltonika’s internal services, including the Amazon AWS Metadata service, and may leak sensitive information.
Generally speaking, this type of cloud-based server-side request forgery (SSRF) vulnerability could be dangerous, because it exposes the cloud infrastructure to attacks and could allow attackers to compromise the entire cloud. However, in this case we could not leverage this attack further.
The evolution of industry 4.0 demands high connectivity of devices wherever they are located. The use of 4/5G routers to enable such connectivity has been and will always be one of the foundations that enable the hyper transformation and drives this connectivity.
In IoT, the challenge starts with the need to scale up; most solutions need to support a huge fleet of 4G routers, enabling sys-admins to configure, monitor, and maintain all of their devices. This is where cloud management platforms are introduced, allowing sys-admins control over their devices remotely, through the internet.
However, with the move to smart cloud-controlled devices comes risk, as vulnerabilities in the cloud platform could introduce new attack vectors to companies, putting at risk their remote site and vulnerable IoT/IIoT networks.
In order to explore this new threat landscape, Claroty’s Team82 and OTORIO collaborated to research and uncover critical vulnerabilities in one of the most popular 4G router solutions, Teltonika Networks Throughout our research, we explored attack surfaces in 4G routers’ cloud management platforms, and discovered three unique attack vectors that could allow attackers to remotely take control over devices and gain access to companies’ internal IIoT/IoT networks.
All discovered vulnerabilities were disclosed to Teltonika, which addressed and provided security fixes to them all.
We wish to acknowledge and thank Teltonika Networks for its cooperation and coordination throughout this disclosure.
CWE-204: Observable Response Discrepancy
Teltonika’s Remote Management System versions prior to 4.10.0 contain a function that allows users to claim their devices. This function returns information based on whether the serial number of a device has already been claimed, the MAC address of a device has already been claimed, or whether the attempt to claim a device was successful. An attacker could exploit this to create a list of the serial numbers and MAC addresses of all devices cloud-connected to the Remote Management System.
Read more: “Triple Threat: Breaking Teltonika Routers Three Ways”
CVSS v3: 5.3
CWE-287: Improper Authentication
Teltonika’s Remote Management System versions prior to 4.10.0 use device serial numbers and MAC addresses to identify devices from the user perspective for device claiming and from the device perspective for authentication. If an attacker obtained the serial number and MAC address of a device, they could authenticate as that device and steal communication credentials of the device. This could allow an attacker to enable arbitrary command execution as root by utilizing management options within the newly registered devices.
Read more: “Triple Threat: Breaking Teltonika Routers Three Ways”
CVSS v3: 8.1
CWE-918: Server-Side Request Forgery
Teltonika’s Remote Management System versions prior to 4.10.0 contain a virtual private network (VPN) hub feature for cross-device communication that uses OpenVPN. It connects new devices in a manner that allows the new device to communicate with all Teltonika devices connected to the VPN. The OpenVPN server also allows users to route through it. An attacker could route a connection to a remote server through the OpenVPN server, enabling them to scan and access data from other Teltonika devices connected to the VPN.
Read more: “Triple Threat: Breaking Teltonika Routers Three Ways”
CVSS v3: 9.3
CWE-15: External Control of System or Configuration Setting
Versions 00.07.00 through 00.07.03.4 of Teltonika’s RUT router firmware contain a packet dump utility that contains proper validation for filter parameters. However, variables for validation checks are stored in an external configuration file. An authenticated attacker could use an exposed UCI configuration utility to change these variables and enable malicious parameters in the dump utility, which could result in arbitrary code execution.
Read more: “Triple Threat: Breaking Teltonika Routers Three Ways”
CVSS v3: 8.0
CWE-78: Improper Neutralization of Special Elements used in an OS Command (OS Command Injection)
Versions 00.07.00 through 00.07.03 of Teltonika’s RUT router firmware contain an operating system (OS) command injection vulnerability in a Lua service. An attacker could exploit a parameter in the vulnerable function that calls a user-provided package name by instead providing a package with a malicious name that contains an OS command injection payload.
Read more: “Triple Threat: Breaking Teltonika Routers Three Ways”
CVSS v3: 8.8
CWE-287: Improper Authentication
Teltonika’s Remote Management System versions 4.14.0 is vulnerable to an unauthorized attacker registering previously unregistered devices through the RMS platform. If the user has not disabled the "RMS management feature" enabled by default, then an attacker could register that device to themselves. This could enable the attacker to perform different operations on the user's devices, including remote code execution with 'root' privileges (using the 'Task Manager' feature on RMS).
Read more: “Triple Threat: Breaking Teltonika Routers Three Ways”
CVSS v3: 9.0
CWE-79: Improper Neutralization of Input During Web Page Generation (Cross-Site Scripting)
Teltonika’s Remote Management System versions prior to 4.10.0 contain a cross-site scripting (XSS) vulnerability in the main page of the web interface. An attacker with the MAC address and serial number of a connected device could send a maliciously crafted JSON file with an HTML object to trigger the vulnerability. This could allow the attacker to execute scripts in the account context and obtain remote code execution on managed devices.
Read more: “Triple Threat: Breaking Teltonika Routers Three Ways”
CVSS v3: 7.5
CWE-830: Inclusion of Web Functionality from an Untrusted Source
Teltonika’s Remote Management System versions prior to 4.10.0 have a feature allowing users to access managed devices’ local secure shell (SSH)/web management services over the cloud proxy. A user can request a web proxy and obtain a URL in the Remote Management System cloud subdomain. This URL could be shared with others without Remote Management System authentication . An attacker could exploit this vulnerability to create a malicious webpage that uses a trusted and certified domain. An attacker could initiate a reverse shell when a victim connects to the malicious webpage, achieving remote code execution on the victim device.
Read more: “Triple Threat: Breaking Teltonika Routers Three Ways”
CVSS v3: 8.8
