The issue of security in Java is undoubtedly a complex one, as well as being a matter that can turn rather contentious if not discussed in the right way. For one, as Jaxenter notes, developers who primarily or entirely use Oracle's open-source programming language as their code of choice for building software and web applications have likely become partial to it: They may well insist that Java is the most secure language available, particularly in comparison to its forebears like C and C++ and perhaps even in contrast to codes like Python and TypeScript (the popularity of both of which is surging in 2020).
In truth, Java certainly can be secure, but programmers using it must do so with great care to mitigate the chance of creating vulnerable software or web apps. This requires sticking to a best-practices regimen that includes regular library audits, thorough and cutting-edge encryption of libraries, constant input validation and configuration to manage application secrets, per Jaxenter.
Because Java is so widely accessible and easy to use, a fair share of the developers creating with it at any given time may not be observing all of the protocols necessary to keep their apps secure. This means at least some final products with varying degrees of vulnerability will emerge, the evidence of which we see with some regularity. Here, we'll take a look at some of the latest examples of Java flaws you'll want to know about before embarking on any digital transformation or legacy system modernization efforts that involve Java-based tools.
Apache flaw leads to Facebook breach (by a white-hat hacker)
Groovy, a language used within the Java-based Apache framework, is known as one of the more easy-to-learn Java variants. Unfortunately, Groovy's libraries were also, until recently, host to a critical vulnerability that facilitated a breach of Facebook's internal systems. According to the cybersecurity blog The Daily Swig, a Taiwan-based security researcher for DEVCORE known as Orange Tsai determined that he could gain unathenticated remote code execution permissions within Facebook due to a weakness within its third-party mobile device management program MobileIron — and the vulnerability stemmed from the MDM's use of Groovy.
As detailed on his personal blog, Tsai determined that MobileIron's URL parser and fetcher had inconsistent activity that would allow an experienced hacker to circumvent typical steps in the authentication process, "leverag[ing] the inconsistency between Apache and Tomcat to bypass the ACL control and reaccess the web service." From there, he realized MobileIron's outdated version of Groovy (anything 2.4 or below) contained a critical vulnerability, permitting him to exploit serialization and deserialization processes and gain full RCE.
Both Facebook and MobileIron — the latter of which offers MDM services to more than 15,000 organizations around the globe — are fortunate that it was a white hat like Tsai who found the flaw rather than a malicious web actor. He reported it to both organizations promptly. Although this specific vulnerability was neutralized, it serves as an object-lesson in how dangerous it is if developers fail to update Java code libraries regularly.
Tycoon remains at large
Earlier this year, a joint BlackBerry-KPMG report revealed the existence of a malware strain that researchers dubbed "Tycoon," according to TechCrunch. Users of this malware, which appears to the untrained eye to be an innocuous file in Java's JIMAGE format, can gain control of targeted Windows and Linux systems via remote desktop protocols and virtual private networks and escalate their privileges to the highest levels. This allows for the potential theft or encryption of data, and hackers can even disable backups so victims have no contingency for data restoration after the hack.
SecurityBoulevard recently cited Tycoon as one of its top five ransomware attacks for 2020 and 2021 — not as a mere ranking, but to warn that the malware remains unpatched and is still being used against various organizations. Thus far, most targets have been in the education and software development sectors, and its usage rate has dropped, but users of malware as dangerous as Tycoon can't be expected to stick to any pattern. The only way to virtually guarantee safety from this cyberattack type is to avoid using JIMAGE and Java Runtime Environment, which may be easier said than done.
Examining Java's low rank on Kaspersky report
Global cybersecurity firm Kaspersky recently issued its latest "IT threat evolution" report, covering Q2 of 2020. At first glance, proponents of Java would say it looks good for the language, as vulnerabilities within the code only accounted for 4.36% of the exploits leveraged against Kaspersky users. (Microsoft Office vulnerabilities were the vast majority — 72.29% of exploits.)
Yet this result does not really diminish the security issues regarding Java. Even setting aside that plenty of organizations aren't Kaspersky customers (diminishing the value of the sample size), the issue with flaws affecting Java-based software and apps is that they are often severe. The Equifax breach is the biggest example, but Tycoon could be similarly destructive, and the NetWeaver zero-day bug from earlier in the year, while patched, could be reverse-engineered and retooled for further attacks, according to the US-CERT team. Again, it may be most beneficial to simply avoid using Java as much as possible.
Here at the Inventu Corporation, we equip organizations of all sizes with a revolutionary terminal emulation tool called Inventu Viewer+, a high performance emulation solution that is built with C at its core. This solution allows developers to craft reliable and safe software using clean HTML and JavaScript hosted on secure Windows servers. All in all, Inventu Viewer+ supports streamlined IT modernization and meets employer and staff expectations in a way that feels both familiar and simple. Contact us today or review our extensive product catalog to see how Inventu can help you rid your servers of unsafe Java with a server product built over decades in the ever-reliable C language.
