Invicti detected that the application is vulnerable to the Log4j (version 2) remote code execution vulnerability (CVE-2021-44228) by capturing a DNS A request, which occurs when input data is interpreted by the vulnerable log4j library.

This is a highly critical issue and should be addressed as soon as possible.

Apache Log4j is an open source logging library used widely in the Java ecosystem. It features enhanced logging capability with JNDI and system property lookups. Improper input sanitization can cause JNDI lookups to load arbitrary Java classes from remote servers and can lead to remote code executions, sensitive information leakage and denial of service.

Three main CVE’s are published in regard to this vulnerability:

CVE-2021-44228: In Apache Log4j2, the JNDI features used in configuration, log messages and parameters do not protect against code being loaded from attacker controlled LDAP servers and other JNDI related endpoints. An attacker who can control log messages or log message parameters can execute arbitrary code loaded from LDAP servers.

CVE-2021-45046: It was found that the fix Apache implemented in version 2.15.0 was incomplete in certain non-default configurations resulting in information leak, remote code execution and denial of service.

CVE-2021-45104: It was found that Apache Log4j versions through 2.16.0 did not prevent uncontrolled recursion from self-referential lookups.

• An attacker can run arbitrary code on the server by loading arbitrary Java classes via JNDI lookup.
• An attacker can leak sensitive information such as hostname or environment variables from a vulnerable server.
• An attacker can cause denial of service on the vulnerable server.

Apache has published patches for this vulnerability. Due to incomplete patches 2.15.0 and 2.16.0, upgrading to 2.17.0 is recommended.

• Upgrade to Log4j 2.3.1 (for Java 6), 2.12.3 (for Java 7), or 2.17.0 (for Java 8 and later).

Alternatively, this infinite recursion issue can be mitigated in configuration:

• In PatternLayout in the logging configuration, replace Context Lookups like ${ctx:loginId} or $${ctx:loginId} with Thread Context Map patterns (%X, %mdc, or %MDC).
• Otherwise, in the configuration, remove references to Context Lookups like ${ctx:loginId} or $${ctx:loginId} where they originate from sources external to the application such as HTTP headers or user input.