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.

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

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

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
    

Since the discovery, mitigation and remediation phases may take some time, organizations are encouraged to take steps to ensure they are not impacted by the Log4j vulnerabilities, including – but not limited to – the following:

• Immediately increase security monitoring with emphasis on servers and applications that make use of Java and Log4j, including cloud and third-party servers and applications (where possible) – your SOC (or SOC provider) should be actively looking for exploits on these.
• In particular, we see exploits that are deploying cryptominers onto systems – and can expect worms and ransomware to follow soon
• Update and/or add appropriate rules to security platforms to block and alert for any attempt to trigger the Log4j vulnerability, such as IDS/IPS systems and WAFs
• Increase the level of logging for servers that host Java applications or services
• Increase the level of logging for Java-based applications or services

• Mass scanning for applications and services that use the vulnerable versions of Log4j began prior to the public announcement made by the ASF, and as such, organizations should consult their incident response policy and incident response plan for guidance on how to respond to the active, on-going threat
• Organizations are encouraged to perform compromise assessment steps to ensure they were not breached as a result of the Log4j vulnerability
• Check for common post-exploitation activities, e.g.: malware alerts from security software; the use of post-exploitation frameworks such as Metasploit and Cobalt Strike; abnormal lateral movement; and data exfiltration
• Many investigative processes can help identify vulnerable applications and services not identified during the discovery phase as well as gaps in security monitoring

The following actions are highly recommended so as for IT to sleep better at night next time a similar issue happens:

• Ensure you have a software bill of materials and configuration management database as part of your asset management
• Deploy SIEM solutions to collect log files and monitor these – managed SOC providers can help
• Regularly and routinely perform vulnerability scans and penetration tests – both internal and external
• Test your incident response plans at least annually – even a tabletop exercise can help