Don't let Log4j ruin your security setup Don't let Log4j ruin your security setup
The Apache Software Foundation announced that the popular Log4j Logging Services software library – a Java library that provides logging capabilities for Java applications – has a critical exploit that allows remote code execution.
Over the last week, all our clients have been talking about Log4Shell / Log4J (CVE-2021-44228) being rated critical (CVSS 10/10) due to ease of exploit and widespread use. The vulnerability allows an attacker to execute code on a remote server without authentication.
Several security agencies have issued security advisories and bulletins that include detailed information that companies can use to help determine if they may be impacted by the Apache Log4j vulnerability.
That said, this latest vulnerability has uncovered a bigger challenge in the industry – configuration and asset management. Simply knowing what is in your estate can sometimes be the biggest challenge.
What to do FIRST
Don't panic. A well-organized, prompt response to the Log4Shell threat is the best approach to achieve effective and efficient results. Even though you may not have a full CMDB in place, you can identify where you have vulnerable systems.
Organizations should consider multiple processes in parallel to efficiently respond to the threat, with emphasis on the following processes:
- Discovery
- Mitigation and remediation
- Security monitoring
- Investigation
- Long-term planning
Discovery
Compile a complete list of applications and services used within your organization, including cloud and third-party applications and services.
Vulnerability management applications can be used to assist with the discovery process – for example, Nessus, Qualys and Orca all have an ability to discover if an application is vulnerable.
Where applicable, organizations should consult their SBOM (Software Bill of Materials) from vendors to ensure complete coverage during the discovery phase
- Determine any/all applications or services that make use of Log4j and the version of Log4j used for each application or service
- Create a prioritized list of impacted applications and services ranked according to the risk to the organization and create a plan for mitigation and remediation
Mitigation and remediation
Wherever possible, organizations should upgrade Log4j to version 2.16.0 to mitigate the active, on-going threat – upgrading Log4j to version 2.16.0 is the only method known to completely mitigate the threats associated with the Log4Shell vulnerabilities.
- Organizations that are unable to upgrade to Log4j version 2.16.0 can mitigate risk by changing configuration options or by removing the effected Java class from their application:
- Enable the execution flag for the property log4j2.formatMsgNoLookups by setting the property to true; this can be achieved by setting an environment variable (LOG4J_FORMAT_MSG_NO_LOOKUPS=true) or by including the argument in the JVM options (JAVA_OPTS=-Dlog4j2.formatMsgNoLookups=true)
- Remove the JndiLookup class from the classpath for each application
- Enable the execution flag for the property log4j2.formatMsgNoLookups by setting the property to true; this can be achieved by setting an environment variable (LOG4J_FORMAT_MSG_NO_LOOKUPS=true) or by including the argument in the JVM options (JAVA_OPTS=-Dlog4j2.formatMsgNoLookups=true)