Are you vulnerable to Log4J? The answer is most likely “yes.”
By now you may have heard about a new vulnerability making the rounds. The underlying software that is vulnerable is an open-source application called Log4j by the Apache Foundation. How bad is this new vulnerability? It’s bad. I mean really bad. A successful exploit of a vulnerable system can give the attacker full control over that system. That means they can install other software, use that system to attack other systems, install ransomware, you name it.
At this point, you might say to yourself, “Good thing we don’t use that software.” Unfortunately for almost every organization, just because you have not directly deployed this application, does not mean you are safe. Why is that you ask? The reason being is that many of the biggest names in tech (and many of all other sizes as well) use this piece of open-source software within their own products. If you use any of these affected products, then your environment is now vulnerable as well. So now the question becomes, “how do I know if something in my network uses log4j?” That is the million-dollar question. Finding out what open-source components are embedded in the products you buy has always been problematic at best. At this moment, the best way is to inventory the devices you have in your network, particularly any device that is accessible from the Internet, and start contacting those vendors to find out whether they are vulnerable to this exploit. If you have a vulnerability scanning solution, such as Qualys, you can now use that to start identifying vulnerable systems as well.
So now let’s assume that you have found out that you indeed do have this vulnerability in your environment, how do you protect yourself? Normally this is where we would say you need to update your systems right away. The problem right now is that many vendors do not have an update at the time of this writing. So now we need to look at mitigating the threat until a permanent resolution is available. When we talk to our clients, we talk about defense-in-depth to better protect against advanced threats and now especially against these fast-evolving supply-chain attacks. What is defense-in-depth and how does it benefit you? Think of security as an onion. Each layer of that onion is another form of protection. On the outside, you have your next-gen firewall. The layer inside that may be your email security or your web proxy. Inside that, you have you advanced endpoint protection, and so on. While no single layer is fool proof, by layering protections on top of each other, you begin to cover holes in one layer with protections in another.
Back to my earlier point about this being bad. From a pure vulnerability standpoint, this is about as critical of a vulnerability as you will see. What makes is so much worse than others is that instead of being on one or a small handful of systems on your network, it may be on dozens or hundreds, all without your knowledge. As a security community, I’m confident that the affected vendors will provide updates quickly and this will be mitigated over the next several weeks. The take-away from this event should be preparing ourselves for the next time this happens, because I promise, this will happen again.
If you would like assistance identifying this or other vulnerabilities in your environment or would like to discuss building a defense-in-depth security implementation to protect against future supply-chain attacks, we’d love to have a discussion with you. Contact us today to learn how we can help you mature your security posture.
Additional Information from some of our Vendor Partners Regarding Log4J
- Cisco – Vulnerability in Apache Log4j Library Affecting Cisco Products: December 2021
- VMware – VMSA-2021-0028.1 (vmware.com)
- NetApp – CVE-2021-44228 Apache Log4j Vulnerability in NetApp Products | NetApp Product Security
- SentinelOne – CVE-2021-44228: Staying Secure – Apache Log4j Vulnerability
- Palo Alto – https://security.paloaltonetworks.com/CVE-2021-44228
- Arctic Wolf – https://arcticwolf.com/resources/blog/log4j
Vice President, Infrastructure Services