Forensic Readiness Assessment(alleen beschikbaar in het Engels)
Log4Shell: How does it work and what steps to take?
Datum:
13 december 2021 |
Author(s):
Ralph Moonen - Technical Director
13 december 2021 |
Author(s):
Ralph Moonen - Technical Director
UPDATE 3/1/2022
In the past two weeks, Secura 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. Secura 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.
What is Log4J?
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. Secura is in close contact with other security organisations 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.
How does Log4Shell work?
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! 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 10 or more attempts. So it is difficult to test all possible injection vectors and 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 vCenter, and many 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.
Steps To Take
- 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 standard incident response and forensic measures: isolate, contain and investigate.
Asset Management
It is clear that most organization 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, see https://www.ncsc.nl/onderzoek/onderzoeksresultaten/software-bill-of-materials-sbom-en-cyber-security-map).
OT Systems
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.
Further Updates
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.
Live Webinar: Log4j, Latest Insights and How to Stay Secure?
On Thursday 30th of December, 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.