en
en
Ralph Moonen - Principal Consultant
Vulnerabilities have been found in Apache Log4j, named Log4Shell (formally known as CVE-2021-44228). Many web applications and other systems globally use this software which could cause serious damage in a very short timeframe. The vulnerability has already seen an effect with Twitter, Amazon, Apple, Tesla, and more.
What will you find on this Log4j update page?
Bureau Veritas Cybersecurity has assisted numerous customers in identifying vulnerable instances of Log4j or performing forensic analysis on servers that were (potentially) compromised. During that time, new vulnerabilities in Log4j were also discovered and hyped. Luckily, the current situation seems to be that active exploitation is not very common. We say this with some reservation, because the threat model for this vulnerability is so different from other vulnerabilities that it is very plausible that there will be new and innovative attack vectors discovered in the future.
For now, it is important to note that version 2.17.1 was released to address a security issue that turned out to be only of very limited impact. Therefore it is not acutely necessary to run out and patch again. If you run 2.16.1 you are still protected against Log4Shell and any known variants. Bureau Veritas Cybersecurity will continue to monitor the situation and provide updates here in case of any changes.
If you are still unsure what to do or wish to gain insight into your security, please don’t hesitate to contact us.
Log4j is a widely used component in all kinds of environments. It has recently become known that a serious vulnerability exists that impacts many other products, applications, and systems because it is embedded in many software solutions. Bureau Veritas Cybersecurity is in close contact with other security organizations such as Cyberveilig Nederland and the NCSC to coordinate helping our customers deal with the fallout of this new vulnerability. Our testers have incorporated tests for this vulnerability into their standard workflow. But you still might have questions on what to do and how to react. So we would like to suggest some steps that you can take to lessen the risk and mitigate this issue.
But first, it is important to understand the issue. It works like this: if an attacker can get a specific attack string logged through log4j, this string will trigger log4j to make a connection to an attacker-controlled host, and download a piece of attacker-provided code and execute that. So what kinds of things are logged? Quite a lot, it turns out! It could be a username, an email header, a website cookie, really anything could get logged somewhere along the way. And to complicate things, sometimes things are logged at a later date, or only after a certain number of events have occurred. For instance, some logging mechanisms might only log a failed login attempt after ten or more attempts. So it is difficult to test all possible injection vectors. It is entirely possible that all your externally internet-exposed servers are not vulnerable, but a backend internal application server is. The point is, an attacker can spray the strings around and hope it will find vulnerable components at some time. At the time of this writing, vulnerable products include many mainstream solutions: Jira, Confluence, Splunk, Elastic, VMWare Center, and many more. Some are actually security products!
Luckily the Dutch NCSC is tracking known vulnerable software. They are also providing IOCs and mitigations. So instead of providing these here, we will redirect everyone to their repository.
Figure out where you are using log4j or a vulnerable product that uses log4j. Check the list at https://github.com/NCSC-NL/log4shell regularly because it is updated continuously!
Patch your software, or apply one of the mitigations mentioned in the link to the NCSC GitHub repo. Don’t forget: it’s not just internet-facing systems that can be attacked.
If you can’t patch or mitigate, make sure that a vulnerable server cannot make an internet connection as a temporary solution.
Configure your IDS and SIEM to block the IOCs and implement detection rules, again we refer to https://github.com/NCSC-NL/log4shell for this information (and keep it up to date because there are also many ways to bypass the detection rules).
If you have indications of compromise of a server, take the standard incident response and forensic measures: isolate, contain and investigate.
It is clear that most organizations are at risk currently since the exploit is so easy and the vulnerability so widespread. Knowing what you have (asset management) is extremely important and knowing what software components you use (SBOM)
Also, we expect not just IT systems, but also OT systems to be impacted by this vulnerability. Due to the often embedded nature of applications in OT environments, we expect it will take a lot longer to know and find out what OT products are especially vulnerable. But it is very plausible that OT data historians and loggers will turn out to be vulnerable.
We will update this page when new developments or information become relevant. For our customers, please contact your account manager if you have any questions concerning this vulnerability.
On Thursday 6th of January, our Technical Director, Ralph Moonen, will host the live webinar: "Log4j, Latest Insights and How to Stay Secure?", during which you can ask all your questions. Want to attend this webinar? You can now sign up here.
