Updated critical vulnerability Log4j

Summary

A second vulnerability (CVE-2021-45046) has been discovered in log4j, impacting versions < 2.16.0 and remediation strategies applied to versions 2.7.0 to 2.14.1 under specific conditions. The new attack vector might lead to a Denial of Service (DOS) attack or may leave you vulnerable to Log4shell (Remote Code Execution). Even if mitigating measures such as setting formatMsgNoLookups to true are in place. We strongly advise to update log4j to the latest version (2.16.0 at time of writing) or when updating isn’t possible to remove the lndilookupclass from prior versions.

Mitigation

We strongly advise to upgrade log4j to version 2.16.0 as soon as possible. Releases for log4j can be found here. Enforcing mitigating settings on older versions (< 2.16.0) might limit the Remote Code Execution but does not prevent all vulnerabilities (such as DOS) currently present in log4j.

The specific issues from the new (and old) CVE can also be mitigated by removing the lndilookup class from the classpath, e.g.:
zip -q -d log4j-core-*.jar org/apache/logging/log4j/core/lookup/JndiLookup.class

Update on mitigation with MsgNoLookups and %m{nolookups}

As mentioned previous mitigation strategies including setting the MsgNoLookup setting to true are outdated due to new attack-vectors discovered in CVE-2021-45046. Using a modified payload it is still possible to achieve Remote Code Execution in versions 2.10.0 <= 2.14.1.

For versions >=2.7.0 the previously advised %m{nolookups} mitigation strategy could be bypassed under certain conditions and would still allow for Remote Code Execution.

Additionally, a Denial of Service (DOS) vulnerability is also present in the log4j versions up to 2.15.0 which is mitigated in version 2.16.0 by removing the lookup patterns and disabling the jndi functionality by default.

Review log4j for Indicators of Compromise

As previously advised strategies have shown to be insufficient in regards to the latest log4j vulnerability we advice you to review impacted log4j systems for indicators of compromise. This can be done in the following manner:

  1. Review apache logs for jndi:ldap, jndi:rmi or jndi:dns entries. These queries may indicate successful exploitation of the vulnerabilities that are affecting log4j;
  2. Scan /var/log (or for Windows Apache the log folder such as [DriveLetter]:\\\\logs\\) with signatures matching the indicators mentioned above;
  3. Scan webservers for generic webshells and review outbound connections coming from webservers in your firewall.

Support by Ordina

Ordina is proactively supporting clients in their efforts to mitigate the Log4j vulnerability and to ensure their resilience.

  1. Identify: Ethical Hackers from our Red Team are able to identify the use of Log4j within application stacks and research whether the used version is vulnerable, therefor exposing the attack surface within your organization.
  2. Protect: Members of our Blue Team then proactively take measures, as mentioned above, to prevent the misuse of Log4j and minimize the impact of the vulnerability.
  3. Detect: Once the preventive measures are in place, our Blue Team shifts to detection mechanisms in order to detect ongoing or previous attacks.
  4. Respond: Based on Indicators of Compromise and our detection mechanisms our Blue Team will assist in the case of successful compromise to ensure quick and effective containment of the attack.
  5. Recover: Our Security Strategy team evaluates the response process and incorporates the ‘lessons learned’ within your 0-day reaction processes to ensure your resilience towards future 0-days.

If you require any assistance with identifying whether the vulnerability is existent in your IT-environment, remediation of the vulnerability or rapid response to an ongoing cyberattack please give us a call:
030 – 663 80 03 or send an e-mail to blueteam@ordina.nl.

References and sources

https://www.lunasec.io/docs/blog/log4j-zero-day-mitigation-guide/

https://www.cve.org/CVERecord?id=CVE-2021-45046