This is how we are handling the Apache Log4j vulnerability
Latest update of the information document Apache Log4J based on recent developments:
- The potential impact of vulnerability CVE-2021-45046 is bigger than previously thought, the CVSS score has been increased from 3.7 to 9.0.
- A new Log4j 2.x vulnerability has been discovered, CVE-2021-45105, with a CVSS score of 7.5.
16 DECEMBER 2021
A week ago, the National Cyber Security Centrum (NCSC) drew attention to a vulnerability in the widely used Apache log system Log4j (reference CVE-2021-44228, or Log4Shell). Since then a worldwide race has started between security experts and attackers, including state actors and criminal groups, to either patch or exploit this vulnerability. In this article we explain more about this vulnerability and what you can do to patch it and minimise the impact. In addition, in this document (Dutch) you will find more information about Log4j and the measures we take to reduce the impact on customers to a minimum.
A specific problem in this scenario is that Log4j is a commonly used software subcomponent in applications. Many organisations probably do not know that they are users of this code. It depends on the application that uses the Log4j component, which you may or may not manage yourself.
Priority Level: High/High
The vulnerability has the highest priority level, a score of 10/10, by the CVSS scoring system. Attributing such a high score is due to several factors:
- The impact of this vulnerability is very high: could lead to remote code execution on the compromised server, which could allow malware to be executed and executed.
- The risk of this vulnerability is very high: it is relatively easy to exploit the underlying vulnerability. An attacker only needs to force a vulnerable application to log a certain string. Since apps register many types of events, there are several ways to do this. It can be as simple as typing a message in a chat box.
The ripple effect can include sensitive data exfiltration and ransomware attacks, which can last for months or years.
Solvinity’s security experts and customer engineering teams are in daily dialogue with each other and our customers. We have a pretty good understanding of where risks can be and we monitor and analyse these systems for malicious behavior. We closely monitor the latest developments and follow updates from (potentially) affected suppliers. We have a direct line with the NCSC. Developments follow at a rapid pace and our knowledge improves by the day. Yet new components can still be discovered that we didn’t know were vulnerable.
We advise organisations to: install the available update as soon as possible and monitor the advice of the NCSC closely.
- Find where Log4j is running in the environment.
- Patch immediately by upgrading, or perform a workaround.
- List all the parts from that Log4j is running.
- Ensure security operations (SecOps) teams execute any alert surrounding Log4j.
- Quickly detect vulnerable applications.
We have summarised our findings in this document (Dutch). Here you can read in detail about the impact of the Apache log4j vulnerability on various applications. We also explain how Solvinity has protected itself, to minimise the impact on its customers, and what is still under investigation.
Tip: on 15 December 2021, the NCSC, together with Digital Trust Center and the CISO DSP, held a live webinar about this Log4J vulnerability with information about the situation and what you can do as an organisation. The webinar (Dutch) can be viewed here.
All in all, this is a vulnerability that needs to be taken very seriously. We expect to hear and read about it for a long time to come.
If you have any questions, please contact your Customer Service Manager or Customer Engineering team.
Sign up for the Solvinity Newsletter
Receive the latest news, blogs, articles and events. Subscribe to our newsletter.
Discover the most important conclusions from our minor class, organized with the Digital Ecosystems Institute, and...LEES MEER
Better insight into cyber criminals and continuous validation of your security? Read in this blog how...LEES MEER