log4shell: how to analyse and mitigate

This post is about two security vulnerabilities reported on log4j 2.x framework: CVE-2021-44228, scored 10 of 10 points in CVSS VERSION 3.1 RISK, and CVE-2021-45046, scored 3.7 points.

Determine affection

1. Use a vulnerability scanner
   It’s best to scan hosts company wide on a regular basis. I do not have experience here, use wikipedia as a (neutral) starting point. There is a useful list of scanners provided by OWASP (Open Web Application Security Project).
   To date, almost 166k CVE have been reported. The next vulnerability in software your are using will be reported sooner or later. It’s recommended to use a capable vulnerability scanner to landscape affection.
2. Use log4j2-scan
   “log4j2-scan is a single binary command-line tool for CVE-2021-44228 vulnerability scanning and mitigation patch. It also supports nested JAR file scanning and patch. It also detects CVE-2021-45046 (log4j 2.15.0) and CVE-2021-4104 (log4j 1.x) vulnerabilities.”
   Download here
   Example:
   Analysing log4j on applications folder on mac os% java -jar /tmp/logpresso-log4j2-scan-1.4.0.jar /Applications
Logpresso CVE-2021-44228 Vulnerability Scanner 1.4.0 (2021-12-15)
Scanning directory: /Applications
[*] Found CVE-2021-44228 vulnerability in /Applications/cnlabSpeedTest.app/Contents/Java/log4j-core-2.8.1.jar, log4j 2.8.1
[*] Found CVE-2021-45046 vulnerability in /Applications/SQLDeveloper.app/Contents/Resources/sqldeveloper/sqldeveloper/lib/log4j-core.jar, log4j 2.15.0
Running scan (9s): scanned 13817 directories, 130151 files, last visit: /Applications/Microsoft Excel.app/Contents/Frameworks/mso99.framework/Versions/A/Resources/mso_intl.bundle/Contents/Resources/es.lproj
Running scan (20s): scanned 25665 directories, 272045 files, last visit: /Applications/Microsoft PowerPoint.app/Contents/Frameworks/Chart.framework/ResourcesScanned 26463 directories and 276474 files
Found 2 vulnerable files
Found 0 potentially vulnerable files
Completed in 20.35 seconds
3. Find log4j jar files
   This is a fast, but not reliable method as log4j could simply be in a renamed jar file or nested. A jar file is a zip archive.
   1. As root/administrator, search for log4j jar filesLinux, Solaris, AIX, Mac OS, …:
      find / -name *log4j*Windows
      dir /s /b <folder><pattern>
   2. Check version used. if below 2.16, you are affected:
      zip -p <jarfile> META-INF/MANIFEST.MF

How to mitigate?

Disable JNDI lookups using the following parameter when startup a java application:
-Dlog4j2.formatMsgNoLookups=true
Most Java application need to use properties at some point, generally to store simple parameters as key-value pairs, outside of compiled code. And so the language has first class support for properties – the java.util.Properties – a utility class designed for handling this type of configuration files. Key-value pairs can be loaded from properties files. Popular file endings are .properties or .xml. As long as a file’s content meet properties file format requirements, it can be parsed correctly by Properties class.

So usually, look for a java.properties file to add above parameter. Example to start a jar file:
<JAVA JRE HOME>/bin/java -Dlog4j2.formatMsgNoLookups=true <additional parameter> <jar-file>

Example: Oracle Unified Directory

It seems Oracle is still analysing the situation. I could not do mitigation according to official vendor information Doc ID 2827793.1, because JndiLookup.class was not present. Personally, I think deleting java classes is suboptimal as it could lead to errors in logfiles and false positives in monitoring.
I modified Java startup parameter to mitigate:

1. Edit
   <OUD instance home>/config/java.properties
2. Add additional parameter:
   start-ds.java-args=-Dlog4j2.formatMsgNoLookups=true
3. Activate:
   <OUD instance home>/bin/dsjavaproperties
4. Restart OUD
5. Check if OUD started using parameter
   ps -ef | grep Dlog4j2.formatMsgNoLookups

I’m looking forward for an official patch, which I will apply on test environment first.

log4shell & Oracle software

Please check this webpage on a regular basis.

Log4j 1.x

Log4j 1.x is not affected by above CVEs, but others. And it’s end of live, consider migrating to a version greater/equal 2.16.x

Cet article log4shell: how to analyse and mitigate est apparu en premier sur Blog dbi services.