A zero-day attack (commonly referred to as "O-day") is defined as "an attack that occurs when an attacker discovers and exploits a previously unknown flaw, providing 'zero days' of warning" (Ciampa, 2007). Zero-day attacks have been prominently featured in the media and have even infiltrated Hollywood. In the 2003 blockbuster film, "Matrix: Reloaded," a main character, Trinity, shut down an electrical grid comprised of 27 city blocks by releasing a (2001-era) secure shell zero-day attack, which targeted an "exploitable vulnerability in the CRC32 compensation attack detector" (Lyon, 2009). This scene has since been applauded by many Black Hat and DEFCON conference speakers since its release and accurately depicted the danger zero-day exploits pose to our infrastructure.
The Cost of Exploits
In reality, there are substantial costs associated with zero-day code, not only in its development, but also in the damage it can cause. Computer Economics assessed that the Windows meta-file vulnerability cost $3.75 billion world-wide between 2004 and 2005 ("Microsoft WMF," 2006). This "infamous Windows Meta-File vulnerability" was reportedly purchased by malicious actors from its developer for approximately $4,000 (Higgins, 2006). In 2006, TrendMicro reported "an online criminal" offered to sell a zero-day exploit affecting the Microsoft Vista operating system for $50,000 in an online hacking forum (McMillan, 2006). Zero-day code not only negatively affects the commercial sector, its development has netted a profit for free-lanced code writers and is a lucrative market for the hundreds of security software companies. The trading of these exploits have become a cash cow for both criminals and the software security industry. Sadly, the internet has facilitated the trading of zero-day code, as well as made access to actual zero-day exploits exceptionally easy for those with malicious intent.
Security and Profitability
How has the corporate world responded to the growing number of malicious code developers and black market vendors? The software security sector has hired thousands of code developers, both employees and free-lanced researchers, and now sells zero-day exploits wholesale. Code researchers have found an abundance of opportunities to earn a significant annual income. A well-known and respected software security company, Tenable Network Security, recently posted a vacancy for a vulnerability research engineer requiring two-to-four years experience and an expected annual salary between $60 to $90 thousand dollars depending on the applicant's prior experience ("Careers," 2010). Conversely, Ivan Arce, Chief Technical Officer and co-founder of Core Security, believes that it is "more cost-effective" for a software security company to pay "$10,000 apiece" for vulnerability code than paying a six-figure salary to a software researcher and expecting him or her to produce "ten big-time bugs" a year (Higgins, 2006). Other competitors are following suit. Not only will the vulnerability researching company iDefense pay $15 thousand dollars for "reliable proof-of-concept exploit code," the company holds an "Annual Vulnerability Challenge," which offers $90 thousand dollars in cash prizes for the "most significant contributed vulnerabilities (zero-day exploits) of the year" ("Vulnerability," 2010). In 2005, TippingPoint supplemented its DVLabs' research wing by establishing the Zero Day Initiative program, which pays free-lance researchers on a case-by-case basis for discovered vulnerabilities, as well as offers notoriety and solid resume padding for the researcher. The Zero Day Initiative currently has 1,179 external researchers responsible for creating over two thousand cases with and average verification time of 19 days after initial submission ("Why Did We," 2009). The question is if these financial incentives are enough to influence unscrupulous zero-day code writers to legitimately submit their proof-of-concept code to these software security companies? Apparently, not.
Availability of Malicious Code
In 2008, the Federal Bureau of Investigation arrested 60 individuals world-wide (in conjunction with its foreign counterparts) and effectively closed a 2,500 member online hacking forum that sold and traded stolen identity information and zero-day exploits since 2006 (Mills, 2009). Unfortunately, these zero-day exploits are relatively available to anyone without having to access an illegal online hacker den. The Metasploit Project offers a software framework that provides its user with hundreds of automated "working exploits" that result in remote access to a targeted system. Metasploit's mission statement is to "provide information on exploit techniques and to create a functional knowledge base for exploit techniques" ("Metasploit," 2010). Its popularity cannot be doubted as a Google web search for the keyword "metasploit" yielded 507,000 results and a YouTube search netted 462 demonstration and how-to videos. The Metasploit framework allowed for the recreation of the infamous Aurora Internet Explorer vulnerability within a month of its release (approximately December 30, 2009). This exploit module was created 24 hours after the Aurora code was publicly submitted to the Wepawet page. Consequently, seven days after the Metasploit module's release, only 26.8% of the Anti-Virus vendors (to include Kaspersky, McAfee, Microsoft, and TrendMicro) had developed protection from the Aurora exploit (HDM, 2010 and "Update .Exe Text," 2010). The Metasploit framework allows anyone with malicious intent and basic coding knowledge to develop an exploit hours after its initial public release. Mischievous teenagers with internet access and unskilled crackers are now able to compromise and obtain remote administration control of any system vulnerable to the latest zero-day exploit, thanks largely in part to the immediate re-creation and posting of ready-to-go Metasploit modules. However, zero-day exploits do have a shelf life and it may prove to be too tempting for malicious code developers to release a zero-day attack prior to the release of a software patch or update; then, let the code become obsolete. As in combat, a weapon not used is a useless weapon.
Conclusion
The research, development, and ultimate usage of zero-day exploits cause many ethical dilemmas for all involved. A legitimate "white hat" code developer must ask himself or herself whether or not to notify the affected software vendor of a discovered vulnerability (pro bono) or sell the proof-of-concept code to a third-party security vendor (for a profit). Similarly, a malicious "black hat" code developer must now ask whether or not to legitimately sell the exploit to a vendor for a marginal profit or risk possible arrest by marketing this zero-day code to unscrupulous buyers (for a larger profit) in an illegal hacker forum. A penetration testing company may have to decide whether or not they should release a "purchased" zero-day exploit against a client's network to ensure that "they found a vulnerability" in order to keep a client's business; although, that same vulnerability has not been previously released in the "wild." Finally, a government with a cyber network attack capability may purchase zero-day exploits in preparation for a "cyber war." The ultimate question is if a zero-day exploit has the ability to affect emergency services and destroy/degrade (either telecommunications or electrical) infrastructure, should it be classified as a weapon of mass destruction and subject to international treaties?
References
