“log4j 2” – a perfect way to ruin a security professional’s weekend
By Paul Watts, Distinguished Analyst at the ISF
By now Members will be very familiar with the concern around the ‘log4j 2’ remote code execution vulnerability; Apache’s java-based logger library also known as ‘Log4Shell’. This vulnerability is filed as CVE-2021-44228 in the NIST National Vulnerability Database. If this is news to you, perhaps skip to the bottom of this blog post and read the NCSC Advisory.
For those who are very aware and have spent the weekend on back-to-back calls, you have my sympathy and my best wishes – as easy as it is to say, make sure you take some personal time to rest and to eat; as they say on the airline safety briefings, “put your own face mask on before helping others”.
The prevalence of this library across all manner of devices and services puts it way up the list of ‘things to really worry about in 2021 if you are a cyber security professional’. In reality your business leaders should also be worrying too; many enterprise applications will be affected and in a number of cases, patches are not immediately forthcoming.
There is evidence of there being in the wild exploitation and both CISA and NCSC are reporting widespread scanning for this vulnerability by threat actors. Weaponised, exploiting this vulnerability will allow an attacker to execute code on the affected host – with potentially devastating consequences. This also does not need an experienced hacker to exploit either, this is a reasonably simple process to achieve making it all the more dangerous.
The steps to take are simple on paper, but can be very complex depending on the size and sprawl of your estate. The current (at time of publishing this blog) version of the library – log4j 2 2.15.0 – is the version to be aiming for which addresses this vulnerability. Ideally, you need to be identifying and patching across your estate as soon as possible, working with vendors to ensure patches to their applications are speedily released and hastily applied. There is a mitigation of sorts for those running version 2.10 and later, which is to set the system property “log4j2.formatMsgNoLookups” to “true” or to remove the JndiLookup class from the classpath.
The NCSC advisory can be found at https://www.ncsc.gov.uk/news/apache-log4j-vulnerability and some indicators of compromise (IoC) can be found at https://github.com/curated-intel/Log4Shell-IOCs (disclaimer: these links are third party and not controlled by the ISF).
The speed at which declared vulnerabilities can be turned into effective weapons shortens as each month passes. Events such as these serve as a reminder that as security professionals we exist in a vacuum of a rather large game of ‘cat and mouse’ when it comes to vulnerability management. Having a good plan helps to stay on top of things, particularly with a nasty vulnerability such as log4j 2. Maintaining a good inventory of your estate and having a good grasp of your vendor dependencies is equally critical so your plan can be expedited. And of course, keeping on top of your patching and technical debt are important when maintaining your levels of hygiene.
All of this is easily said, but remains a panacea that most of us find incredibly difficult to achieve.