Critical Log4j Vulnerability Hits Everything, Including the IBM i Server
December 15, 2021 Alex Woodie
Hackers gave themselves an early Christmas present this year with a critical security flaw in Log4j, a popular logging framework that is used across many programs, including some that run on IBM i. IBM i shops are encouraged to take this flaw very seriously, as the vulnerability already is being actively exploited in the wild. However, finding where Log4j exists in your stack is not always simple, which makes this particular flaw particularly nasty.
The Log4j zero-day vulnerability, which was disclosed last week by security researchers with CERT New Zealand, was logged into the National Vulnerability Database as CVE-2021-44228. It scored perfect 10 out of 10 on the CVSS v3 rating scale (although Nadia Comăneci will be happy to know it landed a mere 9.3 on the older CVSS v2 scale).
The flaw, which exists in Log4j versions 2.0 and 2.14.1, gives cybercriminals the ability to execute arbitrary code on all impacted systems by sending malicious code to the Log4j queue. Security experts say it’s a relatively easy flaw to exploit, and attackers do not need to be authenticated to exploit it.
The flaw, which also goes by “LogJam” and “Log4Shell,” should be considered “a severe threat to IBM i systems,” says Shmuel Zailer, an IBM i security expert and the CEO of Raz-Lee Security.
“The peaceful ‘write to log’ API can be circumvented to run commands,” Zailer tells IT Jungle via email. “All that is needed is to make [the] log a special structure of information. Log4j would then interpret the contents of the messages, fetch commands from remote systems, and run them.”
A fix for LogJam has been released by the Apache Software Foundation, which oversees the Log4j project. System administrators are encouraged to upgrade their systems to Log4j-2.15.0-rc1 to mitigate the issue. However, the Java-based library can be embedded in other applications, which complicates the issue for administrators.
A critical flaw was discovered in the Log4j framework.
“IBM i shops should be concerned since there is a lot of Java used by vendors’ applications,” writes Tony Perera, the CEO of IBM i security software developer Trinity Guard. “Fortunately, we don’t use Java, so Trinity Guard products are not vulnerable to this attack.” Zailer confirms Raz-Lee’s iSecurity GUI is written in Java, but it does not use Log4j at all, either when it is used on the desktop or when it runs in a Web server. As such, no new release is needed
HelpSystems is currently analyzing its software to see if there are vulnerabilities, says Robin Tatam, an IBM i security expert with the company. “Not all of those [IBM i] shops are impacted but actively assessing the risk is always the best approach, and critical if Java applications are known to be running,” he tells IT Jungle. “Folks can then determine if its viable to upgrade to a later Log4J version as well as disable Log4J lookup functionality.”
Jesse Gorzinski, IBM’s business architect for open source for IBM i and its point man for Java, told IBM i shops to focus on their own Java-based applications and their dependencies– “especially anything that external entities can feed data to,” he tweeted, “Unfortunately resolution is not easy. If you are running third party Java apps, solicit the vendor for a patch.”
IBM is a big Java shop, and uses the programming language throughout its products. IBM WebSphere and the Tomcat Web server are both Java-based, and are vulnerable to LogJam attacks. On Monday, IBM issued a security bulletin for WebSphere Application Server 8.5 and 9.0 running on all supported platforms, including IBM i. (The HTTP Server for IBM i — the one developed by Apache — is written in C and is not impacted.)
“IBM is continuing a product-by-product analysis for Log4j impacts,” the company wrote in its PSIRT blog post on December 12. “If an IBM Software or Systems product is impacted, there will be a bulletin posted on this blog as a remediation or fix becomes available.”
The risk posed by LogJam is so great that Scott Forstie, the IBM i business architect for the Db2 database, quickly put together a SQL query to help IBM i shops find where Log4j may be embedded in their IBM i software stacks. The query automatically finds objects in the IFS that have the string “log4j” in their name. He shared the details on his GitHub page.
Remediating the Log4j flaw is going to require a lot of this.
IBM i community members also shared tips on how to remediate Log4j problems on discussion boards, including on Ryver and MIDRANGE-L. Many users have shared little scripts they have created to help flush out the Log4j code. While searching for .JAR files is a good start, experts recommend that users scour .EAR and .WAR files as well for the Log4j library, since developers can sometimes repackage Java code in other libraries.
Notes and Domino generally are not impacted. But according to this blog post from HCL Software (which develops and maintains the software now), there is an optional extension to Notes-Domino that is impacted by the flaw. Undoubtedly, the number of applications susceptible to the LogJam flaw is going to grow in the weeks and months to come.
The flaw is being actively exploited now. Since the flaw was first reported Friday, December 10, the number of attacks exploiting the flaw has exceeded 800,000, Check Point Software Technologies wrote in a blog post.
“Since we started to implement our protection we prevented over 1,272,000 attempts to allocate the vulnerability, over 46 percent of those attempts were made by known malicious groups,” the firewall and network security device maker wrote in its blog. “It is clearly one of the most serious vulnerabilities on the internet in recent years, and the potential for damage is incalculable.”
Check Point Research documented more than 60 variants of the Log4j attack in less than 24 hours after it was first disclosed.
The Log4j flaw is the cybersecurity’s “Fukushima Moment,” declared security expert Renaud Deraison in a Tenable blog post on December 13. Just as the impacts of the 2011 tsunami and partial nuclear meltdown continue to be felt today in the Japanese prefecture, so too will the impacts of LogJam on the wider IT community.
“We’re discovering new apps every minute which use Log4j in one way or another,” Deraison wrote. “It affects not only the code you build, but also the third-party systems you have in place. Everything from the new printer you’ve bought for the office to the ticketing system you’ve just deployed is potentially affected by this flaw. Some affected systems may be on premises, others may be hosted in the cloud but no matter where they are, the flaw is likely to have an impact.”
Specifically, Deraison cited two variables that could supercharge the impact of LogJam and extend its impacts into the future: the way organizations generate and store huge amounts of log data, and the reliance on open source software to build applications.
“The Apache Log4j flaw shines a bright light on the risky practice of relying on open-source code libraries to build enterprise-scale applications,” he wrote. “This dependence on what is effectively a wild, wild west of code libraries will continue to leave organizations vulnerable until they invest the time and resources needed to make them more secure.”
In addition to the LogJam flaws, IBM this week also patched five flaws impacting the open source components used in Rational Developer for IBM i (RDi). The patches, which range in severity from 6.7 to 8.2, stem from vulnerabilities recently discovered in OpenSSL and Node.js. You can read about them here.
RELATED STORIES
Security Threats, They Are a Changin’
