Log4Shell: RCE 0-day exploit found in log4j2, a popular Java logging package.
Who Is Impacted?
Many cloud services are vulnerable to this exploit. Please read below article for more details about
the impact:
• https://www.lunasec.io/docs/blog/log4j-zero-day/
• CVE-2021-44228
• https://github.com/advisories/GHSA-jfh8-c2jp-5v3q
Description:-
FortiGuard Labs is aware of a remote code execution vulnerability in Apache Log4j. Log4j is a Java
based logging audit framework within Apache. Apache Log4j2 2.14.1 and below are susceptible to a
remote code execution vulnerability where a remote attacker can leverage this vulnerability to take
full control of a vulnerable machine.
This vulnerability is also known as Log4shell and has the CVE assignment (CVE-2021-44228).
FortiGuard Labs will be monitoring this issue for any further developments.
What are the technical details?
Apache Log4j2 versions 2.14.1 and below Java Naming and Directory Interface (JNDI) features do not
protect against attacker controlled LDAP and other JNDI related endpoints. A remote code execution
vulnerability exists where attacker controlled log messages or log message parameters are able to
execute arbitrary code loaded from LDAP servers when message lookup substitution is enabled.
What versions or Software are affected?
Apache Log4J versions 2.0-beta9 to 2.14.1 are affected.
Is there a Patch or Security Update Available?
Yes, moving to version 2.15.0 mitigates this issue. Further mitigation steps are available from Apache
as well. Please refer to the “Apache Log4j Security Vulnerabilities” in the APPENDIX for details.
What is the CVSS Score?
10 (CRITICAL)
What is Exactly Apache Log4j?
According to Apache:
Log4j is a tool to help the programmer output log statements to a variety of output targets. In case
of problems with an application, it is helpful to enable logging so that the problem can be located.
With log4j it is possible to enable logging at runtime without modifying the application binary. The
log4j package is designed so that log statements can remain in shipped code without incurring a high
performance cost. It follows that the speed of logging (or rather not logging) is capital.
At the same time, log output can be so voluminous that it quickly becomes overwhelming. One of
the distinctive features of log4j is the notion of hierarchical loggers. Using loggers it is possible to
selectively control which log statements are output at arbitrary granularity.
What is the Status of Protections?
FortiGuard Labs has IPS coverage in place for this issue as (version 19.215):
Apache.Log4j.Error.Log.Remote.Code.Execution
Please note that, since this is an emergency release, the default action for this signature is set to
pass. Please modify the action according to your need on a few test policies before rolling out to all
policies protecting your Server segment.
Any Suggested Mitigation?
According to Apache, the specific following mitigation steps are available:
In releases >=2.10, this behavior 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
FortiGuard Labs recommends organizations affected by CVE-2021-44228 to update to the latest
version of 2.15.0 immediately. Apache also recommends that users running versions 1.0 or lower
install version 2.0 or higher as 1.0 has reached end of life in August 2015 for Log4j to obtain security
updates. Binary patches are never provided and must be compiled. For further details, refer to the
“Apache Log4j Security Vulnerabilities” in the APPENDIX.
If this is not possible, various counter measures such as isolating machines behind a firewall or VPN
that are public facing is recommended.
Appendix
Apache Log4j Security Vulnerabilities (Apache)
More news about Logix InfoSecurity.