Log4Shell. Thinking of winding down for Christmas? Here is another dumpster fire to attend to...

A vulnerability in a widely used logging library is becoming a full-blown IT security nightmare affecting digital systems across the internet. If exploited, the vulnerability allows remote code execution on vulnerable servers, giving an attacker the ability to import malware that would compromise machines. The vulnerability, now going by the name Log4Shell, and the flaw could have serious repercussions worldwide

The United States Cybersecurity and Infrastructure Security Agency issued an alert about the vulnerability on Friday, as did Australia's CERT. Here in New Zealand, the government cybersecurity organisation alert noted that the vulnerability is reportedly being actively exploited.

https://www.cert.govt.nz/it-specialists/advisories/log4j-rce-0-day-actively-exploited/

The exploit was first seen on sites hosting Minecraft servers, which discovered that attackers could trigger the vulnerability by posting chat messages. A tweet from security analysis company GreyNoise reported that the company has already detected numerous servers searching the internet for machines vulnerable to the exploit.

What is log4j

Log4j is an open-source Java logging library, used by applications and services across the internet, and while the programming language is less popular with consumers, it's still in very broad use in enterprise systems and web applications. Log4j is part of the Apache Logging Services, a project of the Apache Software Foundation, and is one of several Java logging frameworks.

Logging is a process where applications keep a running list of activities, they have performed which can later be reviewed in case of error. Nearly every network security system runs some kind of logging process, which gives popular libraries like log4j an enormous reach.

How can it be exploited

All an attacker has to do to exploit the flaw is strategically send a malicious code string that eventually gets logged by Log4j version 2.0 or higher. The exploit lets an attacker load arbitrary Java code on a server, allowing them to take control.

https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2021-44228

Minecraft screenshots circulating on forums appear to show players exploiting the vulnerability from the Minecraft chat function. On Friday, some Twitter users began changing their display names to code strings that could trigger the exploit. Another user changed his iPhone name to do the same and submitted the finding to Apple. Researchers have advised that this approach could also potentially work using email.

The situation underscores the challenges of managing risk within interdependent enterprise software. Many organisations will need to develop their own patches or will be unable to patch immediately because they are running legacy software, like older versions of Java. Its not just straightforward just to patch live services because if something goes wrong an organisation could compromise their logging capabilities when they need them the most ...such as watching for attempted exploitation.

Mitigation

Mitigations are available for versions of log4j 2.10.0 and up. Version 2.15.0 is not vulnerable by default. Note that there may be other dependencies, such as your Java version, that need to be updated before you can upgrade. Fixing the vulnerability may not be straightforward, but it is urgent.

According to the Apache log4j project, if you are unable to upgrade, for whatever reason, you can mitigate this vulnerability in version 2.10.0 or higher by switching log4j2.formatMsgNoLookups to true. This can be done by adding ‐Dlog4j2.formatMsgNoLookups=True to the JVM command for starting the application.

https://logging.apache.org/log4j/2.x/security.html

Unfortunately, there is little, if anything, that users of affected systems can do to make themselves less vulnerable to the consequences. No doubt many systems will be affected and system administrators will want to treat anomalies with extreme caution.

For versions older than 2.10.0 that can’t be upgraded, these mitigation choices have been suggested:

• Modify every logging pattern layout to say %m{nolookups} instead of %m in your logging config files (here are Apache’s details); or,
• Substitute a non-vulnerable or empty  implementation of the class  org.apache.logging.log4j.core.lookup.JndiLookup, in a way that your  classloader uses your replacement instead of the vulnerable version of  the class. Refer to your application’s or stack’s classloading  documentation to understand this behavior; or
• Users should switch  log4j2.formatMsgNoLookups to true by  adding:”‐Dlog4j2.formatMsgNoLookups=True” to the JVM command for  starting the application.