Vulnerability of Teltonika Cloud Takeover Exposed

Vulnerabilities Uncovered Affect Thousands of Internet-Connected Devices Worldwide

Roni Gavrilov / OTORIO
Noam Moshe / Claroty

Comprehensive research was conducted on Teltonika Networks’ IIoT devices, with a focus on industrial cellular devices widely used in various industries, specifically, the Teltonika Remote Management System and RUT model routers. In this research, a collaboration with Claroty was done, joining forces for disclosure and resolving major issues in the mentioned product lines. In the interest of transparency, Claroty and OTORIO have both published the same research article on our own blogs. 

The research uncovered eight vulnerabilities that affect 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 in order to route traffic to malicious sites, or inject malware into traffic. Also, an attacker may exploit these issues to access and control networked devices and change router settings in order to manipulate configurations such as DNS settings or firewall rules. The compromised industrial devices may also be used to launch attacks against other devices or networks.

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. As part of our efforts to provide a more comprehensive view for our customers regarding risks in the Teltonika product, a collaboration with Claroty was done, joining forces for disclosure and resolving major issues in the mentioned product lines. Our findings underscore the urgent need for organizations to prioritize the security of their industrial IoT devices, particularly those connected to the Internet.

Background on Teltonika Networks and Cloud-Based IoT Routers

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’s RMS platform enables 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 and 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.

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.

A search for Teltonika devices using the internet search-engine censys.io

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 picture of a label on the back of each device showcasing the device's MAC 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 to know 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.

Using these two identifiers, users are able to claim their devices and take control of 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

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

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 unsuspecting users' 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 to discover the 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 was created using the RMS Task Manager feature.

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.

RCE on RUT955 obtained by 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.

The router firmware is 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 - 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, and 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 the 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 numbers 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 make this vulnerability actually 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 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:

1. The serial number is already in use
2. The MAC is already in use
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 together.

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 everyone 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 the 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 stems from the tcpdump utility, allowing users to download a pcap of filtered traffic from their devices.

The tcpdump functionality of RUT241 devices allows users to save 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.

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 contains the parameters passed to the tcpdump binary.

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.

A payload was sent to the /UBUS API route, requesting the UCI config for the widget.

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.

A request setting the configuration of the tcp_mount parameter to a malicious OS command.

Then we commit the changes to the configurations:

A commit call, setting our configuration to a malicious value.

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
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.

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” 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.

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 difficult, 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
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's 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 traffic internally to our own web server instead of the local web service:

Legitimate RMS subdomain redirects to a 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:

1. rms.teltonika-networks.com
2. *.rms.teltonika-networks.com

Content-security-policy’ allow loading content from RMS subdomain.

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 an 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.

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.

Stored-XSS leads to remote code execution on all routers under the account.

Accessing Internal Cloud Infrastructure
Another vulnerability we found enabled us to make requests from the RMS infrastructure - CVE-2023-32348. 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 the 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 allows 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 the OpenVPN client in order to connect the device to the Hub.

OpenVPN configuration is 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.

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.

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 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.