Written by Noam Moshe, Roni Gavrilov-OTORIO.
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’s RMS platform, enabling remote management of network devices.
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.
Teltonika’s RUT241 4G router.
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.
Teltonika Device Identification and Pairing Mechanism
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.
A Teltonika RUT router label showing the device’s MAC address and serial number.
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.
The UI used by users to claim their devices, claiming devices by their serial number and MAC address.
Attack Vectors Used to Compromise Teltonika IIoT
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.
Takeover: Unregistered Device over the Cloud (CVE-2023-2586)
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.
Collecting identifiers for registration using shodan.io.
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.
A reverse shell task created using the RMS Task manager feature.
Intheexampleabove,wecreatedareverseshelltaskusingtheTaskManager.Runningthis task on the registered router will result in remote code execution (RCE) with root privileges.
Remote code execution on RUT955 obtained by using the Task Manager feature.
Takeover: Registered Device over LAN/WAN
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.
Remote code execution on RUT955 obtained by using the Task Manager feature.
Teltonika RUT240 router firmware available for download.
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.
Inside Teltonika’s RUT240 firmware
When examining the filesystem inside the firmware upgrade, we discovered some interesting configuration files, setting up configurations for an MQTT broker.
/etc/config/rms_mqtt : a configuration file for the device’s MQTT connection.
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: main things:
Thisbinaryhandlestwo
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.
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,
A JSON sent by the device in order to identify itself to the cloud and receive an MQTT certificate.
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 sufix 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
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.
Finding all Registered Devices Using Cloud Oracles
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 , allowing users to claim their devices. Using this route, users try and claim devices from their serial number and MAC address. However, we noticed that only three options exist:
1. The serial number is already in use
2. TheMACisalreadyinuse
3. The device is successfully claimed
An error returned from the claiming process, telling us that the serial number we guessed is used already in the RMS platform.
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.
A request checking multiple serial numbers and MACs.
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 bruteforce necessary to find every one to 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.
A login request over Teltonika’s WebUI.
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 trafic from their devices.
The tcpdump functionality of RUT241 devices, allowing users to save trafic from their devices.
The tcpdump functionality of RUT241 devices, allowing users to save trafic from their devices.
In order to save the trafic, Teltonika uses the tcpdump binary. Users can also filter the trafic, only saving trafic coming from a specific interface, host etc. These filters will then be reflected inanOScommandexecutingtcpdump. 
The tcpdump command is being executed by the Teltonika TCPDump utility.
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.
The /etc/config/system configuration file, containing the parameters passed to the tcpdump binary.
However, one feature that is exposed to authenticated users is the , which gives access to users to the utility. By using this API, which is accessible through the
API route, it is possible for users to interact with the UCI configuration utility, allowing users to both get and set configuration parameters.
A payload sent to the /UBUS api route, requesting the UCI config for the widget.
Through this 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.
A request setting the configuration of the tcp_mount parameter to a malicious OS command.
Then we commit the changes to the configurations:
Then, whenever we use the TCPDump utility, our malicious payload will be executed.
Our malicious payload being executed, resulting in us being able to execute OS commands in the root permissions.
Registered Device(s) Takeover Through Account Takeover (CVE-2023- 2587)
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 field to trigger the vulnerability.
HTML object in the fw_version field.
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” 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 tag to load an arbitrary web page; by moving the mouse over the “malicious” web page will be loaded.
Mouse over the fw_version field will trigger the XSS.
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 dificult, we’ve chained it with the next vulnerability, which led to easier and reliable exploitation of account takeover.
Abusing User-controlled Subdomains in teltonika-networks.com (CVE- 2023-2588)
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:
- Accessing router local web service over the cloud.
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 trafic internally to our own web server instead of the local web service:
Legitimate RMS subdomain redirect to malicious web page.
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:
Content-security-policy allows loading content from RMS subdomain
Thesecondsource(*.rms.teltonika-networks.com)includestheDeviceWEBfeature(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:
- Exploit page: Creates a reverse shell and executes it on all routers.
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.
Accessing Internal Cloud Infrastructure (CVE-2023-32348)
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.
The RMS VPN feature, allowing users to set up a VPN network for their 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.
OpenVPN configuration used by the device to connect to the VPN 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.
An internal service used by Teltonika to manage their VPN hubs.
A request to Amazon AWS meta-data service, providing information about the internal AWS network only accessible to servers from the internal networks.
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 sensitiveninformation.
Generallyspeaking,thistypeofcloud-basedserver-siderequestforgery(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.
Summary
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.
