For anyone in the cybersecurity space, there is never a dull moment. Almost every week, news comes out about potential new vulnerabilities affecting some hardware or software product. One specific vulnerability called a zero-day vulnerability often receives more attention than most.
So, what is a zero-day vulnerability, and how do we protect our environment against it? We will cover all of that and more in this post.
What is a zero-day vulnerability?
A zero-day is a vulnerability in a system that is being exploited without the security team being aware that the vulnerability exists. When you learn about a zero-day, it is already too late. When a new zero-day is announced, a threat actor is already exploiting the vulnerability. This gives security teams little time to prepare and deploy their defenses. If a patch is announced at the same time, the patch should be deployed within hours because there is no time to waste.
Examples of a zero-day vulnerability
An example of a zero-day vulnerability is Log4J. It might be the most well-known zero-day vulnerability, initially released in 2021. It received the CVE code CVE-2021-44832 and was rated as a severity 10 – the highest possible rating. The vulnerability consisted of an issue in the open-source logging library ‘Log4J’ used in applications such as Apache.
When this vulnerability was announced to the world, no patch was available. This meant security teams worldwide scrambled to see how they could detect and block potential exploitation attempts. The main difficulty of the Log4J vulnerability was the fact that this was a library used throughout a variety of different tools. Tools like JIRA Atlassian and MobileIron used the library, which was unknown to security teams.
Because no patch was available and security teams did not know whether they were affected, it was tough to protect against an attack. One organization I work with was breached within four hours of the vulnerability being announced. Four hours is an impossible time frame to defend against, since there is no time to investigate where it was used and to set up defenses against the attack.
How are zero-days identified?
A zero-day vulnerability can be identified and announced to the public in multiple ways. Sometimes, an organization is attacked, and the security team identifies the flaw during their research. Some security researchers might bump into a zero-day by ‘accident’ and report the vulnerability to the vendor.
For example, the recent Outlook vulnerability (CVE-2023-23397) was identified by Ukraine’s CERT (Computer Emergency Response Team). The team determined that the vulnerability was carried out by a Russian state actor who had identified and abused the vulnerability. Research had shown that the vulnerability had been exploited for up to a year before it was publicly disclosed. It is only because of the research of Ukraine’s CERT that Microsoft is aware of this vulnerability and was able to patch it. This makes collaboration between security researchers and hardware/software vendors so important. Vendors are not always aware of what flaws are hiding in their software and depend on security researchers to identify and flag them. That is why bug bounty programs are so important, as they will incentivize a security researcher to report the vulnerability instead of selling it on the black market.
How many zero-days are there?
The Outlook vulnerability is an example of a zero-day that was exploited long before it was publicly disclosed. This raises the question of how many unknown zero-days still exist in the wild. That question is impossible to answer, which makes it scary. As a defender, you have no idea what tricks an attacker has up their sleeve and what vulnerability they can abuse. Because of this, it is important to protect yourself at multiple levels.
How to combat a zero-day vulnerability
Now that we know what a zero-day vulnerabilities are and how they come alive, you should know how to combat them. Unfortunately, there is no single answer to that question. That is because every zero-day is different; some zero-days have a patch available while others have not. You have to take four critical steps while defending against a zero-day.
- Conduct an extensive tech inventory
- Be prepared to deploy patches rapidly
- Build up your walls
- Assess the impact
Conduct an extensive tech inventory
Knowledge is key. This first step is often forgotten, but is probably the most important step in combating zero-days. Every organization should have an extensive inventory of all software and hardware used in their environment. The Log4J vulnerability showed how important this was. The real difficulty was not building detections or patching, but finding out if you were even vulnerable. Because Log4J is a library used by other products, organizations had no idea what the impact was. Most did not even know if they used one of the hundreds of vulnerable software applications.
Because of this lack of knowledge, security teams worldwide lost valuable time. Instead of taking protective measures, they were in discussions with stakeholders throughout the organization to identify the attack surface.
Every organization should have an overview of all used software and hardware vendors, prioritizing public-facing resources first. This list should cover firewalls, web servers, client applications, etc. While this is a very time-consuming task, it is paramount for a swift response to the next zero-day.
Be prepared to deploy patches rapidly
If a zero-day is announced, a patch is sometimes available that fixes the vulnerability; other times, a patch is only available a couple of days/weeks later. Nevertheless, the patch should be deployed as soon as possible, as it will protect your environment from being exploited. Organizations are often ill-prepared when a patch rolls out for a highly critical vulnerability and scramble to identify the correct stakeholders and schedule downtime. These kinds of processes and approvals should be made beforehand. It is important to have a written procedure in which production downtime is allowed when a certain level of vulnerability is identified. In times like Log4J, time is of the essence, and a patch needs to be deployed in hours instead of days. You are losing valuable time if you need to find the correct stakeholder to get the approval.
Build up your walls
Deploying a patch that fixes the critical flaw in an application is often the only step organizations take in defending against zero-days. In case of a zero-day, you are often too late as you are protecting yourself from the unknown. You should lead the effort in helping your organization put up as many defenses as possible and harden the environment. You must build walls, disable unused features and protections, implement segmentation, and secure privileged accounts. By implementing these countermeasures, the threat actor will have a much harder job exploiting zero-days and moving laterally in your environment. You might be unable to prevent a threat actor from exploiting an unknown zero-day. Still, you can ensure your environment is challenging to move around, so the threat actor cannot further impact your environment.
Assess the impact
Earlier in the article, we mentioned that a zero-day is exploited before publicly disclosed. This means you are not out of the woods if you have implemented a patch. After deploying the patch, you must dive into the logs to determine if a threat actor has abused the vulnerability. By assessing the logs, you can say with 100% certainty that this zero-day did not impact your environment.
Waiting for the next zero-day to be announced…
After you have implemented as many defenses as possible, it is time to wait for the following zero-day vulnerability to be announced. The number of zero days has been increasing in the past few years, so the chances of having a new zero-day around the corner are high.
Every organization should take the time to review its environment, ensure it has an inventory, set up processes to deploy emergency patches, and build up as many walls as possible. Because the next zero-day vulnerability is just around the corner.
