This Log4J flow chart helps you make the right decisions

Log4j is used by many applications to keep application logs. Recently, a vulnerability was disclosed in the Java library 'log4j', which may allow an attacker to execute code within the application and/or system on which log4j is deployed. The vulnerability arises from a functionality within the log4j library which is used for formatting log messages.

Because of the way this functionality works, functions can be called unintentionally which can perform actions (such as downloading and executing code from a remote server).

The vulnerability in this functionality can be exploited if a log message is written away. This occurs in many different situations and is context-dependent, such as:

• When completing a login screen where the username field is included in the log message;
• When sending a request to a web server (where a User-Agent-header is sent to the server; this is a value that an attacker can have control over);
• When modifying any other field in an application where the field is included in the log message.

Summary: Applications that are remotely accessible, can process user input, and use log4j (a version lower than 2.15.0) to log this input may be vulnerable.

If an attacker is able to successfully exploit the vulnerability then it can execute code controlled by the attacker. This could potentially result in the server running the application becoming compromised. This attack can be performed from the Internet where no authentication is required.

From a compromised server, an attacker could potentially gain access to the rest of the network. For this reason, the impact of the vulnerability is classified as critical.

At the time of writing, there are multiple indicators that there are active attempts to exploit the vulnerability - including attempts by known rogue IP addresses(https://www.greynoise.io/viz/query/?gnql=cve%3ACVE-2021-44228).

In addition, there are now known cases of attempts to insert crypto coin-miners after a system has been compromised via the vulnerability.

Because the vulnerable functionality resides in a popular Java library, the current scope or impact is not transparent. However, initial reports do indicate that commonly used web services and software packages (e.g., VMWare vCenter, Apache Solr, ElasticSearch, IBM QRadar SIEM, Palo Alto Panorama, Pulse Secure, and UniFi) appear to be vulnerable(https://github.com/YfryTchsGD/Log4jAttackSurface). It is very likely that many more applications are vulnerable which are not yet known at the time of writing. The above makes fully detecting any abuse of the vulnerability, at the time of writing, complex.

For developers of applications using log4j, the following advice applies:
A new version of log4j is available which can be downloaded from the URL; https://logging.apache.org/log4j/2.x/download.html. NFIR recommends that an upgrade be performed as soon as possible ^{[1] [1]} and then deploy it to the affected systems and applications.

At the time when upgrading is not possible, the following workaround can be applied:

1. A temporary workaround can be applied by removing the vulnerable classes:

zip -q -d log4j-core-*.jar org/apache/logging/log4j/core/lookup/JndiLookup.class

For third-party applications that you use, NFIR recommends that you contact the vendor for any updates.

The recommendation is to at least update to version 2.17.1.

It is important for your organization to take at least the following steps:

1. Map out which individual vendors you have for on-premises software packages, Software-as-a-Service (SaaS) or other application vendors;
2. Consult your vendor's website and determine if some form of 'dependency lists' are available within which you can check whether 'log4j' is used within the application;
3. Contact your vendors to verify if 'log4j' is used within the applications and which version of log4j is used;
4. Prepare your organization for the situation when patches need to be executed unexpectedly (outside the regular update timeframes) and apply patches in a controlled manner according to the procedure usual for your organization.

Do you have systems where the risk is high (for example, systems with sensitive or special personal data)? If so, do you have any possible indications that Java is being used with log4j and updates are not yet available? Then consider temporarily disabling the system.

If your organization is suspected to have been the victim of an attack, the urgent advice is to have research conducted into the cause, to what extent attackers may have compromised other systems and what information may have been accessed unauthorized.

1. If possible, disconnect affected systems from the network, but leave them on (because of possible traces such as volatile memory - RAM);
2. Have the affected systems forensically examined; ensure adequate backups;
3. Reset your passwords and user data;
4. Report to the Police;
5. Consider filing a report with the Personal Data Authority.

Does your organization currently have an incident? Our Computer Emergency Response Teams (CERT) are available to organizations 24/7 to support IT Security Incidents.

Then call 088 133 0700 and we will do our utmost to help you as quickly as possible.(Learn more about our Incident Response Service.)