Last update: December 20th, 3:00 PM CET

This blog is no longer being updated. The latest information on the Log4j vulnerability can be found in our Log4j FAQ, which is continuously being updated and monitored.

On Thursday, December 9th a serious vulnerability was discovered in the much-used Apache Log4j Java logging library (Log4j). Through this vulnerability, an unauthenticated, unauthorized RCE (Remote Code Execution) is made possible, which can be used to take over a server. A patch was quickly made available, but executing said patch is proving to be a more complex activity.

It’s now been eight days since the Log4j vulnerability became known. What has since become clear, what should you absolutely have done and what should you be doing now? CTO Lieuwe Jan Koning and Lead Architect Rob Maas have been part of ON2IT’s Log4j CIRT (Cybersecurity Incident Response Team) since Friday night. What have been their priorities these past days, and what’s their advice to our customers?

Tech Talk Log4j – December 21, 3:00 PM CET

Yuri BobbertThis Tech Talk is dedicated to the recent Log4j vulnerability and is meant as a Q&A session for anyone who has questions about this high impact exploit.

Sign-up here

“The thing that makes Log4j special is that nearly every organization still has a growing list of vulnerable applications that need to be patched”, says Rob Maas.

“That’s easier said than done. The challenge is that Log4j is applied in nearly all Java-based applications. This means that organizations have to patch multiple applications, and possibly also business-critical applications, as fast as possible. This leads to a large impact, also on the availability for users, but patching is the most effective measure.”

ON2IT will, when asked, help organizations with quickly and efficiently localizing applications that are vulnerable. In addition to that, in consultation with customers, we’re rolling out ‘emergency Zero Trust policies’ in firewalls, mostly to block outbound traffic.

However, these mitigating measures aren’t the solution, as new attacks are constantly added, which means the blocklists have to constantly be updated.

“A big problem is that not all suppliers have published whether or not their application is vulnerable and when we can expect a patch,” adds Lieuwe Jan Koning, CTO at ON2IT.

“The Apache Log4j logging library needs to be updated to at least version 2.17.0. As an additional countermeasure, ON2IT is composing blocklists, which are constantly being updated. These contain IP addresses and hostnames that are currently actively being used by hackers to exploit the leak.

These lists are implemented on firewalls, to make it very hard for these hackers to succeed. However, these mitigating measures aren’t the solution, as new attacks are constantly added, which means the blocklists have to constantly be updated. The same goes for other mitigations, such as IPS signatures. On top of that, blocklists are effectively useless against attacks from the inside.”

Koning, therefore, advises to block all traffic on outgoing servers immediately and to only allow very specific traffic when needed. He believes this is still largely effective. Though not nearly sufficient, as information (such as passwords) can still leak via the DNS protocol. Because nearly all servers require DNS in order to function, we cannot turn this off.

It’s important to obtain a patch or workaround from each supplier who delivers this technology as a (semi) finished product. Suppliers will generally speaking understand the urgency of this, but in this situation applying some pressure might be in order.

Is a patch already available? Install it as soon as possible. If not, run a risk analysis and determine what needs to happen.

Many customers are considering closing off their test and development environments from the internet and the rest of the IT environment, or shutting them off completely, and to first focus on critical systems. Especially in a non-segmented environment, where the production and test environment “intersect”, this is highly recommended.

According to Koning, it is important to check all servers and applications with this particular vulnerability, and to determine what needs to happen next. “Is a patch already available? Install it as soon as possible. If not, run a risk analysis and determine what needs to happen. Should other mitigating measures be applied, like a configuration change of the application, or turning off the relevant servers? By running through all this in a structured and well-documented way, the impact can be reduced. Also, consider supervisory authorities and auditors who might want to be able to look at what you did after the fact.”

High/High security advice

Rob Maas points out the NCSC list (The Dutch National Cyber Security Center) that keeps track of which applications pose a risk. This list of vulnerable applications offers a good starting point, but the list isn’t nearly complete and will be added to in the following days with information on applications that aren’t yet on the list. This NCSC-page is also used to announce scan- and detection possibilities (scripts) and Indicators of Compromise.

The NCSC has also published clear instructions and composed a roadmap. The NCSC cannot update its security advice for each application that uses Log4j. If an application is mentioned on this list, it can therefore be seen as a HIGH/HIGH security advice (high chance at big damages).

Our advice

From a risk control standpoint, we advise you to at the very least take inventory of all Log4j v2 that is being used in your technology landscape. Also consider third parties that develop software for you and external libraries that are being used, like in content management systems. These suppliers will also have to update their systems. Make sure to also consider cloud assets!

Be aware that systems without an internet connection can also be at risk.

To execute the stock-taking you can make use of application lists or CMDBs, so you can then run scripts to identify whether or not Log4j is being used. This can grant you insight into where and what version is being used.

Several vulnerability scanners have also published updates or plugins to check if systems are vulnerable. You can find these on the NCSC website as well. Because these scanners never provide a 100% guarantee, we advise you to double-check. ON2IT can help you with more in-depth investigations if you wish.

Be aware that systems without an internet connection can also be at risk. Attacks from the inside are also probable. A ‘landscape check’, during which all systems are assessed on potential sensitivity for misuse through this vulnerability, but also a check to see if the vulnerability has already been exploited, is recommended.

Maas and Koning indicate that clients who have set up their cybersecurity measures using the strategic principles of Zero Trust will have a reduced impact, because they are actively using segmentation (which lowers the blast radius), profit from active traffic inspection, and security product updates are better monitored.

Now that the house is on fire, it is too early to ask questions such as “how could we have prevented this?” and “how do we better set up our patch policy?”.

The roles of compliance and supplier policy are also important. Never waste a good crisis, is often-heard wisdom. This certainly applies here. This is something we’ll be looking at extensively in the coming weeks.

Tech Talk Log4j – December 21, 3:00 PM CET

Yuri BobbertThis Tech Talk is dedicated to the recent Log4j vulnerability and is meant as a Q&A session for anyone who has questions about this high impact exploit.

Sign-up here