Go to content

Apache Log4j vulnerability

A serious vulnerability has been identified in Apache Log4j, a program that is commonly used in Web applications and many other systems. The National Cyber Security Centre (NCSC) has warned of potentially major damage and is advising organisations to prepare for a possible attack. To help organisations deal with this situation, we have drawn up a step-by-step plan, and we have created a platform on GitHub, which contains an overview of vulnerable applications, scanning and mitigation tools and indicators of compromise (IoCs).

GitHub

The NCSC has published a list of vulnerable applications on GitHub. National and international partners, organisations and companies have been urgently requested to share any additional information they may have. So far, there has been a massive response to this appeal. The pages on IoCs and scanning and mitigation tools already contain a great deal of useful information. This makes this list one of the most complete, in international terms. Because it is not possible for the NCSC to update its security advice for every single application that uses Log4j, the appearance of a particular application on this list should be seen as an update of the HIGH/HIGH security assessment (i.e. a high likelihood of major damage). The figure below provides a schematic overview of updates and found vulnerabilities.

Enlarge image
Overview of found vulnerabilities and updates

Reduce the chance of misuse

Log4j has certain functionalities that give attackers the opportunity to introduce code into log files. If an attacker designs that input in a certain way, they can use it to run a remote code execution. In other words they can remotely force a computer or programme to run a programme code.

It may not be clear to organisations what action they should take in this situation. This is why the NCSC has drawn up the following step-by-step guide:

  1. Check to see if Log4j v2 is used in your network. Various scripts are available for this purpose (Linux and Windows). A number of vulnerability scanners have released updates or plugins to check whether systems are vulnerable. These can be found on GitHub. Please note: these scans do not offer a 100% guarantee that your system isn’t vulnerable.
  2. Be aware that even systems without an internet connection can be at risk. Attacks from inside your system are also a possibility.
  3. If your system is vulnerable, check to see if your software provider has already made a patch available, and install it as soon as possible.
    1. If your system processes information from potentially untrustworthy sources (for example, from the internet) and no patch is available, take mitigating measures wherever possible.
    2. If it is not possible to carry out an update, we advise you to consider shutting down the system until a patch is available.
    3. The GitHub list maintained by the NCSC can provide you with information about newly released patches, but we advise you to also monitor the pages of the software suppliers themselves.
  4. Check vulnerable systems and systems that have already been patched for misuse, going back at least as far as 1 December.

Be prepared for misuse

The measures below will help you in identifying and dealing with a Log4j incident.

  1. Make sure that you have incident response manuals at the ready. Make sure you know who you need to contact in case of an incident. Have a team on stand-by. Consider setting up a temporary on-call duty roster. Keep an eye on the NCSC’s GitHub site for the latest information on indicators from forensic investigation.
  2. Be prepared for misuse. Check to see if your incident response plans are designed to handle an incident like Log4j and if not, adjust them accordingly, for example by isolating affected systems and changing credentials that the compromised server has access to. Determine how disk and memory artifacts (disk image, memory image) are secured for further investigation, for example to investigate whether adjacent systems have been compromised.
  3. Wherever possible, turn on detection measures. Various organisations have made detection rules available for their firewall products. Here too, it should be noted that having these measures turned on is no guarantee that you will be able to protect yourself from every form of misuse. Make a record of what you do not monitor and fill these gaps wherever possible with detection measures.
  4. Test your existing back-ups. Make an offline back-up, even if this is not something you would normally do.
  5. Ask staff to notify you of anything suspicious, such as heightened processor activity or other unusual behaviour.
  6. Take steps to limit the impact of a successful attack, by restricting traffic between your systems. For example, segment your networks, or block unnecessary outgoing network traffic on your servers. Identify dependences between your systems, and see if you can find ways of reducing them in the short term.
  7. Log4j is widely used; it may be used in products where you wouldn’t expect it. If you are confronted with an incident in the near future that you can’t figure out, be aware that it could be the result of a compromised system caused by the Log4j vulnerability.
  8. The vulnerability in question can be used to carry out a ransomware attack. The NCSC advises its partners to make the necessary preparations. More information can be found on the Ransomware factsheet.
  9. Determine whether your suppliers use Log4j. In some cases scanning tools will not detect the use of Log4j in products belonging to suppliers. Many suppliers are communicating proactively about the impact of Log4j on their products. If this is not the case for you: ask your supplier about the vulnerability and the actions you can take. On GitHub the NCSC is compiling an overview of the status of products.

Cyber resilience in the longer term

The advice contained in this blogpost deals with the very short term. If you are interested in making longer-term investments in your cyber resilience, the following publications can offer useful guidelines.