The multifaceted value of IT resilience	Java faces major security questions
Oracle patches major Java flaw, but platform still vulnerable to other risks
There's no denying the environment of near-ubiquity that Oracle has created for Java, with at least 10 million developers around the world using it for the creation of client-server web applications and various other platforms. However, it's also become increasingly clear that the open-source programming language remains bedeviled by a sizable number of vulnerabilities across the numerous programs it has been used to create, some of them critical. After all, the infamous 2017 data breach of Equifax's servers, which exposed the personally identifiable financial information of more than 130 million people in the U.S., is now widely understood to have stemmed from a flaw in the Apache Struts component of multiple Java-based Oracle applications.
With the software development firm recently announcing the issuance of patches for nearly 300 vulnerabilities across its product portfolio, it might seem as if Oracle has learned from its security struggles of the past few years. But new situations of potential weak spots in Java-powered applications keep showing up even after protective updates hit the market. Companies considering legacy application modernization for their IT infrastructure might need to think long and hard about whether they want to engage with Java at all.
Biggest vulnerability patched by Oracle was three years old
According to eWeek, Oracle addressed all of the currently known Java flaws through the April 17, 2019 release of the firm's newest Quarterly Patch Update. One of them is a deserialization vulnerability within the Apache Commons FileUpload library, classified as CVE-2016-1000031. Deserialization flaws, which led to the Equifax breach, are classified as highly critical vulnerabilities. This one existed in 19 separate Oracle products, and ordinarily might not be drawing the attention of the tech news media – but for the fact that it was first identified three years ago.
Apostolos Giannakidis, a security architect with Waratek, said in an interview with eWeek that the gap between identification and final patch release could stem from certain factors outside of Oracle's direct control, such as the necessity of delicate application redesign and the chain reaction across platforms that a single error in the glitch-fixing process might cause. At the same time, he also made a point of emphasizing how dangerous the flaw was.
"The vulnerability exists in the DiskFileItem component that can be manipulated in such a way that when it is deserialized, it can write or copy files to disk in arbitrary directories," Giannakidis told the news provider. "Remote attackers could exploit this vulnerability to take complete control of the affected systems."
It took three years for Oracle to fix a major deserialization flaw in its Java-based Apache Commons library.
Among the 297 errors discovered and patched in the Quarterly Patch Update, 53 of them earned classification as critical vulnerabilities due to scores of 9.0 or greater on the Common Vulnerabilities Scoring System. Oracle issued an advisory regarding the details of the patch, and some of its wording could be perceived as blaming users for the security breaches.
"Oracle continues to periodically receive reports of attempts to maliciously exploit vulnerabilities for which Oracle has already released fixes," the statement explained. "In some instances, it has been reported that attackers have been successful because targeted customers had failed to apply available Oracle patches."
New malware targeting Java Servlet
As far as the overall question of Java vulnerabilities is concerned, the crux of the matter for so many in the field of software development – and the overall tech universe – is that even as the established flaws of the programming language and its associated applications are being fixed, new bugs are showing themselves. One such discovery happened earlier in April, about two weeks before the Oracle patch came out. According to ZDNet, this new malware, called Xwo by the researchers at AT&T Alien Labs who identified it, targets default credentials for Java Servlet's open-source Tomcat implementation. It also goes after login credentials and other sensitive information associated with services like FTP, MySQL, PostgreSQL, MongoDB, Redis and Memcached.
Infosec professionals think that Xwo may be the brainchild of those responsible for MongoLock and X Bash malware strains, both of which were also written with Python and share similarities in coding style. Because the malware's main objective is scanning for and storing exposed credentials for these services, rather than stealing from compromised organization's sites via cryptocurrency mining or deploying ransomware – unlike either of Xwo's counterparts – analysts are not quite sure what its intent is just yet.
That said, there exists a strong suspicion that Xwo is performing reconnaissance of sorts – scouting in advance to weaken targets' defenses before a full-fledged cyberattack takes place, one wreaking considerable havoc. What is clear is where the information that Xwo has collected is going – a C2 server hosted via CloudFlare domains. CloudFlare terminated the domains once their malicious intent became clear, but in all likelihood the actors behind this malfeasance will find new hosts for their work.
Another Java vulnerability – not yet patched – centers around a malware threat targeting the Tomcat Java Servlet.
Tom Hegel, a security researcher at Alien Labs, elaborated on the potential dangers of the malware.
"This malware is entirely scanning-based. It will attempt to identify valuable targets and report back the details to a C2 server," Hegel told ZDNet. "It is our belief that this insight is then used by the attacker for further attacks outside of Xwo. "While Xwo steps away from a variety of malicious features…such as ransomware or exploits, the general use and potential it holds can be damaging for networks around the globe."
Hegel further explained to the news provider that it would be wise for network owners to avoid making use of default service credentials whenever possible due to the severity of this threat. Additionally, Alien Labs made a list of Xwo's Indicators of Compromise available to the public on its website.
"Xwo may not be a major shift in the adversary changing tactics, but rather them experimenting with different capabilities. Based on our assessment of the relation to XBash and MongoLock, the adversary has historically been diverse in their toolset," Hegel said.
Legacy modernization is certainly a worthwhile goal for your organization to pursue. But it's critical that you exercise great care while doing so. Choosing to take cybersecurity less seriously than you should can be an extremely costly mistake. Also, you may end up inadvertently creating vulnerabilities in your IT infrastructure simply by using application frameworks based in Java or other coding types that can easily be compromised by cyberattackers.