Hello All,
On Mar 20, 2019 Security Explorations reported a security vulnerability
(Issue 19) to Gemalto [1], that made it possible to achieve read, write
and native code execution access on company's card (GemXplore 3G v3.0).
On Mar 30, 2019, Gemalto provided is with the results of its analysis
of the submitted report.
Gemalto started its message by stating that "the company is committed
to provide state of the art security products and solutions to its
Customers and is always very attentive to security information that
may affect them".
Yet, Gemalto did not ask Security Explorations for:
1) a Proof of Concept code illustrating the reported issue,
2) details regarding a novel method to read complete memory of GemXplore3G
card with the use of 16-bit JCRE references,
3) details regarding a method to completely read memory of USimera
Prime card,
4) the way native code execution was achieved on the card regardless
of the Harvard RISC architecture of the underlying Samsung CalmRISC16
processor.
The company indicated that its "R&D Card teams and Java Card experts
have thoroughly studied the report submitted as well as other technical
information made public by Security Explorations".
Yet, the company referred to reported issue as potentially impacting
Gemalto products and finally concluded it is "not applicable to products
used in compliance with their user guidelines" [2]. Gemalto indicated
that "today and to the best of its knowledge, there is no vulnerability
in the applet loading process".
Security Explorations does not think Gemalto R&D Card teams and Java
Card experts have thoroughly studied the received vulnerability report.
The report contained an unintentional mistake in the way that it
incorrectly associated GemXplore issue to USimera Prime SIM card. The
USimera card could be successfully exploited, however the exploit was
due to another vulnerability and Gemalto should have spotted that.
Today, Security Explorations provided Gemalto with an updated version
of the report, which now treats USimera issue as a separate weakness
(Issue 33).
Security Explorations is perfectly aware that Gemalto makes use of its
own custom implementation of Java Card VM. This implementation hasn't
been investigated in a thorough fashion as there was no need for it.
Discovered issues were completely sufficient to achieve unauthorized
access to target cards (such as to code and data memory or STK keys)
as proven by our accompanying publication [3].
In that context, Gemalto referral to Security Explorations' report in
terms of potentially affecting company's products does not reflect the
reality. The reported issue has been clearly proven to affect given
Gemalto products. The security of Gemalto's Java Card VM implementation
has been successfully compromised regardless of some custom security
checks implemented by the runtime.
It's worth to note that achieved compromise clearly shows that target
Gemalto SIM cards failed to provide secure environment for multiple
applications as imposed by Java Card specification [4]. Vulnerable
Gemalto SIM cards cannot securely co-host applications from various
providers such as telecom and banking due to no security isolation
between them.
It's surprising to learn that one of the world's top SIM card vendors
dismisses a threat reported with respect to company's products. which
are potentially used to safeguard security and privacy of hundreds of
millions of people around the globe.
Security Explorations has reasons to believe that Gemalto SIM cards
require an in-depth security investigation.
Initial security analysis conducted with respect to GemXplore3G SIM
card revealed several instances of preinstalled, proprietary SIM Toolkit
applications from Gemalto with a dangerous functionality. At least one
of them can be used for unauthenticated, over-the-air loading of arbitrary
Java applet code into the SIM. Proper vulnerability report describing this
(Issue 34) was also submitted to Gemalto today.
Additionally, SIM Toolkit security settings seem to be relying on the
presence of some files (directly affecting STK MSL and signature checking).
Finally, we experienced problems obtaining keys for development purposes
with respect to many Gemalto cards (such as NFC UPteq). According to our
supplier, the keys were not provided to it by Gemalto partly for security
reasons.
In that context and with respect to Gemalto response received, we have
reasons to suspect that security of Gemalto cards may rely on secrecy
of the implementation (and secrecy of the keys) rather than quality and
security of code ("security through obscurity"). Our experience with
SAT TV ecosystem and "secure" STMicroelectronics chipsets (broken to
pieces in 2012 [5] and 2018 [6], all relying on secrecy for security)
make us believe same situation may apply in Gemalto case.
The above makes independent security evaluation of Gemalto products
even more important taking into account their wide market share.
At this point, we are however unable to complete the project without
support as further explained here [7].
Thank you.
--
Best Regards,
Adam Gowdiak
---------------------------------------------
Security Explorations
http://www.security-explorations.com
"We bring security research to a new level"
---------------------------------------------
References:
[1] Gemalto
https://www.gemalto.com/
[2] Java Card project, Vendors status
http://www.security-explorations.com/javacard_vendors.html
[3] Reverse engineering Java SIM card
http://www.security-explorations.com/materials/javasim-reversing.pdf
[4] JAVA CARD CLASSIC PLATFORM SPECIFICATION 3.0.5
https://www.oracle.com/technetwork/java/embedded/javacard/downloads/index.html
[5] Security vulnerabilities of Digital Video Broadcast chipsets
http://www.security-explorations.com/materials/se-2011-01-hitb2.pdf
[6] SRP-2018-02 Exploitation Framework for STMicroelectronics DVB chipsets
http://www.security-explorations.com/ncplus_sat_general_info.html
[7] Gemalto Java SIM cards research - Call for Support
http://www.security-explorations.com/javacard_news_2.html
