When Log4J received the report for the JNDI lookup injection they decided to validate the LDAP entries fetched. javaCodeBase: Based on the previous, JDNI LDAP context will deserialize the data presented in the field javaSerializedData.With the previous attributes, the class Log4jRCE is downloaded from and instantiated. Here are two combinations as described in RFC2713.

Multiples LDAP attribute combinations can be used to trigger code execution. In Log4J 2.15, RMI and IIOP are not included in the protocol allowlist verification leaving only the LDAP protocol to be used. The class JndiManager is wrapping the lookup for JNDI which can cause some unexpected code execution specifically if RMI, IIOP or LDAP are used. These new validations fell short due to a Time of Check, Time of Use vulnerability (TOCTOU).

The JNDI lookup feature was still included in 2.15 and additional checks were made to prevent malicious LDAP attributes when the feature is enabled. Information about the status of our products is available here.īefore we dive into the code, we should clarify that only Log4J version 2.15 and below are vulnerable and only if lookups are enabled for backward compatibility. For further information about Log4Shell’s impact, visit our blog on mitigation and remediation.

This vector was also discovered independently by Alvaro Muñoz and Tony Torralba. It is likely that many other individuals have reported related bypass techniques because there were multiple weaknesses in the same Java class ( JndiManager).ĭuring this time, Log4J has received multiple security updates and GoSecure has been working across our portfolio of products and services to support our clients who may be affected. We recommend everyone update to the latest version 2.17 for the best available protection. In this blog, we will detail the new mitigation introduced in 2.15 and the bypass we found using a Time of Check, Time of Use vulnerability (TOCTOU). And as the GoSecure research team investigated, we realized that the mitigations implemented were incomplete. Log4J 2.15 vulnerabilities are now considered high severity (9.0).

Log4J has been in the spotlight for the past two weeks for a new attack vector which relies on Java Naming and Directory Interface (JNDI).

Lansweeper log4j2