Over the last few months, everyone has been busy patching — seeking to close the loophole that many learned about on December 10, when the Apache Software Foundation released Log4j 2.15.0 for Java 8 users to address the remote code execution (RCE) vulnerability CVE-2021-44228. RCEs allow attackers to gain full control of an infected machine, enabling them to execute system commands; write, modify, or read files; connect to databases; and much more.
U.S. Homeland Security Secretary Alejandro Mayorkas called it “one of the most critical cyber vulnerabilities ever encountered.”
The National Vulnerability Database (NVD) ratesCVE-2021-44228 as 10.0, the highest rating possible. The first Log4j vulnerability is easy to execute, meaning it does not take a lot of technical knowledge or skill to use it. Log4j itself is a commonly used component that many developers use to understand how their programs function, which is why it is imperative to look for and patch it not only in your own code, but make sure it has been patched in all software in use throughout your organization.
The complexities of patching
The rush to patch is understandable; it is a nearly Pavlovian response in the cybersecurity community to disclosure of a severe vulnerability. Attackers are scanning to find potential victims vulnerable to attack, and nation-state and individual hackers alike are already launching attacks. Patching Log4j is complex, and it is important to understand why:
- It is hard to determine the extent of the exposure because you do not know all the dependencies in your own and third-party software components. It is impossible to immediately determine how many assets are exposed, so your first step is to identify your risk exposure. Many of the solutions you use every day are impacted: see the Cybersecurity & Infrastructure Security Agency’s curated list of affected vendors, products, and available updates.
- It is not easy to identify the risk to an organization. To do that, you need to know not only whether your organization uses the Log4j package, as stated above, but also how it is related to your crown jewels — those assets that are most critical to accomplishing your organization’s mission.
Even when you understand your own exposure, through internal applications and third parties, the process of patching is challenging. Patching takes time and may have an operational impact on your organization. You may need to put other workarounds in place until you have the time to apply patches without significant disruption to your business. Adding to the confusion, the patches for the vulnerability CVE-2021-44228 came with their own vulnerabilities — Log4j 2.12.2 for Java 7 users and Log4j 2.16.0 for Java 8users addresses an RCE vulnerability in Log4j 2.15.0 — CVE-2021-45046, while Log4j2.17.0 for Java 8 users addresses a denial-of-service (DOS) vulnerability in the previous release — CVE-2021-45105. CVE-2021-44832 is another RCE vulnerability via the JDBC Appender. The patch can itself create additional exposure, so you need to think beyond a single vulnerability.
The patching process is similar to a Pareto distribution, or the 80-20 rule: once a patch is available, 80% of the loopholes might be fixed with just 20% of your time and effort. To fix the remaining 20% of loopholes, however, you need to expend 80% of your efforts. And there will always be a small portion of your digital footprint that is not fully patched or protected from the vulnerability, whether that risk lies in your own network or through third parties. On the other hand, an attacker needs just ONE way in. While covering 80% of the loopholes in 20% of the time seems like a very cost-effective approach, you still need to manage the risk coming from the 20% of loopholes remaining.
Understand your blind spots
Right now, there are two things at play: your organization is at risk from the Log4j vulnerability and you’re now aware of a previous blindspot. The rapid releases of patches for Log4j vulnerabilities create momentum for identifying and patching vulnerable components, but that is not enough. You also need to understand that attackers do not wait for a vulnerability notification to try to get into your system. The vulnerability in the code existed long before the patch, so you may have had that door open for a year… or two. You may have already been compromised, unknowingly. Unfortunately, patching does not automatically remove cybercriminals from your environment.
In the industry, the true blind spot is the period of time between when the vulnerability entered the codebase and when the vulnerability was disclosed. Usually, the industry thinks of a zero-day vulnerability as the time between disclosure and when a patch is available— T1 in the timeline below. As evident from the patching frenzy related to Log4Shell, criminals rush to exploit zero-day vulnerabilities to gain access to your systems before you apply all the necessary patches or compensating controls.
This is not the right approach. Instead, it’s important to think of zero-day vulnerabilities in terms of when the vulnerability entered the codebase. That period is described as T3 in the timeline above, which is a much longer period. This is a time of unknown attacks, when the vulnerability existed, but ethical hackers are not yet aware of it. This is a period of time when cyberattackers may have been exploiting that vulnerability, creating backdoors that will let them in to exfiltrate data, execute a ransomware attack, or otherwise compromise your systems. During T3, hackers may be preparing for a future attack calculated to cause significant chaos to your business and maximize their chances of getting paid, for espionage purposes, or with some other long term goal in mind.
Focus on these 3 key challenges
There are three key challenges for the software industry in responding to Log4j: discovering when attackers entered your environments via the vulnerability, patching the vulnerability, and increasing your readiness to respond to an attack. A few things to keep in mind:
- Your organization has been at risk for as long as the vulnerability itself has existed in your environment.
- It takes time to apply patches. Sometimes it’s complicated to apply the patch because there are dependencies that impact when and how you patch. Furthermore, the patch itself may not be good, necessitating further patching. Until patching is perfect, your organization is at risk.
- You can only do so much to prevent an attack or close security holes, so you need to spend time on detection and response efforts to discover backdoors and indicators of compromise (IOCs).
There is a great deal of valuable information already available about what needs to be done to prevent your environment from being attacked using a Log4j vulnerability, and yet more about how to detect an ongoing attack with this vulnerability. All of this information is helpful and valuable, but it does not address the critical question of what you need to do to see if your organization has already been hacked using the vulnerability in Log4j.
The entire cybercriminal industry is trying to make the best of this gift that they have, and the average company faces multiple challenges. For as long as you have a vulnerable version of Log4j, the door has been and remains open – attackers will find it easy to break the locks until you change them. The patching process is so extensive in this case that it may take months, so patch quickly, but do so carefully. Assume that your organization will be attacked — don’t wait for that to happen. The time you spend now getting ready for that possibility will increase your resilience before an incident and reduce the severity of impact if or when those attackers use their back door.
