Our applications and operating systems may have vulnerabilities inside that we simply haven’t discovered yet. In this video, you’ll learn about zero-day attacks and how to protect against them.
The operating systems and applications that you use every day may have a security vulnerability inside of them. The problem is that we haven’t identified that vulnerability quite yet. But somebody is working to try to find a vulnerability, either in the operating systems that you’re used to using or the applications that you’re running on your system. Obviously, the attackers are trying to find these vulnerabilities before the manufacturers find these vulnerabilities.
And fortunately, there are researchers that are also hunting for these vulnerabilities so that they can tell the manufacturer where these problems might be found. The attackers, of course, aren’t interested in telling the software developer where their problems are. They want to keep these vulnerabilities to themselves and be able to use them for their own gains. We refer to these vulnerabilities that have never been identified and that have never been discovered or announced as a zero day vulnerability.
These types of vulnerabilities are obviously a huge concern for an organization because once we discover the vulnerability exists, there haven’t been any patches or methods of mitigation that could prevent this vulnerability from being exploited. If you’d like to keep track of what vulnerabilities have been found and what applications are operating systems are associated with those vulnerabilities, you can check the Common Vulnerabilities and Exposures database, or CVE. That’s found at cve.mitre.org.
Here’s an example of a significant zero day vulnerability was found this was announced on December the 9th of 2021, and it dealt with a service called the Log4j service, and it provided a remote code execution for the attacker who was able to exploit this vulnerability. Log4j is a logging service written in Java and it’s commonly included with Apache web servers. This is installed literally on millions of devices around the internet.
And so when we identified this vulnerability in December of 2021, we realized it had always been part of the code since September the 14th of 2013. To get an understanding of just how severe this particular vulnerability was, we can look at the CVSS number. This is a number between 0 and 10 that describes just how bad this type of vulnerability, is where 0 is not a problem at all and 10 is the worst possible vulnerability you can have.
And you can see the CVSS associated with this vulnerability was identified as a 10.0 or a critical vulnerability. Fortunately, five days after the vulnerability was announced on December the 14th, there were patches available, and we began patching and trying to fix all of these millions of servers. Now that additional eyes are looking into the source code, we discovered very quickly that there were additional vulnerabilities associated with Log4j.
So there was even patching done after the 14th on December the 17th. Hopefully, this solves this particular vulnerability, but it does show how a particular problem may be inside software just waiting for somebody to find it and take advantage of it.