Hello, In 2020, a vulnerability (CVE-2020-15858) in multiple Cinterion IoT devices was discovered by Adam Laurie and Grzegorz Wypych of IBM X-Force Red [1].
The issue was described as allowing for organizational secrets theft and Java application code access. The use of Java VM / apps by wireless (connected) devices triggered my attention in particular. Historically, Java flaws could be successfully exploited for a more in-depth investigation of many interesting targets (mobile phones, smart cards, set-top-boxes, cloud environments, databases, etc.). I had a feeling this could be the case for Cinterion IoT as well. I am releasing the details of my initial investigation of Telit Cinterion IoT devices (till the end of 2022 owned by Thales). Brief technical details in a form of a README.md file can be downloaded from this location (bottom of the page): https://security-explorations.com/cinterion-devices.html I would like to emphasize the word initial as there has been many areas that haven't been investigated at all. These include, but are not limited to 3g/4g protocol stacks, USB stack, SIM directed messages, the SLAE cloud management endpoint / API, LWM2M, etc. Yet, numerous issues could be found in a tested Cinterion device such as path traversal issues, Java privilege elevation, AT commands whitelist / blacklist bypasses, brute force space decrease for a remote AT command interface enabling, remote OMA DM management interface auth bypass and finally a heap overflow in fragmented SMS messages processing. The end result is a complete device compromise (code exec at ARM Supervisor level) along a potential (due to the test done in a lab, not in "the wild" / mobile network operator environment) for a remote code execution access. Only phone number of a target device would need to be known (the exploitation is triggered and proceeds with the use of SMS messages among others) for a remote attack. My test were primarily targeting DGL61-W device. Complete local compromise has been also verified for ELS61-E module (firmware indicates same remote issues could be present in it as well). Default device configuration was used in both cases. Through the research numerous tools have been developed. This include standalone toolkit with several helper utilities (Android SMS sender and ASJMLED exploit, JAD / JAR file generator, vendor midlet instrumentation tool, exploit server for a remote vulnerability triggering) making it possible to exploit vulnerabilities in DGL-61W and PLS61-E devices, access device file system, perform runtime code hooking / tracing, manage Java applications and extract low level OS information from the device (AT and URC command tables, Java classes dump and disassembly, device threads, device handles, product test commands, config command handlers, MBIM, etc.). Without this custom tool chain, successful reversing, bug discovery and exploit development would not be possible. Telit company has been notified and provided with full access to research material for evaluation purposes (communication from Jan 11, 2023, all key vulnerabilities were reported to the company in Jan 2023). On Apr 17, 2023, the company provided the results of its triage regarding the reported issues. Telit informed that the base device for which all of the issues got reported (DGL61-W) is at the end of its lifecycle and EOL was announced to customers. The company also indicated that IMEI number leak is an intentional feature and part of the OMA DM protocol and that it doesn't consider it a vulnerability on its own. Issues related to privileges granted by default to Java applications and facilitating hijack of system AT commands were not considered vulnerabilities on their own (described as intentional features and by design rely on customer properly configuring the security of the embedded processing capability). This evaluation is questionable as system commands hijacking by 3rd party code undermines trust to the operating system environment, such a hijacking may also lead to the development of a stealth / persistent backdoor (i.e. AT^SFSA command may return false information about the state of a file system). The remaining issues (which include remote ones) were evaluated with a final risk as not critical - the company made its evaluation upon the use cases and configurations of its major customers. Telit informed that the company rolled out a vulnerability fix for the most critical issues and that a new version of ATSJMLED midlet has been already released. The build date of the files, indicates Jan 18, 2023 (a fix without prior notification / coordination). There has been no information on the web page where the fixed app version has been made available about the security nature of the new release (a silent fix). The only information received from Telit regarding fixes took place on Feb 27, 2023. The company informed that "a fix is planned" for some of the issues (these were not described) and it would keep me updated. No update was provided by Telit prior to the rollout of the fixes though (I learned about the fixes from Apr 17, 2023 "triage" message). Beside learning about a fix without priot notification / coordination, I found Telit response problematic in several other aspects too. First, Telit refered only to DGL61-W device in its "triage". This implicated no other devices were affected. Back in 2020, Thales claimed [2] that at least 5 different Cinterion products were affected to vulnerability found by IBM X-Force Red, which was similar to the one reported to Telit (the vulnerability from 2020 exploited "." character in the path, those from 2023 exploit a combination of "*" and "%" characters, this implicates not a thorough code check by Thales when dealing with CVE-2020-15858). On Mar 16 2023 Telit informed that other devices are also affected ("I can confirm that other Java platforms are affected as well. The R&D team is also verifying this aspect" lines received from the company). Yet, Telit did not refer to these devices / did not provide impact information with respect to them as a result of its triage (an indirect implication these devices are not vulnerable, which was questionable taking into account the above). I have successfully verified that ELS61-E was affected to some of the issues. Telit was also provided with a PoC working on ELS61-E. The company was notified of the potential of other devices being affected as well in that context. This should not be my job though to check every Cinterion device against each reported issue. Telit is a product owner. The company has access to all source codes, documentation, debug interfaces, hidden APIs, tools, dev boards, firmware builds and devices that are required to conduct a proper vulnerability analysis. I pointed out to Telit that their vulnerability triage information is missing information about impact with respect to other devices. As a result, on Apr 20, 2023 Telit completed information about impacted devices and their SW versions and admitted that the issues affect many of them. These are listed below: Vulnerabilities impacting only DGL61-W with pre-installed ATSJMLED Java MIDlet: ATSJMLED MIDlet - all versions lower than 0.1.59 Vulnerabilities impacting products with OMA DM client: ELS61-US/-USA: all FW versions PLS62-W: all FW versions ELS81-US: all FW versions Vulnerabilities common for the platform baseline: BGS5: all product variants and FW versions EHS5/6/8: all product variants and FW versions PDS5/6/8: all product variants and FW versions ELS61/81: all product variants and FW versions PLS62: all product variants and FW versions As for the non-critical nature of the issues (remote ones), IBM X-Force, implicated that "given a critical nature of many of these [Cinterion] devices, a targeted cyberattack could be significant". Medical devices along energy and utilities were provided as an example. In some way this is contradicting Telit evaluation of the potential remote attack against their devices as "not critical". It's contradicting security goal of these products too [3]: "Strong gateway cybersecurity is critical to IoT ecosystem trust". "Thales IoT Gateways are the only industrial IoT gateways to safeguard the complete data-to-cloud journey for the device's lifetime" As the company signalled trouble to execute the PoC two months following the reporting, I fear Telit might be lacking proper competences / engineering resources when it comes to evaluation of security issues (PoC execution problem could be solved by using the precompiled binaries delivered to the company as part of the initial research package from Jan 2023). Finally, there is also one more issue that is still not clear and is worth mentioning. It is related to a missing bug origin information. Both, DGL61-W and ELS61-E devices rely on Intel modem chipset (XMM7160). They embed Intel specific code for OMA DM client too. It is not clear though if remote issues such as OMA DM auth bypass have its origin in Intel code or were introduced by the previous Cinterion vendor (Thales). In that context it is not clear if Intel should be forwarded and handle OMA DM vulnerability information. Similarly, it is not clear if Java path issues (likely having its origin in J2ME classes and file protocol handler) have its origin in Oracle code for embedded J2ME or vendor specific customizations. When inquiried about the abovementioned vulnerabilities origin (whether in Intel / Oracle code), Telit informed me that the company cannot comment on code provided by its platform supplier as it is covered by NDA. According to Telit PSIRT pages [4], PSIRT reserves the right to forward details of issues reported to it if they affect third-party components or external projects. Throughout this process, Telit PSIRT will continue to coordinate and communicate with researchers. No communication regarding forwarding of any issues to any 3rd party company took place. It is not clear if any forwarding took place. Any vulnerability forwarding shouldn't take place without original researcher's (bug discoverer's) consent / approval as: - the original bug discoverer should hold the right to decide about who its bug is shared with (other 3rd parties should learn about it either from a bug finder or a public security bulletin of a vendor) - the original bug discoverer might be eligible for a credit in a public security bulletin of a 3rd party company - the original bug discoverer might be eligible for a Bug Bounty reward (such as Intel Bug Bounty Program [5]) Finally, let me say that as a result of experiencing significant disrespect / problems with various vendors (Microsoft, Canal+ [6], Telit) over the process of reporting the issues to these companies, a new Disclosure Policy gets introduced at my end: https://security-explorations.com/research.html Now, the default is not to inform vendors about security findings anymore and to disclose the results of research to the public without prior notification. Thank you. Best Regards, Adam Gowdiak ------------------------------------- Security Explorations - AGSecRec Lab https://security-explorations.com ------------------------------------- References: [1] New Vulnerability Could Put IoT Devices at Risk https://securityintelligence.com/posts/new-vulnerability-could-put-iot-devices-at-risk/ [2] Security Updates for Cinterion IoT Modules (archived page) https://web.archive.org/web/20201220171411/https://www.thalesgroup.com/en/markets/digital-identity-and-security/iot/resources/security-updates-cinterion-iot-modules [3] Bridge the Gap with IoT Gateways https://www.thalesgroup.com/en/markets/digital-identity-and-security/iot/inspired/iot-gateway [4] Telit Product Security Incident Response Team (PSIRT) https://www.telit.com/about/psirt/ [5] Intel Bug Bounty Program https://www.intel.com/content/www/us/en/security/security-practices/vulnerability-management/bug-bounty-program.html [6] Microsoft PlayReady security research https://security-explorations.com/microsoft-playready.html _______________________________________________ Sent through the Full Disclosure mailing list https://nmap.org/mailman/listinfo/fulldisclosure Web Archives & RSS: https://seclists.org/fulldisclosure/
