Re: log4j trivial RCE (similar to ShellShock) - "Log4Shell" CVE-2021-44228


Royce Williams
 

Important update:

All previous mitigations - based on anything other than upgrading to log4j 2.16 or entirely removing JndiLookup classes - are no longer effective mitigation.

If your vendors have not yet supplied patches that upgrade to 2.16, your best bet may be to remove the JndiLookup class.

This page from Apache itself is the best summary of the latest practical upshot of vulnerability and effective mitigation: https://logging.apache.org/log4j/2.x/security.html

For detection and mitigation on Unix-likes, this is a really good tool, based on pure shell (so highly portable), written by Yahoo's security team. By default it just detects. It has an optional flag that will make a zipped backup copy of a jar or war file, and then attempt to remove the affected class. 

    https://github.com/yahoo/check-log4j (Unix-likes only)

See my page for other mitigations - I'm updating best-effort in my spare time. My page also has other major lists you can check for your products if you haven't heard back from your vendor yet.

(Also for folks who play or have kids who do, update all Minecraft if you haven't already)

Royce

-- 
Royce Williams
Tech Solvency


On Fri, Dec 10, 2021 at 7:42 AM Royce Williams <royce@...> wrote:
This one is developing quickly, so I'll push updates here as I discover them:


-- 
Royce Williams
Tech Solvency


On Fri, Dec 10, 2021 at 7:21 AM Royce Williams <royce@...> wrote:
Summary (Dan Goodin):
Log4j takes a log message, interprets it as a URL and goes out and fetches it. It will even execute JavaScript in URLs with full privileges of the main program. Exploits are triggered inside  log messages using the ${} syntax. Easy peasy.

Who is affected:
- Servers and clients that run Java and also log anything using the log4j framework
- log4j 2.x confirmed, and probably log4j 1.x also
- Don't forget appliances that use Java server components
- Downstream projects that include log4j, including Apache Struts, Solr, etc.

Required to fully mitigate:
- Upgrade Log4j 2.15.0
- requires Java 8

Exploitation: active:

Mitigations - easiest:
- (@MalwareTechBlog): If you can't upgrade log4j, you can mitigate the RCE vulnerability by setting log4j2.formatMsgNoLookups to True (-Dlog4j2.formatMsgNoLookups=true in JVM command line).

Mitigations - official project itself (https://logging.apache.org/log4j/2.x/)
>Users of Log4j 2.10 or greater may add -Dlog4j.formatMsgNoLookups=true as a command line option or add log4j.formatMsgNoLookups=true to a log4j2.component.properties file on the classpath to prevent lookups in log event messages.
>Users since Log4j 2.7 may specify %m{nolookups} in the PatternLayout configuration to prevent lookups in log event messages.
>Remove the JndiLookup and JndiManager classes from the log4j-core jar. Removal of the JndiManager will cause the JndiContextSelector and JMSAppender to no longer function.

Mitigations - harder:
- WAF to limit exploit queries
- egress filtering to block unexpected outbound traffic

Exploit detection:

Good threads and summaries:

-- 
Royce Williams
Tech Solvency

Join nuga@groups.io to automatically receive all group messages.