IMPORTANT this blogpost is outdated, please see the following link for the latest mitegation.
Apache log4j2-library version
<2.15.0 is vulnerable to a Remote Code Execution (RCE) (CVSS-score: 10, CVE-2021-44228). If a specially crafted line of text, sent by an attacker, is logged by Log4j the payload inside is executed. Multiple mitigation options exist which include changing configuration parameters or removing classes from non-updated Log4j instances or updating to Log4j to version
2.15 or higher (which requires a restart of the application or system).
The vulnerability exists due to the way Log4j handles
Java Naming Directory Interface (
JNDI) queries. In the context of the vulnerability these queries are “user provided input”, and malicious users abuse this pattern to load lookups or malware.
In some applications user input or user interaction is logged. You can abuse this logging to query certain protocols such as
(Secure) Lightweight Directory Access Protocol (
Remote Method Invocation (
Domain Name Service (
An example of such a query is:
These queries are found to be “nestable” and can be used to receive system information.
All systems and services using the Log4j library (ranging from versions
2.14.1) are vulnerable. Even systems and applications that are not directly connected to the internet (e.q. behind firewalls, proxies or loadbalancers) can be at risk due to the nature of the vulnerability.
Examples of applications and systems using Log4j include VMware, ElasticSearch, Atlassian products, Apache and Oracle.
We strongly advise to upgrade Log4j to version
2.15.0 or higher as soon as possible. Releases for Log4j can be found here.
If updating Log4j to version
2.15.0 or higher isn’t possible specific settings should be changed in order to prevent lookups that are abused by the vulnerability. To apply these settings a restart is required.
2.10 one can edit the following settings to be true:
# Change this property to 'true' log4j2.formatMsgNoLookups=true # Additionally LOG4J_FORMAT_MSG_NO_LOOKUPS=true
Alternatively, till version
JndiLookup class can be removed:
zip -q -d log4j-core-*.jar org/apache/logging/log4j/core/lookup/JndiLookup.class
As last resort one could use firewall rulesets to check and drop incoming traffic containing the
jndi lookup queries and block all outgoing
RMI traffic as temporary work around.
Indicators of Compromise
- Review apache logs for
jndi:dnsentries. These queries are potential uses of the vulnerability affecting log4j
/var/log(or on Windows Apache the applicable log folder such as
[DriveLetter]:\\logs\) with applicable signatures matching these indicators
- 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 ensure their resilience.
- 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.
- 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.
- Detect: Once the preventive measures are in place, our Blue Team shifts to detection mechanisms in order to detect ongoing attacks.
- 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.
- 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 firstname.lastname@example.org.