Cellular IoT Vulnerabilities: Another Door to Cellular Networks

Cellular IoT vulnerabilities show an increasing trend over the years, indicating that these devices are becoming more and more popular — and that they are being targeted more frequently.

By Jennifer C. Lin, Richard Y. Lin, and Salim S.I

Key Takeaways

  • Private cellular networks extensively use cellular routers and gateways to provide connectivity for IoT devices, and compromised routers have been used as initial access vector to cellular networks. 
  • Web vulnerabilities dominate. The distribution of vulnerability types follows the same pattern as non-cellular routers. These are probably inherited from common router software development kits (SDKs). However, the noticeable presence of cellular technology-specific vulnerabilities is unique to these devices. 
  • Our survey shows that generic IT security vendors have limited coverage for these device specific CVEs. 
  • Cellular IoT vulnerabilities show an increasing trend over the years, indicating that these devices are becoming more popular, and that they are being targeted more frequently. Most major cellular router vendors are present on the vulnerability list, showing the need for wide coverage to secure cellular networks. 

Are cellular IoT devices accessible from external networks? 

Private cellular networks are typically deployed by organizations for operation-critical devices like machinery, sensors, and vehicles; therefore, the chosen security solution must cover both the infrastructure and the connected devices. This differs from public networks where the security of connected devices is left to the device’s owner. CTOne has been tracking cellular IoTs over the last few years, building a repository covering hundreds of vulnerabilities in this space. This article shares insights from our database. 

Cellular technology as a connectivity option is on the rise among IoT devices. Trend Micro researchers have flagged the risks of “unexpected connectivity in areas where security models expect no connectivity.” 

In general, connected devices in cellular networks have private IP addresses, which are assigned by the cellular packet core or a separate DHCP server. Network Address Translation (NAT) is performed at the N6 interface (the gateway to external networks). This private subnet acts as an effective layer of protection, shielding devices from external attackers. In practice though, there are many instances where cellular IoT devices require direct connectivity to the internet. 

  • IoT sensors frequently connect to a cloud server to upload data. 
  • Large fleets of IoT devices are often connected to a management cloud (for tasks such as firmware upgrades and configuration changes). 
  • They may need to be accessed from outside for remote management and trouble shooting. 

This is in addition to the unintentional exposure that can occur due to configuration errors. Misconfigurations, such as improperly set NAT rules or firewall settings, can inadvertently expose private devices to the public internet. 

A Shodan search with keywords like “LTE” throws up thousands of results.  

Figure 1. Shodan search results for the keyword “LTE,” filtered for a telco

Figure 1. Shodan search results for the keyword LTE, filtered for a telco 

Figure 2. Industrial routers on Shodan

Figure 2. Industrial routers on Shodan

Figure 3. Cellular cameras on Shodan

Figure 3. Cellular cameras on Shodan 

Cellular routers are the most versatile IoT connectivity devices. They create a local Wi-Fi network that allows IoT devices, such as sensors, cameras, and smart appliances, to connect seamlessly. These routers access the internet via cellular networks such as 4G LTE or 5G. Cellular connectivity enables IoT devices in remote areas or mobile environments, such as farms, oil rigs, or vehicles, to maintain cloud connectivity for data transmission, monitoring, and control. 

The figures below show a typical deployment for a remote pump station proposed by Advantech and the traffic management system from Teltonika 

Figure 4. A remote pump station proposed by Advantech

Figure 4. A remote pump station proposed by Advantech 

Figure 5. Traffic management system from Teltonika

Figure 5. Traffic management system from Teltonika 

In-the-wild 

Threat actors have extensively used Cellular IoTs and routers in the wild, just like their non-cellular counterparts. The added focus on cellular IoT devices comes from two reasons: 

  • They are frequently deployed in industrial, vehicular, and military networks, which are high-value targets. 
  • They are often deployed in remote locations, outside traditional security controls, making them more vulnerable to attacks. 

Claroty’s Noam Moshe explains how cellular routers were used in FuxNet attackshere 

Figure 6. FuxNet attack architecture (Source: Claroty)

Figure 6. FuxNet attack architecture (Source: Claroty) 

CVE-2023-43261, which affects Milesight industrial cellular routers, is suspected to be exploited in the wild. In 2021, it was discovered that TP-Link cellular routers were abused for years in SMS messaging-as-a-service scam. In Poland, cybercriminals hacked cellular devices including DaHua cellular cameras, D-Link and Teltonika cellular routers, and Digi cellular modems to mass-send SMS messages. 

Mandiant documents the growing trend of Operational Relay Box (ORB) networks among threat actors to cover C2 (command and control) tracks. ORB networks employ compromised routers and connected IoT devices to build their botnet service. 

Device type distribution 

It is no surprise, then, that routers are heavily represented in our threat database. 

Figure 7. Device type distribution (Source: CTOne)

Figure 7. Device type distribution (Source: CTOne) 

Protocol distribution 

The heavy presence of cellular routers in the dataset skews vulnerability statistics toward router-related issues. After all, cellular routers are not too dissimilar from Wi-Fi routers, except for the presence of a baseband modem, and a few modules such as ADB (Android Debug Bridge) and SMS capabilities. As shown in Figure 8, HTTP dominates the protocol distribution. Short Message Peer-to-Peer Protocol (SMPP) and ADB are unique to cellular devices. Message Queuing Telemetry Transport (MQTT), commonly seen in IoT environments, also has a notable presence. 

The presence of cellular protocols (ADB, SMPP) and industrial protocols (MQTT) is unique to industrial cellular devices. These vulnerabilities are unlikely to be detected by generic network security solutions. Administrators responsible for securing cellular networks should seek solutions that can cover these specialized protocols. 

Figure 8. Protocol distribution (Source: CTOne)

Figure 8. Protocol distribution (Source: CTOne) 

Vulnerability type distribution 

It follows from the dominance of HTTP in protocol distribution that many of the vulnerabilities are also related to web interfaces. We see that a wide range of vulnerabilities can be exploited without authentication (Figure 10), many of which are web-related (Figure 8). Many IoT web servers are configured to support only HTTPS. Therefore, it is recommended to select a security solution capable of decrypting web traffic toward IoT devices. 

Figure 9. Top ten vulnerabilities by type (Source: CTOne)

Figure 9. Top ten vulnerabilities by type (Source: CTOne) 

Authentication 

Brute force logins are one of the most common attacks on the internet. However, to keep focus on vulnerabilities originating from the vendor, this category was excluded from the dataset, along with issues related to weak credentials. 

This raises the question: How many vulnerabilities in the dataset require authentication, and can strong passwords prevent these attacks?  

Our analysis reveals that 72% of the vulnerabilities in our database can be exploited without authentication. Strong passwords are necessary but insufficient to mitigate these threats. As previously mentioned, cellular IoT devices are often exposed to the internet for various reasons. To minimize the risks, a network security solution that covers a broad range of devices is essential. 

Figure 10. Pre-authentication vs post-authentication (Source: CTOne)

Figure 10. Pre-authentication vs post-authentication (Source: CTOne) 

CVE trends 

The CVEs in the dataset span from 2018 through the first half of 2024, as shown in Figure 8. Despite the seeming dip from 2003, we believe the overall trend shows an increase in CVEs. The drop from 2023 can be attributed to the fact that recent CVEs are still under processing, they will be included in the database after details are known.  

Note: The plot in Figure11 covers only published CVEs in our database. 

Figure 11. Cellular IoT CVE trend (Source: CTOne)

Figure 11. Cellular IoT CVE trend (Source: CTOne) 

Vendors 

Many cellular IoT vendors have a presence in the dataset.  

Figure 12. Vendor list (Source: CTOne)

Figure 12. Vendor list (Source: CTOne) 

Cellular IoT vulnerabilities vs others 

The macro view of cellular IoT threat landscape is similar to that of other IoT devices. However, the dataset shows a noticeable presence of cellular-technology-specific vulnerabilities (E.g., ADB, SMPP, QCMAP). 

Some of these vulnerabilities, such as those in QCMAP (Qualcomm Mobile Access Point), have a broad impact. QCMAP software suite is bundled with many of Qualcomm’s SoCs (system-on-chip). Connectivity modules from various vendors integrate these SoCs, making them vulnerable as well. For example, CVE-2020-3657. 

Vulnerabilities in cellular modems impact millions of devices, sometimes in unexpected places. CVE-2024-20082 is a remote code execution (RCE) vulnerability that affects multiple MediaTek modems, including MT2735. MediaTek’s flagship automotive platform Dimensity Auto integrates MT2735. CVE-2023-47610 is an SMS triggered remote code execution in Telit Cinterion cellular modems.  

Researchers have hacked several 4G modules, leading to the compromise of connected devices including vehicles. Several baseband vulnerabilities have been disclosed for Qualcomm and MediaTek chips. The attack vector for many of them is over-the-air (OTA). 

Some cellular routers' status pages are accessible without a password. IMSI is displayed on the status page. Although not a vulnerability per se, it is worth noting that 3GPP goes to great lengths to hide IMSI for privacy reasons. 

Securing cellular IoT devices 

Cellular IoT devices are expected to be deployed in remote locations, so they are designed for extremely low resource consumption. Running endpoint security solutions is nearly impossible, and network-based protection is usually the only feasible solution. 

Data shows that web interface vulnerabilities are the most common. However, web interface is usually SSL encrypted. Network security solutions must be able to decrypt this traffic to be effective. To detect attacks involving unauthenticated access, the security solution must be able to distinguish between authenticated and unauthenticated users. 

A hugely varied device ecosystem presents a challenge for security vendors in terms of coverage. Additionally, details of vulnerabilities are rarely published, requiring focused effort from security vendors to stay up to date. 

We analyzed the coverage of cellular IoT vulnerabilities by major security vendors, and the results show that many vendors provide limited coverage for these vulnerabilities. 

Security recommendations  

Ensuring clear visibility of your 5G assets as a part of the attack surface risk management strategy is a critical first step. Regardless of how roles and responsibilities are allocated between businesses and partners, security visibility and consistent monitoring across the entire 5G environment is of paramount importance. We analyzed the coverage of cellular IoT vulnerabilities by major security vendors, and the results show that many vendors provide limited coverage for these vulnerabilities. 

For more suggestions, visit this page: Securing Private 5G: Where to Start? - CTOne 

HIDE

Like it? Add this infographic to your site:
1. Click on the box below.   2. Press Ctrl+A to select all.   3. Press Ctrl+C to copy.   4. Paste the code into your page (Ctrl+V).

Image will appear the same size as you see above.