0-day vulnerabilities pose an immense challenge to software developers and enterprise IT teams because how can you fight something you don’t know exists?
In this article, we lift the veil on the dark nature of zero-day vulnerabilities and how software developers and hackers try to outrace each other in finding them.
Table of Contents
What is a zero-day vulnerability
According to the combined Google’s Threat Analysis Group (TAG) and Mandiant report, 97 zero-day vulnerabilities were exploited in 2023, with third-party libraries and components being the primary attack surface. As per the 2024 Data Breach Investigations Report by Verizon, 14% of breaches involved vulnerability exploits, which is three times more than the previous year.
Zero-day (or 0-day) vulnerabilities are security flaws that have been found exploited in-the-wild or publicly disclosed before they were fixed by software vendors. “Zero-day” refers to the number of days a vendor has to fix the vulnerability before it gets exploited by malicious actors.
Not every vulnerability is considered zero-day, it becomes one when there’s no patch available at the moment of discovery.
How do zero-day vulnerabilities land in software? They typically sneak into a program with code changes: the more changes are made, the more difficult it is to spot a flaw. Imagine 10,000+ lines of code introducing a new feature. Reviewers can’t manually take apart every line in search of a flaw, and code analysis tools don’t always notice bugs constituting vulnerabilities despite doing a great job at checking code security.
Zero-day vulnerabilities are especially dangerous because the vendor is unaware of their existence. As these flaws are usually used in toolkits for surveillance, espionage, or highly targeted attacks, stakeholders are interested in exploiting zero-day vulnerabilities for as long as possible. So, it is more lucrative for hackers to sell information about zero-day vulnerabilities than to put them into traditional malware used in mass campaigns, which will be discovered the next day. Another common practice is to use zero-day vulnerabilities in ransomware.
Search for zero-day vulnerabilities is a constant race between hackers and software developers. Ironically, they use similar tools and methods to identify vulnerabilities, including but not limited to static code analyzers and fuzzers.
And to answer the eternal question of which software is safer, open or closed source. On the one hand, it is indeed easier to find a flaw in the generally accessible source code. However, it doesn’t mean that closed-source code can’t be analyzed for flaws. For instance, black-box fuzzing is used to observe application behavior at runtime to spot vulnerabilities without examining the source code.
Also, open-source software usually has a vast community of developers and users that encounter and report bugs or purposefully hunt down vulnerabilities. So, the risk of zero-day exploits is higher with open-source software, but so are the chances that the flaws will be identified and patched before hackers get to them.
Zero day vulnerabilities, exploits, and attacks
There are three terms related to the zero-day concept:
- Zero-day vulnerability is a flaw that exists in the software unknown to the software vendor.
- Zero-day exploit is a code that uses the software vulnerability to compromise the system.
- Zero-day attack is an attack on a system that uses the vulnerability not yet patched by the vendor.
In addition, zero-day vulnerabilities are not to be confused with one-day vulnerabilities, the vulnerabilities for which the patch exists but hasn’t been deployed to the systems using the software yet. “One-day” refers to the period between patch release and integration into the systems, but as this period may be prolonged, such vulnerabilities are also called n-day vulnerabilities.
To create an exploit, hackers reverse engineer the patch to see the issue it solves or use proof-of-concept code released by other actors after the patch is made available.
Zero-day vulnerability lifecycle
As mentioned before, vulnerabilities are introduced into the program with code changes. Vulnerabilities can lurk in software for months or years before being uncovered (for instance, the notorious Log4Shell in the Log4J Java library existed since 2013 but was discovered in 2021). Their further life depends on who found the flaw.
Zero-day vs n-day vulnerabilities
If bad actors get to the vulnerability first, they define the attack vector — the code that can be affected after inputting malicious data — and prepare an exploit. The exploit is used to attack a vulnerable system.
What if the vendor discovers the vulnerability first (thanks to their cybersecurity team or a bug report from users or customers)? A patch is made and introduced with a software update in this case. The vendor informs users about the patch. Users must update the software product as soon as possible to apply the patch. At the same time, information about the vulnerability becomes public, which is when it can be analyzed and exploited as an n-day vulnerability.
How to minimize zero-day attacks
Unfortunately, unknown zero-day vulnerabilities may appear in your project. Fighting them is hard because they are like Schroedinger’s cat, except that, in this case, you don’t even know whether the cat is in the box. Traditional vulnerability scanners and antivirus solutions are no great help because there are no signatures yet.
However, you can proactively guard your project from zero-day attacks.
Reduce attack surface
The attack surface comprises all attack vectors a hacker can use to access your system. So, reducing the attack surface will lower the chance to find a vulnerable object or dependency within the attack surface.
- Implement the principle of least privilege: each user should have access only to resources and system parts necessary to do their jobs.
- Implement zero trust policy: users should have access to the system only if they are properly authenticated.
- Segment the network and use good firewalls: this way, you can block hackers from gaining control of the whole system.
Reduce mean time to patch (MTTP)
Mean time to patch (MTTP) is the average time an enterprise applies patches to vulnerabilities. According to the 2024 Data Breach Investigations Report, patching starts picking up after 30 days only, and 8% of patches still need to be implemented by the end of the year.
Reducing MTTP is critical to protect the infrastructure from attacks. Luckily, a proper patch management system helps implement patches sooner and limits the exposure window.
Working with the vendor to receive fixes and patches for your project as soon as possible is also advisable. For instance, BellSoft offers its customers SLA for a security patch max. 48 hours.
Perform regular monitoring for anomalies
Although you may not be aware of 0-day vulnerabilities, you can spot unusual activity in your network that indicates an attempt at exploiting. For that purpose, continuous monitoring of traffic and log analytics is performed.
To facilitate the task, you can use a network intrusion protection system (NIPS) or a next generation antivirus (NGAV) that spot suspicious and unusual behavior.
Prevent known vulnerabilities from nesting in your app
Even when a vendor releases a patch, you have to meet them halfway and apply it as soon as possible. However, many enterprises are in no haste to update project dependencies or don’t update them at all. As a result, the project contains numerous known vulnerabilities, which makes it highly susceptible to hacker attacks. By the way, Java services are the most affected by third-party vulnerabilities, according to the DataDog’s State of DevSecOps Report.
How do you remedy the situation? Implement a Software Bill of Materials (SBOM) that lists all dependencies used in your application, their versions, and known vulnerabilities. This way, you will always know what is happening behind the scenes of your project. Besides, some legislations already demand the adoption of SBOM in some cases, and nonconformity with legislative requirements may lead to heavy fines or other grave consequences.
Zero-day vulnerabilities are unavoidable, but we can minimize risks of attacks
To sum up, zero-day vulnerabilities will inevitably appear in software because of the complex coding processes. They are especially dangerous because nobody knows about their existence until they are discovered.
However, we can prevent zero-day attacks or at least minimize their risk. Software vendors and developer communities are constantly hunting for and patching vulnerabilities. Some vendors initiate bug bounty programs to involve independent researchers in the hunt.
You can implement the tools and best practices mentioned above to protect your project from attacks. And you can also contribute to the zero-day-hunt by reporting bugs you discovered to the vendor or the community.
So, let’s consolidate our efforts and work on software security from zero-day of its development!
