Recently, a cybersecurity research firm found several vulnerabilities in Oracle’s Java card technology. Read on to know more about it…
Recently, a Poland-based cybersecurity research firm Security Explorations 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.
The cybersecurity research firm, Security Explorations revealed that 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 Security Explorations, 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.
According to a posting on Full Disclosure, security researcher Adam Gowdiak said that due to certain architectural choices from the past, it’s hard to perceive Java Card technology in terms of security. “There are ways for malformed applications loaded into a vulnerable Java Card to easily break memory safety. Such a breach directly leads to the security compromise of a Java Card VM, applet firewall breach and jeopardises security of co-existing applications,” he said.
“In some cases, whole card environment can be compromised, but that’s dependant on the underlying OS / processor architecture (ie presence of the flat address space, isolation between tasks).”
He said that he was able to verify 18 of the issues in the environment of the most recent Java Card 3.1 software from Jan 2019 (Oracle Java Card VM reference implementation in the form of a simulator). “One issue was specific to Gemalto cards. These cards could not be immediately exploited with the use of our “favorite” issue found in Oracle reference implementation, so there was a need to find and use another one (which we did),” said Gowdiak.
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.”