CVE-2021-44228 is a rare 10 out of 10 rated flaw in Apache Log4j which is widely used including in software from manufacturers like Amazon, Apple iCloud, Cisco, Cloudflare, Tesla, Twitter, and video games such as Minecraft. The latter has already been breached simply by typing a specially crafted message into the chat box resulting in unauthenticated remote code execution (RCE) on Minecraft Servers.

It’s a HUGE attack surface that’s being actively exploited, so the race is ON between the attackers and defenders. Having been on the front line during the major 2014 incidents, Saepio’s vCISOs have shared some learnings to help educate and guide response plans:

When dealing with a vulnerability as wide spread as log4j, defenders have a huge disadvantage over attackers in that they only catalogue applications at the top level i.e, the Office suite, Adobe, Salesforce, Oracle, Vmware, and so on. They don’t catalogue what components those applications are made up of so it’s like trying to find needles in a haystack when it comes to identifying what assets are exposed. To give an analogy, if there were an issue with a food ingredient such as high fructose corn syrup, most people would struggle to know what items in their cupboards and refrigerator contained this ingredient. Worse still, high fructose corn syrup is essentially sugar so even if you used sweetened foods as your initial filter you would have to check every single item to be sure you weren’t exposed.

On the attackers side, they can use any tool they like to fingerprint your publicly facing assets (and internal assets if they jump the firewall) so they are already three steps ahead. Continuing the sugar analogy, log4j is just one flavour logging code that you can find in an application, so you have to check everything to decide which one is vulnerable. The attacker needs to find just one to exploit before you patch it.

The next problem is like sugar, log code is in absolutely everything. All the java and web applets on websites, the remote login pages for routers and wifi points and just about every internet of things device ever made. In both poodle and heartbleed we had not realised the extent of SSL and TLS certificates that were being used in networks as these typically weren’t catalogued. This was one of the drivers to include cataloguing of certificates and anything else that if compromised could impact the confidentiality, integrity or availability of business critical systems in NCSC’s Cyber Assurance Framework.

So to bring it all together for some additional and helpful advice, the approach to follow when considering a remediation plans is:

1. Assume the vulnerability could be in any IT asset you use and not just web-based applications.
2. If you don’t have vulnerability scanning tools in place already across your entire estate then procure some or alternatively use open source tools like the attackers would but follow your internal change controls procedures to gain approval to scan yourself.
3. Once you have the full list of assets impacted prioritise those which are most critical to the business and are easily able to be exploited and agree the priority order to remediate.
4. Can you apply compensating controls for critical systems before you get to patch it?
5. Dedicate resources to remediate until all high priority systems are patched.

There’s plenty more detail on the Log4j vulnerability with technical remediation guidance from our friends at Automox and Rapid7.