Security vulnerabilities in Telit Cinterion IoT (formerly Thales) devices

[Security Explorations <contact () security-explorations com>]

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/