Now that some of the initial panic around the Log4j security vulnerability has died down, now's a good time to look at how significant an impact it had - and what we can learn from it.
Now that some of the initial panic around the Log4j security vulnerability has died down, it is perhaps time to look at it and see what happened, what the sequence of events were, how significant was the vulnerability and what impact it had.
Log4j is probably the most widely used logging framework in the Java world. It is literally ubiquitous as we mentioned back in December in our post (Log4J – not the yule log you were hoping for!).
The list of affected software is huge (see Log4shell). This includes web servers, financial applications and even games (such as the Java version of Minecraft). This is in part why this security vulnerability is do dangerous, Log4j is just so very, very widely used. It is compounded by the fact that it has taken Apache several attempts to fix the original vulnerability and further vulnerabilities since identified throughout December 2021.
The security vulnerability was first reported by Chen Zhaojun of Alibaba, China’s largest e-commerce company, on 24 November 2021. This vulnerability is applicable to Log4j version 2.0-beta9 through to version 2.15 and thus affects all production versions of Log4j version 2.0 up until a fix was released. Notably forensic analysis suggests that cybercriminals have been exploiting the vulnerability since at least 1 December 2021.
The security vulnerability, initially identified is known as Log4Shell (or LogJam), is also recorded as CVE-2021-44228 in the National Vulnerability Database (or NVD). It is referred to as a zero-day vulnerability meaning that hackers and other individuals may well have known about this issue before a fix was available, thus you have zero days to fix it (in other words you must fix it asap). It was also rated a 10 out of 10 on the Common Vulnerability Scoring System, or CVSS, due to its significance.
This leads us to consider the timeline of how Apache responded to this problem:
This understandably caused turmoil for developers and their organisations. For example, if you updated your build on 15 December 2021, this means that you are probably using version 2.16 and are thus not on the latest version leaving you subject to three known security vulnerabilities! It would have resulted in organisations having to repeatedly build, test and deploy their applications over a two- or three-week period - over Christmas no less...
This vulnerability identification-fix cycle is not that surprising as Log4j is still under the scrutiny of security researchers - so we may not even be at the end of it.
Almost all applications require some form of logging and Log4j is widely regarded as the most used Java logging library.
This means that many, many applications are potentially vulnerable to attack. These applications may themselves directly use the Log4J library, may use it via a common logging interface (such as the SLF4J) or via infrastructure that runs the Java program such as an application or web server (see Tomcat as an example).
This means that almost all Java applications should be examined to see if they are vulnerable to these Log4j security issues.
So, what should you do and where do you start?
If your system is currently under development or active maintenance this may not be a problem. It may be a simple matter to update the dependency information for the system (using for example Maven or Gradle) and then to rerun the build process and perform a regression test to ensure that there are no unforeseen or unexpected side effects of the update. As many development teams now use continuous integration environments this may be as simple as updating a configuration file and running the build (and test) process.
Such organisations may also use a Continuous Deployment set up allowing a successfully updated application to be deployed into production very quickly. However, this may not be true for all organisations, where there may be a sign-off or managed deployment process with strict governance - which will need mean many hoops need to be stepped through before the updated system can be deployed.
Of course, it may not be the case that you have full control over the configuration of the application or its libraries. This may be because you are using a third-party application from an external vendor. In such cases ensure that you have installed the latest version of the software and confirm with the vendor that they have successfully addressed the Log4Shell vulnerability.
As with third party applications, if you haven't already, contact your supplier to ensure that they have deployed an updated version of the Log4j library.
Another scenario is that some software is currently in production but there is no active maintenance being performed. Such a system may have been deployed some time ago and "just works."
Typically, there is no spare capacity in your budget to maintain such a system. However, if it is using the Log4j library then it's vital to address - and may well require a rebuild and full regression testing to confirm that all is well before an updated version is deployed.
Don't forget about the modern trend for Microservice architectures. If there are one or more microservices using Log4j within your system, then you need to take action.
All the above requires that information on the libraries and their dependencies, used across an organisation is actively maintained. In many cases this information is distributed across an organisation and maintained only within Maven or Gradle configuration files. In practice having some form of library inventory (which may be automatically maintained via some form of configuration file analytics) can be extremely useful in these situations.
Even if you don't have Java installed on your systems (e.g. added to PATH) there may well be applications with their own self-contained Java Runtime Environment (JRE). There are many scripts already available to help you scan systems for Log4j - for instance this one from Google.
And if you do find any instances, be sure to update to the latest Log4J version (currently 2.17.1) and keep monitoring the situation.
In conclusion, it is important to be vigilant and monitor all reported security vulnerabilities in all the libraries that your software uses. This may be frustrating at times as an organisation attempts to fix a reported problem repeated or further issues are identified.
Here are some great security blogs and news sources to keep your eye on:
If you found this article interesting you might be interested in our Web Application Security with OWASP training course.
