Go to content
Search for topics, knowledge, services, etc.

Log4j

Click here to go directly to the latest information.

Read more about the Log4j status of products and services of Wortell. 

Important information about the LOG4J vulnerability

On 10 December, a vulnerability was revealed in the widely used software component Log4j (pronounced 'log for jay'). The other name under which this vulnerability is known is Log4shell. Log4j is a freely available Apache open source tool that is used by many developers to log activities in an application. It can be installed separately, but more often than not it is included in the source code of another software package. This vulnerability is known under number CVE-2021-44228 and has been given a risk score of 10; the highest possible score, partly because the software is so widely used, and the abuse of this vulnerability is considered to be simple.

How does vulnerability work?

When using a vulnerable version of Log4j, incoming data (e.g. by filling out a web form) that would normally be logged, can be executed as a command on the relevant server where this application is running. This is called remote code execution (RCE); the remote execution of code, scripts and applications.

The specific vulnerability in Log4j revolves around a component called JNDI (Java Naming and Directory Interface) which normally provides a connection to LDAP. Instead of logging this URL, the text from the text field is executed as a command on the server and it is possible to call up an external URL, for example with the intention of downloading and executing a malicious piece of software. Examples are the installation of ransomware (which 'locks up' this server and/or your entire network) and/or the execution of a cryptocoin miner (which abuses your server capacity to mine crypto coins for others).

How exactly does this work technically?

Our security research & development lead, Jeroen Niesen, has written an article about the deeper technical workings of this vulnerability. You can find the article here. If you have any further questions, you can reach Jeroen and his team at log4j@wortell.com.

Microsoft Defender & Microsoft Sentinel

Our cybersecurity expert Jeffrey Appel has written an extensive technical article on how Microsoft Defender and Microsoft Sentinel can help with this Log4j vulnerability. You can find the article here.

Who is vulnerable?

Log4j is a software component used in many Java-based applications. The Dutch Cyber Security Centre (NCSC) maintains a list of applications that are vulnerable because they use this Log4j version. More and more software manufacturers are now reporting whether their versions are vulnerable, and the list is constantly being updated. If your application is not on the list it is still possible that you are vulnerable; not all software vendors are aware that they use Log4j as a component.

What can you do about it?

There is no easy solution; you will need to do a plethora of things to guard against this vulnerability.

  • First of all, you will need to map out which applications your organization uses and whether Log4j is part of that, for example using the NCSC list.
  • You will then need to update and patch Log4j itself, if it is used separately, or the application that has Log4j in it, for example VMware (if it has already been made available by the vendor). Version 2.17.0 of Log4, which fixes the vulnerability, can be downloaded here.
  • You will also need to check, for example in system logs or network and firewall logs, whether the vulnerability has already been actively exploited in your environment, the so-called ${jndi:ldap rules. Wortell has created automated scanners for this, as part of the Cyber Security Scan, see also below.
  • You can schedule a pentest to have an expert test your important application for the vulnerability in question.
  • For applications that turn out to be vulnerable, for which there is no patch (yet), it is wise to limit network traffic. For example, making DNS, LDAP or LDAPS requests (to the internet) impossible.
  • It is recommended to enable active monitoring for your environment or for specific important applications, for example by using Wortell's Managed Detection & Response (MDR) service, which is active 24x7, and has made additional detections/surveillance for Log4j in its Security Operations Center.

What does Wortell do?

Wortell does at least these three things.

1. An extensive analysis was performed on resources used by Wortell to provide services to our customers. No traces of abuse were found on any of these resources. In the mean time we are performing an inventory on third party software that is part of our services and whether Log4j is used in it. We hope to complete the investigation soon and will share further information. Of course you can always find an up-to-date overview on this page.

2. For Wortell customers who have a Managed Detection & Response (MDR) contract, proactive actions have already been initiated. From the Threat & Vulnerability Management (TVM) process, a customer's potentially vulnerable applications are identified. Also, the MDR has more than 10 use cases active that provide additional monitoring (detection & hunting) for potential abuse of Log4j.

 

3. All other customers will be approached by their service manager, account manager or other contact person at Wortell, to discuss which actions are desired and required. If desired, a Cyber Security Scan can be scheduled (possibly for a fee) to further map out the specific situation, scan for active abuse, and prepare an impact analysis. This scan checks whether systems are vulnerable to CVE-2021-44228 and whether the vulnerability has been exploited.

Not a Wortell customer yet? Then we can still help you today. Please contact info@wortell.nl or +312075050. Are you already a customer, but do you have a problem? Please open a ticket with Wortell through ServiceNow or send an email to services@wortell.nl.

 

Do you see abuse yet?

There are a number of ways for Wortell to get an idea of the possible abuse of this vulnerability. First of all, for our Managed Detection & Response (MDR) customers, a so-called HoneyNetwork is active. This is a series of Honeypots (you could see this as 'lok computers') that 'listen' for this type of abuse. Once this rogue web request is received, the IP address and other relevant data is stored, and this list is used by the Security Operations Center for active blocking.

In our HoneyNet, we are seeing several attempts to exploit the Log4j vulnerability. It is notable that an increase in the number of attack attempts can be seen. The attack attempts take place on different types of honeypots (both web-based honeypots and deamon honeypots).

In addition, active investigations are started ('hunting'). Here we look at logs of customers, or as part of the Cyber Security Scan we look at entire servers and/or environments.

We also actively share information with a select number of other cybersecurity companies, including in Germany and Sweden. Here we exchange examples of the code executed on servers that have been hacked, and share for example those IP lists.

Up to now our impression is that there has not been any large scale abuse of this vulnerability. These scans are performed by security researchers as well as attackers. We do see that servers and applications running Log4j are scanned en masse. Occasionally a cryptominer is installed and attempts are made to activate a reverse shell. Reports do reach us that some attacker groups are exploiting the log4j vulnerability to launch ransomware attacks. We are aware that at least the following attacker groups are using CVE-2021-44228:

  • Phosphorus, an Iranian attacker group that performs ransomware attacks, among other things.
  • Hafnium, an attacker group from China (known for earlier attacks on Exchange servers) abuses CVE-2021-44228.

 

Expectations for the coming weeks

Despite the fact that all suppliers do their best to provide software with a security update as quickly as possible, it is expected that the abuse of this vulnerability will increase in the coming days and weeks because an update may not be available in time or may not be installed on time. It is estimated that there are about three billion devices worldwide on which the vulnerable version of log4j is active. Log4j is therefore widely distributed, even in places where you would not expect it.

As a company, how can you be as proactive as possible? Wortell has developed a Log4J Cyber Security Scan that allows us to identify vulnerabilities; we look at the NCSC list of known applications, we can scan servers and see if Log4j is installed, and we can check logs for potential abuse. Would you like to be helped and protected on an ongoing basis, in addition to this moment-in-time scan? Then contact us about our Managed Detection and Response service.

However, the NOS summarises that it is "silence before the storm" and that "this is not going to end without a bang". And Computable also sees that companies and governments are already taking certain systems offline proactively.

Log4j update 20 december 2021

  • Since November 30, at least 3 different Log4j vulnerabilities have been found, which together have been given a total of 5 CVE registration numbers; thus, it is important to look not only at CVE-2021-44228 (which is often implicitly talked about when Log4j is mentioned) but also at new vulnerabilities. The following vulnerabilities are now known:
CVE Number Score Description

CVE-2021-442278

10.0

A vulnerability for executing external code that affects Log4j versions from 2.0-beta9 to 2.14.1 (resolved in version 2.15.0)

CVE-2021-45046

9.0

An information leak and vulnerability for executing external code affecting Log4j versions from 2.0-beta9 to 2.15.0, excluding 2.12.2 (resolved in version 2.16.0)

CVE-2021-45105

7.5

A denial-of-service vulnerability affecting Log4j versions from 2.0-beta9 to 2.16.0 (resolved in version 2.17.0)


  • We are now seeing active exploitation of the vulnerabilities. For example, the first "worm" based on the Mirai Bot is active, but also in recent days more than 90 (!) examples have been found of about 15 hacking groups trying to exploit Log4j to post ransomware and/or steal data from organization. Even the most advanced hacking group, CONTI, is now using Log4j as a method of attack.
  • Wortell sees from its Security Operations Center a lot of attempts and scans from IP addresses from China, Russia and from TOR exit nodes, among others. These scanners also look for the presence of VMware in combination with the LOG4J vulnerability.

 

  • To gather specific threat information Wortell has developed its own HoneyNetwork; a collection of Honeypots (decoy computers) that pretend to have the Log4j vulnerability. From there we get a good idea of the scans, the IP addresses used, the attack methods tried and the scripts/tools used. These are collected for analysis, and is input to our Managed Detection & Response service.
  • Version 2.16 of Log4j does not yet appear to be completely foolproof. In that version it is possible to perform a denial-of-service attack (making the entire application unavailable). It is therefore necessary to install version 2.17 which solves this problem. This can be downloaded here: https://logging.apache.org/log4j/2.x/download.html  

 

  • Attacks using the Log4j vulnerabilities are becoming increasingly complex. Due to this complexity, it is not possible to rely solely on network security (WAF, NextGen Firewall, etc). We recommend using endpoint security such as Microsoft Defender for Endpoint (MDE) in addition to network security.

Wortell products and services

Our customers ask us if the products and services they receive from Wortell are secure and do not contain Log4j vulnerabilities. In recent days Wortell has done extensive research.

The products and services that Wortell provides are very diverse: we resell third party services and software, we provide Managed Services in which the security responsibility is shared with customers, we have in-house developed software and services, and we also provide as-a-service products (such as Debble).

Wortell has compared the NCSC list with software in use, but in addition there have been active investigations such as scanning the environment, and checking log files. There has also been extra research from the Managed Detection & Response department (hunting) and extra detections have been made (use cases).

Based on this research we have come to the following insights:

Name Details State & Comment
Cloud Mission Critical Azure
  • No Log4j in use
Debble  
  • No Log4j in use
Managed Services

Netherlands

Belgium

  • Log4j found, software patched and mitigating measures taken
Meet

Teams Rooms

Teams Calling

  • No Log4j in use
Secure Managed Detection and Response
  • No Log4j in use
Smart  
  • Log4j found, software patched and mitigating measures taken
Videobutler  
  • Log4j found, software patched and mitigating measures taken
Work

Work

Teams Governance

  • Log4j found, software patched and mitigating measures taken

 

Note: Although Wortell has done its utmost to be as complete and accurate as possible, no rights can be derived from this report. The research was limited to the applications and components that Wortell manages or develops. Wortell does not accept any liability for (external) applications outside of Wortell’s control.

Log4j update 22 december 2021

  • The major newspapers are writing extensively about the Log4j problem. The Washington Post talks about the "most serious security vulnerability ever," the Wall Street Journal writes that the vulnerability "is likely to persist for months," and the renowned MIT wonders "why the Internet runs on free open source and who should fix it now. The Financial Times published a study showing that "over 1.2 million attacks have been attempted in the first few days, including from the Chinese government. The Dutch NCSC also wrote an extensive article on 'Ransomware and how to defend yourself'

 

  • What adds to the complexity of the Log4j problem is that the server that is connected to the Internet does not also have to be the server that receives the hacking attempt. In this diagram, you can see that internal servers can also be hit. It is therefore recommended to check all servers (e.g. via a scan) and look beyond the machines that have Log4j installed.
  • Do you use cybersecurity insurance? Some insurers have announced to start excluding coverage for Log4j. At the (annual) renewal they can effectuate this. Wortell therefore always recommends the 3V model: prevent, remedy and insure. Through our Managed Detection & Reponse (MDR) service we can arrange 24.7 monitoring for you in the coming period, including for Log4j.

 


  • Statistics from our Security Operations Center show that attackers are active during the Christmas period and during vacations. We therefore advise you to be extra vigilant during these days and follow up on security alerts. Do you want these reports to be followed up 24.7 by a specialist team? Then our Managed Detection and Response service is ready for you.

 

Log4j update 29 december 2021

  • As of last night, December 28, it is known that a new vulnerability (CVE-2021-44832) has been discovered by Apache in several (previously secure) versions of Log4j. This vulnerability requires that the attacker has rights to modify the configuration. This ensures that the chance of exploiting the vulnerability is lower but the advice is still to update to a secure version.

 

As of the following versions in Log4j 2.17.1 (Java 8), 2.12.4 (Java 7) and 2.3.2 (Java 6), the above vulnerability has been mitigated and found to be safe. In the table below you can see well the classification by version:

Version Classification
2.17.1 Secure
2.12.2 Unsecure
2.17.0 Unsecure
2.16.0 Unsecure – Contains a denial of service vulnerability
2.15.0 Unsecure  – Contains a vulnerability that allows local "lookups" to be performed
< 2.15.0 Unsecure – Contains a vulnerability that allows "lookups" to be performed to remote systems (the Log4Shell vulnerability)

 

 

  • Wortell Managed Services customers are proactively approached if (new) vulnerabilities are found within the scope of management.

 

  • Do you need help mapping these vulnerabilities? Then we can help you with our Log4j scan.