One of the often-accepted truisms in cybersecurity is to ensure that all systems supporting and protecting business operations are up-to-date and current. Many cyber professionals quickly learn, however, that there are usually several good reasons for not updating corporate software or applications each time a new patch is released. Reasons for not patching key systems run the gamut from “new patches break functionality” to “lack of resources to test new patches.” While many of these reasons are sometimes initially acceptable from a security perspective, without addressing the underlying issue that delays system patching, organizations increase their risk of an exploitation or attack over time. However, with Java’s recent crypto bug, which allows attackers to bypass digital signatures, some organizations find themselves in the rare, if not questionable, position wherein ignoring Java patches and updates may have protected them from exploitation.
The recent Java exploitation, documented as CVE-2022-21449, differentiates itself from others in a few respects. The hack takes advantage of Java’s implementation of the Elliptic Curve Digital Signature Algorithm (ECDSA), a cryptograph algorithm that leverages the algebraic structure of elliptic curves over finite fields to generate encryption keys and provide greater trust of message integrity. Oftentimes, when keys are generated and used to store and/or send data, a signature validation algorithm exists, which leverages an equation that combines a signer’s public key and a hash of a message to validate the signature and thus the integrity of the affiliated data. However, starting with Java 15, a faulty implementation of ECDSA allows for the use of zero as an integer in the two-sided equation. As such, signature checking can be bypassed/negated by introducing zero to the two sides of the equation. Since zero will always equal zero, the signature is always validated.
The impact of this attack could be far-reaching, depending on its use. Specifically, Neil Madden, who discovered the vulnerability, likened the attack to blank identity cards that allow the user to bypass any security checks that leverage it. One concerning method through which this attack can be used is by bypassing SSL checks in communications. As such, it becomes a useful tool for anyone wishing to perform a potential man-in-the-middle attack against a target, or simply listen to communications. Users logging into accounts online and passing credentials that use vulnerable versions of Java are at risk.
However, not all versions of Java are susceptible to this recently revealed vulnerability. Specifically, Oracle, which owns and operates Java Standard Edition (SE), released a statement that noted only Java versions 15 and up are vulnerable. These more recent versions of Java are the ones that leverage the ECDSA equations to generate and validate the keys. Currently, all other versions of Java have proven themselves insusceptible to the exploitation. This fact provides a level of comfort for most developers who implement Java in their workflow, as over 60 percent of applications developed with Java use versions eight or 11. In this case, apparently, ignoring the newer versions of Java has acted as an inadvertent security control for most organizations.
Usually, maintaining older, often unsupported applications and tools can prove both dangerous and risky for organizations. Oftentimes, once a company, such as Oracle, discontinues updates for its applications, it signals the end for that version. Once support ends, new vulnerabilities and exploitations are more likely to be unaddressed except by enthusiasts, hobbyists and corporations with specific desires to continue leveraging the outdated product. In the case of Oracle, it ceased providing public updates for Java 8 in 2019, despite it still being the most popular version in use today. However, in this one instance, not updating to the newest versions of Java proved an unlikely security control, protecting organizations who refused to patch.