Despite how nearly ubiquitous Java is in the landscape of application development, the last several years have nonetheless shown it to be limited in a number of ways. The slow but steady proliferation of Python, as well as the rise of lesser-known but still intriguing codes such as TypeScript and Rust, represent a major factor behind Java losing some of its luster.
But more than anything else, security issues have stood out as a key contributor to the decline in dominance that Java once had over so many software development, legacy modernization and digital transformation initiatives (within tech firms themselves, as well as enterprises in many other industries with in-house app development teams). Though Java can still be extremely useful in various contexts and is unlikely to simply disappear any time in the near future, the consistent discovery of significant new vulnerabilities directly related to the code remains alarming to numerous cybersecurity professionals and developers. Organizations considering using Java for their latest transformative IT projects should immediately educate themselves about these latest flaws in the language.
Chip-based IoT device vulnerability uses Java as its entry point
The internet of things connects a massive number of people and organizations all at once via a multiplicity of devices. In fact, research from IDC projects that by 2025, there will be almost 56 billion computers, smartphones, sensors and other devices around the globe connected to the IoT. Unfortunately, it's also become clear in recent years that the IoT represents a major threat vector for cyberattacks — and in one of the latest examples of this type of threat, Java is facilitating its key dangers.
According to IBM's SecurityIntelligence blog, the company's white-hat hacker team, X-Force Red, recently announced the existence of CVE-2020-15858, a vulnerability that specifically targets EHS8 modules manufactured by Thales. These components are most commonly used to optimize 3G and 4G cellular network connections for industrial control systems found throughout various segments of the manufacturing and energy sectors, and also appear in certain medical devices. If accessed by malicious or unauthorized individuals, the modules can expose any number of security credentials, including usernames, passwords, certificates and encryption keys.
The IBM team determined that the inner workings of the EHS8 systems were specifically vulnerable to incursion and exploitation as a result of their embedded Java runtime environments. Because of this, hackers could install Java "midlets" engineered to turn write-only code into plain text that can easily read, written and deleted. This unencrypted language contains the security credentials noted above, as well as other vital information ranging from product data to financial details.
It is somewhat strange that this vulnerability is only now being reported on — SecurityIntelligence published its post Aug. 19, 2020 — given that Thales claims to have had a patch for it back in February. Additionally, although the flaw can be corrected, EHS8 modules connect more than 3 billion devices each year, meaning there's a significant chance that some organizations may not have learned of the Java-based glitch and consequently updated their systems, and are therefore still at risk for attacks.
Microsoft finally corrects two-year-old glitch allowing attacks by Java-based malware
Thales and IBM deserve credit for addressing their glitch in relatively timely fashion — a claim Microsoft can't make regarding one of the flaws it corrected for its latest Patch Tuesday. Renowned cybersecurity consultant Brian Krebs explained on his blog that this vulnerability, CVE-2020-1464, was first discovered in August 2018 but only recently has a patch available.
The vulnerability is connected to Windows code-signing functionality. Until it was patched, it kept the operating system's Authenticode signature valid after any content, regardless of origin, had been added to Windows Installer files. As such, a hacker could theoretically attach a .JAR malware file, made using Java, and have valid access to the system by piggybacking onto a trusted program. Microsoft even acknowledged the flaw in January 2019 when another cybersecurity expert, VirusTotal's Bernardo Quintero, wrote a blog post about it, but didn't act to fix it until this August for reasons it chose not to elaborate upon.
Apache's quick response to Struts 2 vulnerability exception rather than rule
Many developers (and a fair number of tech neophytes) know Apache Struts due to the role it played in the massive Equifax breach of 2017. Recently, the latest model of the Java-based program was hit by a vulnerability in its Object-Graph Navigation Language evaluation, allowing it to potentially be run remotely by hackers. According to Security Boulevard, Apache quickly rectified this issue, so that all Struts users had to do to eliminate the vulnerability was update the application to its latest version.
However, the speed with which this vulnerability was resolved is not necessarily common when dealing with vulnerabilities affecting Java-built programs, as the two examples above (and numerous historical anecdotes) show. It may be best for organizations to avoid Java in their latest application development and digital transformation initiatives.