In December 2021 a vulnerability, with a severity score of 10 out of 10, in a widely used logging library became a full-blown security meltdown, affecting digital systems across the internet. The problem lies within the software component Log4j. This blog explores everything you need to know about Log4j and highlights the importance of knowing what is in your software.
The Log4j Vulnerability is Critical
Log4j is a Java-based Apache logging framework that developers use to keep a record of activity within an application. This open source software creates a built-in log or record of activity that can be used to troubleshoot problems or track data within their programs.
The vulnerability inside Log4j has been coined Log4Shell. This vulnerability is relatively simple to take advantage of. It allows attackers to send malicious “messages” into a log server that can be used to execute commands on that server, steal data or even take control of that server.
On the 10th of December 2021, the Log4j vulnerability, with a CVSS score of 10/10, went public, causing a security meltdown affecting digital systems across the internet. The first instance of the Log4j vulnerability is tracked as CVE-2021-44228. There are other vulnerabilities associated with Log4j which were a result of patches failing to fix the entire vulnerability.
CVE, which stands for Common Vulnerabilities and Exposures, is a glossary that analyses vulnerabilities. CVSS (Common Vulnerability Scoring System) scores are one way to measure the impacts of security vulnerabilities (See Figure 1). The Log4Shell vulnerability has been given a CVSS score of 10/10 falling in the critical category. This is the maximum severity rating possible.
The Use of Log4j is Wide Spread
There are two reasons why Log4Shell is so serious, the first centres around severity which is outlined above. The second is that Log4j is so highly used, this makes the attack potential massive.
Many pieces of software have logging libraries. It is highly unlikely that organisations, especially big corporations, are coding their own logging software. There is no benefit to this when an open source version is so easily available.
As a popular logging tool, Log4j is used by tens of thousands of software packages and projects across the software industry. Consequently, Log4j is embedded in a vast array of applications, services, cloud platforms, web applications, email services, and enterprise software tools that are written in Java and used by organizations and individuals around the world. This makes the attack reach potentially millions of devices worldwide.
You may be thinking is there an alternative logging tool I can use? Well, there is (see Figure 2) however, this may not necessarily solve the problem at issue. The Log4j security meltdown was not a direct result of badly written code. The fallout was largely a result of organisations’ poor visibility of their own software.
You May be Using Log4j Unknowingly
The lack of visibility organisations had into their software and its dependencies catalysed the impact of the Log4j vulnerability across the globe. The reality is many organisations did not know they were using Log4j when the Log4Shell vulnerability was disclosed.
Simply put, dependencies are software components that another piece of software relies on. For example, if program A requires program B to be able to run, program B is a dependency of program A.
Dependencies are not actually found in the source code but are pulled in at build time. These are known as direct dependencies. However, it is possible for these direct dependencies to have their own dependencies, these are called transitive dependencies.
If each dependency in the chain has its own dependency it is not hard to imagine how large these chains may get. This is why so many users had no idea they were running affected Log4j versions between the thousands of dependencies in their stack. The severity of the Log4j vulnerability has served as a wake-up call to organisations. It demonstrates you must understand what is in your software and where dependencies lie.
The Security Issue Does Not End With Log4j
Log4j and the impacts organisations suffered were not the first of their kind. These security issues apply to the majority of open source components, albeit the severity may not be as severe.
Vulnerabilities in components such as Apache Struts in 2017 and Heartbleed in 2014 produced similar impacts to the Log4j vulnerability. If you were to compare media narratives on all of these components you will see many similarities.
In 2017 two vulnerabilities found in a component named Apache Struts allowed hackers to conduct remote code execution attacks resulting in several high profile security breaches. One victim was the American multinational consumer credit reporting agency, Equifax. The security breach cost Equifax US$575 million in compensatory fees.
Alaska Airlines were another high profile victim of the Apache struts security vulnerability in 2018. Resolving the issue cost Alaska Airline’s in the region of US$2.5 million. In March 2017 when the vulnerabilities in Apache Struts were researched and disclosed to the public, there were around 100,000 downloads of the insecure version and for the next 12 months, this download rate continued, despite there being an updated version.
Similarly, since the 10th of December 2021, when Log4Shell was disclosed, Sonatype reported that Log4j has been downloaded more than 10 million times (See Figure 3). They state that nearly half of these were unsafe versions, despite the fact fully patched and secure versions were available at the time.
Heartbleed is a vulnerability from 2014 which affects a widely used component called OpenSSL. OpenSSL is used for authentication on secure websites. This vulnerability affected secure websites globally. One attack was made against a UK Council which leaked all their employee data when hackers exploited the Heartbleed vulnerability. The council were consequently fined £100,000. Since the Heartbleed breach, there have been over 100 patches to the component. There are still around 200,000 devices and servers that are still vulnerable to this OpenSSL vulnerability.
The reality is that if vulnerable software projects like Apache Struts, Heartbleed and Log4j have been sitting in the heart of the world’s internet infrastructure, how many others are out there?
This cannot be determined until vulnerabilities are researched and documented. However, you can take action to ensure in that event your organisation is prepared. The key question to dealing with vulnerabilities like those found in Log4j is, on the day the vulnerability is documented publicly would your CTO walk into work and know whether Log4j is in your code?
The fundamental aspect to quickly remediating risk in a Log4j type situation is to know exactly what is in your software. The best practice for this is the consistent production of Software Bill’s of Material’s (“SBOM”).
An SBOM is a formal record of components and their associated licences in a piece of software. It is analogous to a list of ingredients on food packaging. An SBOM identifies and lists software components and their licences and the security vulnerabilities associated with those components (see Figure 4).
If your organisation is consistently producing SBOM’s, on the day Log4Shell was published reference could have been quickly made to the latest SBOM. This would have expressly told you whether Log4j is in your software and whether it is the compromised version.
Continuous management is the next step to securing your solution stack. An SBOM represents one moment in time. The moment the scan was performed. Due to the nature of modern software development, the reality is that software composition may change on an operational day-to-day basis.
Implementing practices’ like this into your business operations is the key to dealing with risks like the Log4j security vulnerability swiftly, with minimal fallout and to secure your software for the future.
2 thoughts on “Log4j Vulnerability: What you Need to Know”