Dec 14, 2021 14:45:00

A cheat sheet that summarizes how to deal with the Java / Log4j library vulnerability 'Log4Shell' is being released, and the affected products are also revealed at a glance.

Royce Williams , who works for cyber security company Alaskan Cyber Watch , has released a cheat sheet about the zero-day vulnerability 'Log4Shell ' discovered in Java's log output library Log4j. The cheat sheet is updated from time to time, and it is useful because it also summarizes measures and workarounds to protect yourself from Log4Shell exploits, products affected by Log4Shell and services that have already announced that measures have been taken. ..

Tech Solvency: The Story So Far: CVE-2021-44228 (Log4Shell log4j vulnerability).
https://www.techsolvency.com/story-so-far/cve-2021-44228-log4j-log4shell/

The zero-day vulnerability 'Log4Shell' is summarized in the following article.

Why does the vulnerability 'Log4Shell (CVE-2021-44228)' found in Java's Log4j library have a major impact on the world? --GIGAZINE

Looking at the ' Remediation ' on the cheat sheet, the countermeasures and workarounds are summarized as follows.

◆ Direct measures
-Upgrade Log4j to version 2.15.0 or later. However, to use Log4j version 2.15.0 or later, you need to upgrade the execution environment to Java 8.
-Apply 'Restrict access from JNDI to LDAP server ' merged with Log4j on GitHub.
-Delete or rename JndiLookup.class.
-If it depends on trustURLCodebase = false, update Log4j immediately regardless of Java version.

◆ Workarounds offered by Apache
-Log4j version 2.10 or later users can add '-Dlog4j2.formatMsgNoLookups = true' as a command line option or add 'log4j2.fatormatMsgNoLookups = true' to log4j2.component.properties on the classpath to log the event. Prevent message searches.
-Users with Log4j version 2.7 or later can prevent event log messages from being searched by setting '% m {nolookups}' in PatternLayout.
-Delete the JndiLookup and JndiManager classes from log4j-corejar. However, be aware that if you remove JndiManager, JndiContextSelector and JMSAppender will not work.

◆ Simple workaround
-If Log4j cannot be upgraded, execute -Dlog4j2.formatMsgNoLookups = true on the command line of the Java virtual machine and set log4j2.formatMsgNoLookups to true.
・ Use Cloudflare. However, please note that it is only a partial measure because it only blocks JNDI Lookup among HTTP requests.

◆ Workaround
-Restrict exploit queries.
-Perform egress filtering to block unexpected outbound traffic and block transmissions from non-trusted IP addresses.
-Use the vaccine approach 'Logout4Shell ' provided by cyber security company Cybereason. This is a patch that uses Log4Shell to fix Log4Shell, so to speak, 'control poison with poison'.
-Apply the hot patch provided by AWS to the Java virtual machine.
-Apply log4j-jndi-be-gone .
-Use Nginx and LUA scripts provided by the Swiss ISP Infiniroot.
· Block domains that are reported to have run exploits.
-Use the web application firewall (WAF) developed by Cloudflare and Google Cloud.

In the item 'Affected (and unaffected) products ', 'Products that were previously vulnerable but have announced that they have been patched now' and 'Products that have been confirmed to be affected by Log4Shell depending on the version' 'Products that are not affected by Log4Shell and are not vulnerable' 'Products that are not affected by Log4Shell by default' 'Products that remain vulnerable or have unknown support' 'May be affected by Log4Shell' 'Products with' 'Products for which the official answer is not clear' 'Products that can be relayed, transferred, and integrated, but do not depend on Log4j by default' are summarized.