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:
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 JndiLookup
class 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.
Identify vulnerable software / devices via.
asset inventories.
software bill of material manifests.
software build pipeline dependency manifests (e.g. Maven etc.)
vendor bulletins (see below).
file system discovery (see below) on Windows / Linux to identify class files.
log file analytics to identify log4j like entries.
exploitation (see below).
Software developers should
Ensure they strictly enforce via Gradle and similarly non vulnerable versions of log4j to mitigate transient dependencies
Patch vulnerable software for which patches are available (see vendor bulletins).
Hot patch also exists (see below)
Limit network egress from hosts where vulnerable software exists when possible.
Mitigate through configuration changes.
Ensure protective monitoring via (note: expect extensive scanning)
Network for remote class loading
On host for remote class loading
On host for unexpected command execution
Update / Patch
Vendor patch is available here - although note they have removed all releases.
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()
"
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
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)
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
Further Reading
National Advisories:
Third Party Advice and Analysis:
https://isc.sans.edu/forums/diary/RCE+in+log4j+Log4Shell+or+how+things+can+get+bad+quickly/28120/
https://blog.cloudflare.com/inside-the-log4j2-vulnerability-cve-2021-44228/
https://attackerkb.com/topics/in9sPR2Bzt/cve-2021-44228-log4shell/rapid7-analysis
https://msrc-blog.microsoft.com/2021/12/11/microsofts-response-to-cve-2021-44228-apache-log4j2/
Create your profile
Only paid subscribers can comment on this post
Check your email
For your security, we need to re-authenticate you.
Click the link we sent to , or click here to sign in.