A zero-day (or zero-hour or day zero) attack or threat is an attack that exploits a previously unknown vulnerability in a computer application, meaning that the attack occurs on "day zero" of awareness of the vulnerability.[1] This means that the developers have had zero days to address and patch the vulnerability. Zero-day exploits (actual software that uses a security hole to carry out an attack) are used or shared by attackers before the developer of the target software knows about the vulnerability.
Attack vectors
Malware writers are able to exploit zero-day vulnerabilities through several different attack vectors. Web browsers are a particular target because of their widespread distribution and usage. Attackers can also send e-mail attachments, which exploit vulnerabilities in the application opening the attachment.[2] Exploits that take advantage of common file types are listed in databases like US-CERT. Malware can be engineered to take advantage of these file type exploits to compromise attacked systems or steal confidential data such as banking passwords and personal identity information.[3]
Vulnerability window
Zero-day attacks occur during the vulnerability window that exists in the time between when a vulnerability is first exploited and when software developers start to develop and publish a counter to that threat.
For worms, viruses, Trojans and other zero-day malware attacks, the vulnerability window follows this time line:
- The developer creates software containing an unknown vulnerability.
- The attacker finds the vulnerability before the developer does (or while the developer is aware of but has neglected or been unable to fix it).
- The attacker writes an exploit while the vulnerability is either not known to the developer or known but still not closed (e.g., due to an internal assessment of the threat's potential damage costs being lower than the costs of developing a fix), usually also using and distributing it.
- The developer or the public becomes aware of the exploited vulnerability and the developer is forced to start working on a fix, if still not working on one.
- The developer releases the fix.
Conceptually, there is one more event in the zero-day attack time line, which is the users applying the fix, effectively closing the vulnerability window, but that can vary, as some users may simply stop using the affected software as soon as the problem surfaces, while others may never know of it at all, never fixing it and therefore keep the vulnerability window open. Thus, the vulnerability window's length is usually just measured until the developer releases the fix.
Measuring the length of the vulnerability window can be difficult, as attackers do not announce when the vulnerability was first discovered. Developers may not want to distribute data for commercial or security reasons. Developers also may not know if the vulnerability is being exploited when they fix it, and so may not record the vulnerability as a zero-day attack. By one estimate, "hackers exploit security vulnerabilities in software for 10 months on average before details of the holes surface in public," i.e., the average vulnerability window of a zero-day exploit is about 10 months.[4] However, it can be easily shown that this window can be several years long. For example, in 2008, Microsoft confirmed a vulnerability in Internet Explorer, which affected some versions that were released in 2001.[5] The date the vulnerability was first found by an attacker is not known; however, the vulnerability window in this case could have been up to 7 years. Some windows may never be closed, for example, if they are hardwired in a device, requiring its replacement or the installation of additional hardware to protect it from exploitation.
Discovery
A special type of vulnerability management process focuses on finding and eliminating zero-day weaknesses. This unknown vulnerability management lifecycle is a security and quality assurance process that aims to ensure the security and robustness of both in-house and third party software products by finding and fixing unknown (zero-day) vulnerabilities. The unknown vulnerability management process consists of four phases: analyze, test, report and mitigate.[6]
- Analyze: this phase focuses on attack surface analysis
- Test: this phase focuses on fuzz testing the identified attack vectors
- Report: this phase focuses on reporting of the found issues to developers
- Mitigate: this phase looks at protective measures explained below
Protection
Zero-day protection is the ability to provide protection against zero-day exploits. Zero-day attacks can also remain undetected after they are launched.[7]
Many techniques exist to limit the effectiveness of zero-day memory corruption vulnerabilities, such as buffer overflows.[citation needed] These protection mechanisms exist in contemporary operating systems such as Microsoft Windows 8, Windows 7, Windows Vista, Apple's Mac OS X, recent Oracle Solaris, Linux and possibly other Unix and Unix-like environments; Microsoft Windows XP Service Pack 2 includes limited protection against generic memory corruption vulnerabilities.[8] Desktop and server protection software also exists to mitigate zero day buffer overflow vulnerabilities.[citation needed]
"Multiple layers" provides service-agnostic protection and is the first line of defense should an exploit in any one layer be discovered. An example of this for a particular service is implementing access control lists in the service itself, restricting network access to it via local server firewalling (i.e., IP tables), and then protecting the entire network with a hardware firewall. All three layers provide redundant protection in case a compromise in any one of them occurs.
The use of port knocking or single packet authorization daemons may provide effective protection against zero-day exploits in network services. However these techniques are not suitable for environments with a large number of users.
Whitelisting effectively protects against zero day threats. Whitelisting will only allow known good applications to access a system and so any new or unknown exploits are not allowed access. Although whitelisting is effective against zero-day attacks, an application "known" to be good can in fact have vulnerabilities that were missed in testing. To bolster its protection capability, it is often combined with other methods of protection such as host-based intrusion-prevention system or a blacklist of virus definitions, and it can sometimes be quite restrictive to the user.
Engineers and vendors such as Gama-Sec in Israel and DataClone Labs in Reno, Nevada are attempting to provide support with the Zeroday Project,[9] which purports to provide information on upcoming attacks and provide support to vulnerable systems.
Keeping the computer’s software up-to-date is very important as well and it does help.
Users need to be careful when clicking on links or opening email attachments with images or PDF files, even if the sender is someone they know. This is how many cyber criminals deceive users, by pretending they are something they are not and gaining the user’s trust, as well as having a virus or other malware email copies of itself to the address lists of infected victims.
Utilize sites with Secure Socket Layer (SSL), which secures the information being passed between the user and the visited site.
Ethics
Differing views surround the collection and use of zero-day vulnerability information. Many computer security vendors perform research on zero-day vulnerabilities in order to better understand the nature of vulnerabilities and their exploitation by individuals, computer worms and viruses. Alternatively, some vendors purchase vulnerabilities to augment their research capacity. An example of such a program is TippingPoint's Zero Day Initiative.[10] While selling and buying these vulnerabilities is not technically illegal in most parts of the world, there is much controversy over the method of disclosure. A recent German decision to include Article 6 of the Convention on Cybercrime and the EU Framework Decision on Attacks against Information Systems may make selling or even manufacturing vulnerabilities illegal.
Most formal efforts follow some form of RFPolicy disclosure guidelines or the more recent OIS Guidelines for Security Vulnerability Reporting and Response.[11] In general these rules forbid the public disclosure of vulnerabilities without notification to the developer and adequate time to produce a patch.
See also
References
- Messmer, Ellen, Is Desktop Antivirus Dead?, PC World, April 6, 2007.
- Naraine, Ryan, Anti-Virus Is Dead, D-E-A-D, Dead!, eWeek, December 1, 2006.
- Mediati, Nick, Do You Speak Securitese? Five Security Terms You Should Know, PC World, December 2, 2011.
External links
