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.
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.
Typically, a zero day will follow a timeline similar to the below:
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.
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.
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:
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.
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:
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:
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.
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).
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: firstname.lastname@example.org
No software to download or install.
Contact us or call us 0113 887 8380