What is the difference between an exploit, vulnerability and attack?

It can often surprise those outside the industry that details on vulnerabilities are published and made available to the general public, but this is generally only done once a patch or fix for the vulnerability in question has been developed and made available. This means that organisations that apply patches in a reasonable timescale are at minimal risk since they become aware of a vulnerability at the same time as “hackers”, and yet their task (applying a patch) is much more straightforward than an adversary’s task of determining how to exploit the vulnerability and finding a vulnerable system to perform the exploit on.

The industry therefore uses the terms vulnerability to describe the software or hardware weakness that has been discovered, exploit to describe any code that is written to attempt to leverage the weakness in order to gain unauthorised access or undermine a system’s information security guarantees of confidentiality, integrity or availability – and finally attack to describe one or more executions of the exploit code by hackers against one or more systems that display the vulnerability in question.

What is a Zero Day Vulnerability?

A “zero day” is a loose term for a recently discovered vulnerability and often associated exploit that overturns the above model, i.e. where a vulnerability has been uncovered but rather than being reported to the vendor is being actively exploited (or attempting to be exploited) by malicious parties – before a patch is released and/or implemented – and often before a vendor or its customers are even aware that the vulnerability in question exists. Zero day attackers may leverage this window of time after the vulnerability has been uncovered but before a solution or preventative measures exist or the vendor is even aware of the vulnerability in question. These threats are incredibly dangerous because often only the attacker is aware of their existence, meaning that no action is being taken to prevent their exploit. Since it is impossible to “prove a negative”, no organisation can ever be completely sure that a zero day vulnerability isn’t in fact already present on one or more of their systems and perhaps even being actively exploited.

Zero days may exist in single systems or organisations (as the result of flaws within custom, proprietary or otherwise unique in-house systems, services or code) or else be present in a potentially massive number of installed instances of popular or widely distributed software (such as Apache) or even hardware.

What is the typical timeline of a zero day?

Typically, a zero day will follow a timeline similar to the below:

1. A vulnerability in a system, software or service is found by an individual;
2. That individual does not disclose the details of the vulnerability to the vendor in a responsible manner via the CVE programme but rather chooses to keep the knowledge of the vulnerability private;
3. Knowledge of the vulnerability is then used by either the person discovering it or a partner or contact to develop “exploit code” that is able to leverage the vulnerability;
4. (Optionally, the exploit may be sold on the dark web, black market, or to a more legitimate “exploit acquisition platform”, or else knowledge retained by its discoverer only); and
5. The exploit is then used to perform one or more attacks on vulnerable systems. Since the effect of the exploit may not be instantly recognisable or detectable, an attacker will make a decision as to whether to attempt to maximise their short-term benefit from the exploit (by performing a ransomware attack or similar for immediate financial gain) or may choose to adopt a longer-term view and “grow” the foothold they have established in a target system or organisation, in a spreading presence that is known as an APT or “Advanced Persistent Threat”.

These exploits are considered “zero day” before and on the day that the vendor is made aware of the exploit’s existence, with “zero” referring to the number of days since the vendor discovered the vulnerability. “Day zero” is the day the vendor learns of the vulnerability and begins working on a fix.

An Example of a Zero Day Exploit

A famous example of a zero day exploit is Stuxnet. It is not strictly typical of a zero day but the details are relatively sensational and the potential consequences very serious, so it received massive coverage in the press.

Stuxnet was used to break into Iran’s uranium enrichment centrifuges in 2006 and exhibited all the hallmarks of an APT, being used to spread and gain privileged access on system after system. Many experts believe that the National Security Agency (NSA) created the zero day exploit. Stuxnet infected a very specific industrial control system and sped up or slowed down the centrifuges to the point where they destroyed themselves. During this process Iranian monitoring systems made it appear that systems were operating normally.

Stuxnet was unintentionally released in the wild when one of the engineers at an infected facility connected his work laptop to his home network. Over 15 Iranian facilities were attacked and infiltrated by the Stuxnet worm, which caused substantial damage to Iran’s nuclear program.

How can you protect against zero days?

It is extremely difficult to entirely prevent zero days from affecting a given organisation because by definition the nature of the vulnerability is not known – there are no public reports providing details of its existence, let alone details of its operation, so “blue teams” tasked with protecting an organisation are not equipped with either an easy means of detection (not knowing what the vulnerability looks like or even if it exists) nor a means of prevention – the normal advice to apply all patches in a timely manner does not help since the vendor is unaware of the vulnerability and no patch has been written.

Whilst this may seem like a council of despair, there are nevertheless measures that all organisations can take to prevent, detect or correct zero days should they be present. We will look at each of these control areas – preventative, detective, and corrective – in turn:

What preventative measures can be taken against zero days?

Preventative measures are those measures or “controls” that can be taken or implemented in order to reduce either the likelihood of an attempted attack being successfully exploited, or else reduce the impact of an attack should an exploit take place. Many of these preventative measures constitute general “best practice” guidance, as well as specifically aiding in preventing zero day exploits being successfully leveraged against a given organisation’s systems.

• Minimize the “attack surface” of your organisation by ensuring that you harden systems by reducing their network footprint, limiting available and running ports services and software to only those that are essential;
• Expose individual services only to systems and users that have a business need to access them, using sensible firewalling;
• Screen against classes of vulnerabilities by making use of a Web Application Firewall (WAF) for any web services;
• Restrict the ability of an attacker who does compromise a system to “pivot” his attack and gain footholds on other systems via lateral movement with robust segmentation and a locked down network;
• Where possible under budget and scale constraints, consider using multiple layers of devices such as firewalls from different vendors, such that even if one is vulnerable the next “layer” may not be;
• As an extension of the above, consider the principle of “defence in depth” in any system architecture decisions, making sure that you are not relying on any one preventative measure as a total panacea against threats, but are operating layers of defences.

How do I detect a zero day vulnerability?

Since it is not always possible to prevent the presence of a vulnerability, or of an exploit of that vulnerability, it is vitally important that detective measures are put in place to spot when this has occurred. This has several benefits including making clear the extent of an attack and allowing identification of any compromised systems to inform any decisions taken, as well as reducing the “attack window” during which an attacker may exploit a vulnerability on your system before being shut out, and finally enabling effective corrective measures (listed in the next section) from being implements. Potential detective measures that can be taken include:

• Implementing robust logging and auditing and making sure that logs are both stored off-system in an immutable (unmodifiable) manner in order to prevent an attacker hiding traces of their attack, and also ensuring that logs are reviewed and monitored and alerts in place to detect given event types;
• Implementing intrusion-detection systems, both at the host level (“HIDS”) and the network layer “(NIDS”). These can use multiple approaches including statistics-based detection, or behaviour-based detection to spot unusual patterns in system or network behaviour, which may indicate that they have either been compromised or that an attempted exploit is in progress.
• Perform regular vulnerability scanning using a web application scanner such as AppCheck that scans from “first principles” and is able to discover vulnerabilities even in in-house and custom code and where no prior knowledge of such a vulnerability exists. This allows you to “beat the hacker to the punch”.

What corrective measures can be taken for zero days?

If the worst happens and it has not been possible to prevent an exploit then corrective measures must be taken. This is a complex area requiring very specialist knowledge and it is normal to lean on specialists and consultants for assistance, but measures taken can include:

• Performing an analysis and triage to prevent further spread in a “breach containment” approach;
• Ensuring access removal (shutting the attacker out of the system or network), often initially while the vulnerability is poorly understood by simply removing that system’s network connectivity entirely;
• Performing robust forensics investigation to ensure that the vulnerability has been understood; and
• Remediating the underlying flaw or weakness, and often restoring to a prior point using systems of backups and disaster recovery plans.

How can AppCheck Help with zero days?

AppCheck helps you with providing assurance in your entire organisation’s security footprint. AppCheck performs comprehensive checks for a massive range of web application vulnerabilities from first principles to detect vulnerabilities in in-house application code even where no prior knowledge of them exists. AppCheck does not simply report on known vulnerabilities published in CVEs, but attempts to discover novel and unpublished vulnerabilities in systems using a “fuzzing” approach.

The AppCheck Vulnerability Analysis Engine provides detailed rationale behind each finding including a custom narrative to explain the detection methodology, verbose technical detail and proof of concept evidence through safe exploitation.

About AppCheck

AppCheck is a software security vendor based in the UK, offering a leading security scanning platform that automates the discovery of security flaws within organisations websites, applications, network, and cloud infrastructure. AppCheck are authorized by the Common Vulnerabilities and Exposures (CVE) Program as a CVE Numbering Authority (CNA).

Additional Information

As always, if you require any more information on this topic or want to see what unexpected vulnerabilities AppCheck can pick up in your website and applications then please get in contact with us: info@localhost