Originally published in 2016
“A zero-day (also known as zero-hour or 0-day) vulnerability is a previously undisclosed computer-software vulnerability that hackers can exploit to adversely affect computer programs, data, additional computers or a network. It is known as a “zero-day” because once the flaw becomes known, the software’s author has zero days in which to plan and advise any mitigation against its exploitation (for example, by advising workarounds or by issuing patches)”Thank you, Wikipedia, but what does that break down to. I find there are a ton of generalizations when it comes to this topic, its cool to say “zero-day” when dropping a vulnerability but is it accurate? When you find a system in use by the end user that has say… a port open and a service running that shouldn’t be. Should that really be called a zero day? My feeling is no. Recently at the Energy Sec Hawaii Security Sessions, I presented what I feel are degrees of “hacking” this was meant to be a lightweight way of understanding what level of interaction the researcher might need to have.
The labels were more of a gimme, logical placements for what we already know as a security issue with any end point. Penetration can simply mean getting access in a lot of cases, not really a zero day as most customers might use this weakness to service a system. The implementation might require a bit more thinking, diving into the processes or procedures used to operate the system hmm not really fitting the clear definition. Workarounds and patches are engineering solutions. So that brings us to custom code or Custom Attack well even this has issues. For instance, I was asked to provide code recently that would allow someone to check a true zero-day on their system, the code, for the most part, was reuse from another project that had the same vulnerabilities so did I find a zero day? Well no but one existed. When a developer is using a lot of the same repositories (think Github) and they happen to have a zero day in them, it effects the rest of the developers using them because when the vulnerability becomes publicly known it will be harder to correct on systems already in use. That code I supplied isn’t built into a Nessus scanner or Rapid7 so it requires the attacker to know about the issue in advance and try it out. Or discover it on their own… Aha, this is what a real zero-day is made of. Militarized code is really just suggesting all of the others have been weaponized. None of this speaks to the level of complexity, you can have a genuine anomaly that exists in each of these on most any programmable device and at times, all of these overlap each other. That’s why the degrees are shown as a sphere with layers connecting them. You can compartmentalize your level of engagement when looking for zero days and still be kinda successful in finding what are engineering issues. But I personally would be reluctant to call anything a zero-day unless it has true anomalies at any layer of an ISO model.
