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.
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 mechanism 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!