Zero day, 0day, ohday, oh my!

Hackers have a few things in their favor when it comes to getting into your network and stealing data.  One of those things is the elusive zero day.   
When it comes to hacking, a zero day is an “exploitation against a publicly unknown vulnerability”. But hackers don’t need a zero day.  They only need a “zero to me day”.  What does that even mean? 

Before we begin

Before exploring anything else here, let’s set the record.  Regardless of a formal definition of zero day, the responsibility of the defense team is to protect the confidentiality, integrity, and availability of data and systems. The responsibility of the attack team is to do just the opposite — to effect the disclosure (opposite of Confidentiality), alteration (opposite of integrity), and destruction (opposite of Availability) of data and systems.

In some ways, defining zero day is going to feel like a lesson in academics.  You might ask whether it matters what you call it once you’ve been exploited. The answer is, maybe.  It might matter with regard to penalties.  It will be a bad day if the hack originated due to a defect in the patch process (a “zero to me” situation).  Either way it is going to be a bad day though.

A bad day for all

Computer Security in 2014

Twenty-fourteen was yet another banner year in Computer Security.  The industry met with the Heartbleed SSL vulnerability, Point of Sale equipment attacks against Target and Home Depot, and the Shellshock vulnerability in a piece of software that has been around for more than twenty years.

If you happen to not remember any of those, well, you must be happily sailing the islands.  Good for you!

But for the rest of us in technology, and particularly for those in computer security, we’ve had quite a year.

One of the outgrowths of these vulnerabilities being exploited has been that it seems “everyone” has heard the term “zero day”.  But what is a zero day?

Exploits vs Vulnerabilities

As we define 0day, let’s explore a couple of supporting ideas.  Let’s start with Exploits and Vulnerabilities.

Vulnerabilities

In security, a vulnerability is a weakness that allows a threat to compromise the integrity of a resource.  NIST SP 800-30, “Risk Management Guide for Information Technology Systems”, defines vulnerability as  flaw or weakness in system security procedures, design, implementation, or internal controls that could be exercised (accidentally triggered or intentionally exploited) and result in a security breach or a violation of the system’s security policy.

Exploits

That said, an exploit is an attack on a resource that takes advantage of a vulnerability.  Think of it this way.  A vulnerability is an attack surface.  But it takes a special kind of vulnerability to be exploitable.  There is no exploit unless a vulnerability exists, but not all vulnerabilities are exploitable.

Real life example

Let’s create a non electronic based example to help understand the ideas.  Let’s say you keep paper copies of all credit card transactions in a file cabinet.  A thief only needs to steal your safe in order to steal all the PCI data.  The vulnerability is that all PCI data is in a file cabinet, so the exploit would be that someone walks in and takes your file cabinet.

What “compensating controls” have you emplaced to control the vulnerabilities?  You’ve placed locks on the cabinet and your front door, and you’ve hired an armed security guard and guard dog to police your premises.  Because of these safeguards, the original vulnerability is moot.  

The new vulnerability is several steps deep, called defense in depth.  Now the adversary has to disable the dog, disarm the guard, pick the lock on the front door, and pick the lock on the cabinet.  You still have vulnerabilities, but the combined effort of all those vulnerabilities must be exploitable at the same time in order for an exploit to occur.

The elusive Zero Day

Now that we understand Vulnerability chains and Exploitability, let’s come to an understanding of what a zero day is, and what a zero day is not.  If you’ve seen literature about a security vulnerability, that vulnerability is likely not a zero day (I’ll get to that “likely” word in a moment).  To be comprehensive in this discussion, the systems may remain vulnerable to attack after a vulnerability is patched, but the vulnerability is not a result of the zero day, the vulnerability is a result of an unpatched system.

In general, hackers don’t “discover” 0days.  They buy them.  And zero days are expensive to buy.  What happens is a hacker or hacker group will buy the zero day exploit, then use the zero day against any number of victims.  But a zero day isn’t strictly required to get onto your computer.  A hacker only has to find a vulnerability that you haven’t yet patched. Hence the idea of a “zero to me day”.

Buying your way in…

“Wait, what?”,  you might be asking.  “How is a zero day any different than an unpatched system vulnerability?”  Okay, let’s try this.  A zero day is a vulnerability in which the protectors have had no days to create a patch for the system.  If the protectors are aware of the vulnerability, then it is no longer a zero day.

That said, a vulnerability that has been presented to the protectors but in which a patch has not been created or has not been deployed still results in a vulnerability, but those vulnerabilities are no longer zero day.  But really, zero day is even a little more elusive than this.  Let’s be honest.  Being hit by an exploit will always feel like a zero day, because you likely did not take the attack vector seriously.

Timeline of vulnerabilities

Protecting systems often relies on patches.  So what is a reasonable timeframe between presenting a vulnerability to the vendor and a patch?  Some reports identify that it takes vendors more than ten months to develop a patch.  Google has put the brakes on this long forecasting though.  Google’s Project Zero gives the vendor 90 days before publicly disclosing the vulnerability to the world.

Exploiting the SDLC

Exploiting systems truly relies on exploiting the Systems Development Lifecycle (or SDLC).  The SDLC starts with the first thoughts of a system, and continues through retirement or disposal of the system.  Wikipedia has a great article on SDLC, and we’ll visit and organize a few steps that are particularly important when discussing exploitation:

1. (development) The development team creates software
2. (initial deployment) The software is distributed to end user teams
3. (installation) The software is installed by end user teams
4. (feedback) The development team is made aware of requested upgrades and security issues.
5. (patch development) The development team creates patches
6. (patch deployment) Patches are distributed to end users
7. (patch installation) End user teams install the patches
8. (repeat) Repeat to Feedback loop
9. (end of life) At some point the product will reach End of Life and no longer be maintained.

The best time to hack

Ripe times for vulnerability discovery exist at the following points, and the vulnerability discovery teams will hand off those vulnerabilities to exploit developers:

Between Initial Deployment and Installation

Hackers will get the software and try to do daring things to it, sometimes even before the first end user team has installed it.  Any vulnerabilities discovered here are clearly zero day vulnerabilities.

Between Feedback and Patch Development

Hackers will look at public blogs and websites where bug track issues and core dumps are reported, to determine if any of the logs identify vulnerabilities.  Bugs that translate into vulnerabilities are not really zero days.  Instead, these vulnerabilities are known vulnerabilities that are not yet addressed.  But this definition could be a matter of semantics, and to argue the issue is not worthwhile.  From the point of view of an attacker, they are vulnerabilities.  From the point of view of the victim, they are vulnerabilities.

Between Patch Deployment and Patch Installation.

Hackers will look at patch deployments — especially security patches — to determine what vulnerability existed in the prior version.  This point in time is one of the most prolific in the days of a vulnerability researcher.   These are not zero days.  These are known vulnerabilities, and the systems remain vulnerable because the end user is irresponsible and hasn’t deployed the patches.  The attack surface is a result of unpatched systems, solely the responsibility of the end user.
For an example, Microsoft’s Patch Tuesday invariably results in Exploit Wednesday.  Why?  Because it takes awhile for all users to update their systems.   Oftentimes business users will refrain from patching immediately because of incompatibility with other products.

At and after End of Life

Hackers will take advantage of end of life product in that zero days last forever once the development team has left the update cycle.  These vulnerabilities are sometimes referred to as zero days forever.

Case in point, when Microsoft announced the end of updates for Windows XP, they also described how attackers will lay waste to users who remain on XP.

Zero day… What it means to you

So here’s the short of it all, and let’s revisit our previous definition.  A pure zero day is that moment in time between (a) when an attacker knows about the vulnerability and (b) the defense team does not know about the vulnerability.  In other words only attackers know about the exploit.  The exploit team is using it, and the defense team doesn’t know about it.

Computer Network Attack

To better defend your network, it is a good idea to understand how the adversary is going to attack your network.  From the perspective of the Computer Network Attack & Exploitation (CNA/CNE) teams, the job is to find vulnerabilities and build exploit paths.  How is this done?  CNA teams will:

• Become aware of anomalies through publicly available crash dumps, bug reports, and forums where users of any particular piece of software discuss issues.  If  a system crashes or produces otherwise unexpected results, there is something wrong — and that something may turn out to be a real vulnerability, and in turn that vulnerability may turn out to be exploitable.
• Reverse engineer patch code and compare it to the unpatched versions, especially anything identified by the vendor as “security patch”.  Realize if you find a vulnerability, you are in a race to attack the unpatched systems in the wild before the end user patches those systems.
• Do what you can to create anomalies.  Look at the touch points on the system, be that a network, a keyboard, or some other input device.  Use tools such as Metasploit and fuzzers to force the system to do things it wasn’t originally designed to do.
• Be realistic.  For every million well crafted test cases, be happy with a thousand anomalies.  With a thousand anomalies, be happy with a couple of repeatable vulnerabilities.

Computer Network Defense

If you are on the Computer Network Defense (CND) team, your job is to protect the network from known and unknown (0day) attack.  How?  Keep abreast of the product user community blogs to see what other people are reporting, and keep in touch with your own users to determine if they witness anomalies on the platform.  What should you do?

• Expect an anomaly is a vulnerability.  There may not be an exploit path, but an anomaly is where every vulnerability is birthed.
• Do what you can to isolate systems in general, and certainly any oddly acting systems.  Network isolation is a great place to start.
• Patch early, and patch often.  Realize that when a patch becomes available, the CNA & CNE teams are reversing those patches to discover vulnerabilities and explore exploitation paths.
• Be prepared with a patch plan.  If a patch breaks one of your existing applications, be prepared to isolate the system instead of leaving an unpatched system in your universe.
• For particularly difficult deployments where existing applications are known to not work with the most updated patches, use Virtual Machines to isolate those applications.

Conclusions

Remember, all of this is a race against time.  Eventually (and yes, it may be years), every vulnerability will become publicly available and known, and once known the vulnerability will likely be eradicated through a patch or the exploit path will be nullified through some compensating control such as isolation.

And as always, regardless of what side of the fence you are on, let’s be careful out there.

Reference documents

1. NIST SP 800-30r1,” Guide for Conducting Risk Assessments”, https://nvlpubs.nist.gov/nistpubs/legacy/sp/nistspecialpublication800-30r1.pdf
2. Heartbleed SSL vulnerability,  https://en.wikipedia.org/wiki/Heartbleed
3. US-CERT Alert on Point of Sale exploitation,  https://www.us-cert.gov/ncas/alerts/TA14-002A
4. Shellshock vulnerability,  https://en.wikipedia.org/wiki/Shellshock_(software_bug)
5. Google’s Project Zero, https://en.wikipedia.org/wiki/Project_Zero_(Google)
6. Microsoft Patch Tuesday, https://en.wikipedia.org/wiki/Patch_Tuesday
7. Defines Zero Day Vulnerability, “A zero day vulnerability refers to a hole in software that is unknown to the vendor”,  http://www.pctools.com/security-news/zero-day-vulnerability/
8. Zero Day Vulnerability, “A zero-day vulnerability is previously unknown vulnerability in a software”,  http://www.thewindowsclub.com/what-is-vulnerability-in-computer-security