Bluepurple Pulse: Log4J2 / Log4Shell Special

To be meta is to be better..

Welcome to a special edition drawn from the meta thread on /r/blueteamsec - https://www.reddit.com/r/blueteamsec/comments/rd38z9/log4j_0day_being_exploited/

The thread continues to be updated on Reddit, below are the salient points as of 7:30 UTC on Sunday December 12th.

Hope it helps and have a lovely weekend.

Ollie

Headlines

Log4j2 open source logging framework for Java is subject to a vulnerability which means untrusted input can result via LDAP, RMI and other JNDI endpoints in the loading and executing of arbitrary code from an untrusted source.

This vulnerability was disclosed last week with active knowledge and exploitation following very quickly thereafter.

Wide spread exploitation and scanning is currently occurring by a range of actors including researchers, nation states, coin miners and other criminal enterprises as well as bug bounty participants.

Details

The below are the details of the vulnerability specifically:

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

• https://issues.apache.org/jira/browse/LOG4J2-3201

• https://nvd.nist.gov/vuln/detail/CVE-2021-44228

Description

Apache Log4j2 < 2.15.0 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 behaviour has been disabled by default.

Mitigation

In releases >=2.10, this behaviour can be mitigated by setting either the system property log4j2.formatMsgNoLookups or the environment variable LOG4J_FORMAT_MSG_NO_LOOKUPS to true

For releases from 2.0-beta9 to 2.10.0, the mitigation is to remove the JndiLookupclass from the classpath: zip -q -d log4j-core-*.jar org/apache/logging/log4j/core/lookup/JndiLookup.class

Recommendations

The below are the recommendations I am giving with regards to discovery, remediation and response.

1. Identify vulnerable software / devices via.

   1. asset inventories.

   2. software bill of material manifests.

   3. software build pipeline dependency manifests (e.g. Maven etc.)

   4. vendor bulletins (see below).

   5. file system discovery (see below) on Windows / Linux to identify class files.

   6. log file analytics to identify log4j like entries.

   7. exploitation (see below).

2. Software developers should

   1. Ensure they strictly enforce via Gradle and similarly non vulnerable versions of log4j to mitigate transient dependencies

3. Patch vulnerable software for which patches are available (see vendor bulletins).

   1. Hot patch also exists (see below)

4. Limit network egress from hosts where vulnerable software exists when possible.

5. Mitigate through configuration changes.

6. Ensure protective monitoring via (note: expect extensive scanning)

   1. Network for remote class loading

   2. On host for remote class loading

   3. On host for unexpected command execution

Update / Patch

Vendor patch is available here - although note they have removed all releases.

• https://github.com/apache/logging-log4j2

A third party hot patch has also been produced - it is a simple tool which injects a Java agent into a running JVM process. The agent will patch the lookup() method of all loaded org.apache.logging.log4j.core.lookup.JndiLookup instances to unconditionally return the string "Patched JndiLookup::lookup()"

• https://github.com/corretto/hotpatch-for-apache-log4j2

• https://github.com/simonis/Log4jPatch

Affected products

Extensive and incomplete is the current understanding of the attack surface. Expect a long tail of discovery and patching to be required.

Vendor Advisories for products affected by log4j issues

SwitHak is maintaining a list of vendor bulletins here

Attack surface

Beyond the above other known vulnerable services / products which use log4j2

• https://github.com/YfryTchsGD/Log4jAttackSurface

• https://mvnrepository.com/artifact/log4j/log4j/usages

Finding vulnerable hosts and systems

There are various techniques which can be used to discovery vulnerable hosts. Below is a subset which will support discovery activities.

File hashes

File hash lists for affectedJava class files (.jar) have been generated here:

https://github.com/mubix/CVE-2021-44228-Log4Shell-Hashes

Filesystem discovery

The following commands can be used to discover potentially vulnerable Java class files (.jar)

PowerShell

gci 'C:\' -rec -force -include *.jar -ea 0 | foreach {select-string "JndiLookup.class" $_} | select -exp Path

Linux

find / 2>/dev/null -regex ".*.jar" -type f | xargs -I{} grep JndiLookup.class "{}"

Log4j detector

A third party tool has been released written in Java

https://github.com/mergebase/log4j-detector

Active discovery

Using various penetration testing style techniques it may be possible to detect vulnerable hosts/systems through active exploitation.

• ActiveScan++ 1.0.23 added Log4Shell detection for Burp Proxy

• Thinkst Canary token can be used

• Online reflective vulnerability tester (note they will gain aggregate data so check terms and conditions)

• A scanning script has been released

Exploitation Detection

Please note that exploitation detection may be fragile. It is recommend where possible you aim to detect both the exploitation attempt (which will be very noisy currently) but also the subsequent post exploitation loading of a remote Java class file.

Below are links to various signatures.

• https://gist.github.com/Neo23x0/e4c8b03ff8cdf1fa63b7d15db6e3860b

• https://github.com/Neo23x0/signature-base/blob/master/yara/expl_log4j_cve_2021_44228.yar

• https://github.com/SigmaHQ/sigma/blob/master/rules/web/web_cve_2021_44228_log4j.yml

• https://github.com/SigmaHQ/sigma/blob/master/rules/web/web_cve_2021_44228_log4j_fields.yml

• https://www.splunk.com/en_us/blog/security/log-jammin-log4j-2-rce.html

• https://github.com/Neo23x0/log4shell-detector

Further Reading

National Advisories:

• https://www.jpcert.or.jp/at/2021/at210050.html

• https://www.ncsc.gov.uk/news/apache-log4j-vulnerability

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

Third Party Advice and Analysis:

• https://www.lunasec.io/docs/blog/log4j-zero-day/

• https://isc.sans.edu/forums/diary/RCE+in+log4j+Log4Shell+or+how+things+can+get+bad+quickly/28120/

• https://www.randori.com/blog/cve-2021-44228/

• https://www.rumble.run/blog/finding-log4j/

• https://www.veracode.com/blog/security-news/urgent-analysis-and-remediation-guidance-log4j-zero-day-rce-cve-2021-44228

• https://bishopfox.com/blog/log4j-zero-day-cve-2021-44228

• https://blog.cloudflare.com/inside-the-log4j2-vulnerability-cve-2021-44228/

• https://github.com/advisories/GHSA-jfh8-c2jp-5v3q

• https://www.docker.com/blog/apache-log4j-2-cve-2021-44228/

• https://attackerkb.com/topics/in9sPR2Bzt/cve-2021-44228-log4shell/rapid7-analysis

  • https://attackerkb.com/topics/in9sPR2Bzt/cve-2021-44228-log4shell/

• https://msrc-blog.microsoft.com/2021/12/11/microsofts-response-to-cve-2021-44228-apache-log4j2/

• https://www.rapid7.com/blog/post/2021/12/10/widespread-exploitation-of-critical-remote-code-execution-in-apache-log4j/