Poland-based cybersecurity research firm Security Explorations claims to have identified nearly 20 vulnerabilities in Oracle’s Java Card, including flaws that could be exploited to compromise the security of chips using this technology.
Oracle’s Java Card technology is designed to provide a secure environment for applications running on smart cards, SIMs, embedded secure elements and other trusted devices that have limited memory and processing capabilities. Oracle says the technology is deployed on nearly six billion devices every year, including in the financial, telecoms, and government sectors.
Security Explorations says it has discovered 18 vulnerabilities in the reference Java Card implementation from Oracle, along with one flaw that is specific to smart cards made by Gemalto, whose products use Java Card technology. The flaws were reproduced on Gemalto’s 3G USIMERA Prime and GemXplore 3G V3.0-256K SIM cards, and Java Card 3.1 software, which Oracle released in January 2019.
According to the company, the vulnerabilities can be exploited to “break memory safety of the underlying Java Card VM” and gain full access to the card’s memory, break the applet firewall, and possibly even achieve native code execution. The Java Card VM should normally protect the card environment and applications from malicious applets.
However, exploitation of the flaws, which involves loading a malicious applet onto the targeted card, requires knowledge of the encryption keys used by the card issuer, or the use of some other method that could involve vulnerabilities in the card operating system, installed applications or exposed interfaces.
“These scenarios cannot be excluded though as demonstrated in the past,” Adam Gowdiak, CEO and founder of Security Explorations, told SecurityWeek. “In 2013, Karsten Nohl discovered a crypto flaw affecting a wide range of SIM cards that made it possible to remotely discover keys required to load Java applets into cards (also from the remote). In 2015, there was news of an alleged hacking of Gemalto (a major SIM card vendor) by NSA and GCHQ. The intel agencies’ hack apparently targeted the crypto keys of Gemalto SIM cards.”
Gowdiak says that while there is no reason to panic, the impact of the Java Card flaws discovered by his company would become more serious if someone finds an easy way to deploy Java applications on SIM cards — either remotely through NFC or via SMS messages used by the SIM toolkit or device management interfaces, or by having physical access to the SIM.
Describing theoretical attack scenarios, Gowdiak explained, “In the worst case scenario, one can imagine a malicious Java application modifying targeted card operations (banking, telecom or identity) in such a way that a stealthy and persistent backdoor could be installed into the card. Our analysis of selected SIM cards from Gemalto indicate that development of such a backdoor should be possible.”
“For banking cards / transportation cards, there is a potential for a malicious applet to interfere with payments conducted with the use of a card or to get access to secret keys deployed into it,” he added.
Security Explorations has only provided a brief description of the impact of its findings, but believes this work can pave the way for future research in this field.
Security Explorations sent its findings to Oracle and Gemalto on March 20 and both companies have confirmed receiving the report. Gowdiak says his company does not give vendors a specific deadline to release patches before details of the vulnerabilities are disclosed, considering that some issues, particularly ones that impact the architecture of a product, can take a significant amount of time to fix. However, the company does expect vendors to confirm or deny the existence of the issues and provide periodic status reports.
UPDATE. A few hours after this article was published, Security Explorations informed SecurityWeek that it had reported six additional vulnerabilities to Oracle.
Related: Security Explorations Launches New Research Program
Related: Oracle Reissues Patch for Two-Year-Old Java Flaw