On December 9, 2021, a zero-day vulnerability was discovered in a Java logging library, log4j which, if exploited, results in Remote Code Execution (RCE) affecting nearly all versions of Apache log4j [1]. This zero-day is just one of the nearly 100 identified in 2021, an approximate twofold increase from zero-days discovered in 2020. In this article we’re going to break down what a zero-day vulnerability is, as well as why they’re dangerous and how you can discover them.

Zero-days, Explained.

Zero-day vulnerabilities are vulnerabilities that the software vendor has known about for zero days [2]. This means no patches or fixes have been publicly released and the vulnerabilities can be exploited. In 2019, an estimated 80% of all data breaches were the result of an exploited zero-day vulnerability [3]. It should be no surprise that these vulnerabilities are valuable to not only software vendors, but to attackers as well. In fact, there is a market for these vulnerabilities.

The zero-day market consists of legitimate and malicious researchers. The 3 primary sub-markets include: White Hat markets, Black Hat markets, and Grey Hat markets.

•  White Hat markets are a result of bug bounty programs wherein security organizations, software vendors, and governments pay money for the discovery of a previously unknown vulnerability.
• Black Hat markets consist of unethical researchers and hackers who find and sell these vulnerabilities, where the buyers are typically threat actors who aim to exploit the vulnerabilities.
• Grey Hat markets are comprised of brokers who buy and sell zero-day vulnerabilities to individuals whose identities are anonymous. There is no way of knowing whether the buyer/seller is a legitimate researcher or not [4]

It’s apparent that there is a market for the discovery of new zero-day vulnerabilities. Since zero-day vulnerabilities are unknown, attackers can leverage these vulnerabilities to conduct attacks on vulnerable systems. These exploits are significantly more likely to result in success in comparison to known vulnerabilities, making zero-days inherently dangerous. But how are zero-days found?

Bug Hunting Strategies

Bug hunting refers to the individuals who aim to detect these types of security vulnerabilities [5]. These individuals utilize different techniques such as fuzzing, reverse engineering, and code review to discover these “bugs”.

Fuzzing is an automated way in which an individual can discover hackable software bugs. Fuzzers can be either mutation fuzzers or generation fuzzers. Mutation fuzzers have no intelligence relating to the program that is being fuzzed, whereas generation fuzzers are programmed with knowledge relating to the program that is being fuzzed, such as knowledge of the input formats [6]. These fuzzers randomly feed different permutations of data into a target program until one of the permutations reveals a bug.

While fuzzing was initially utilized by lone hackers, it has become a common security audit that large companies perform on their own code. As such, large companies such as Peach Fuzzer and Codenomicon have constructed businesses geared towards fuzzing [7]. The benefits of fuzzing include being low cost and easily scalable, making it a great technique for beginners as it doesn’t require a lot of knowledge about the codebase. As evidenced by Heartbleed and Shellshock, fuzzing techniques can find extremely bad vulnerabilities [8]. In fact, in response to Log4Shell, the remotely exploitable flaw in log4j, Google developed a tool called OSS-Fuzz that utilizes Code Intelligence’s Jazzer which was modified to identify log4j vulnerabilities  [9].

This brings us to code review. Code review is a type of static analysis of an application that is conducted without the execution of the program and is critical to identifying potentially harmful bugs. Binary analysis and reverse engineering are also in this realm of static analysis.  Most security issues result from insecure coding practices such as input validation errors, missing access, controls, and weak regex checks [10]. Code review can either be done manually or automated and aims to spot these bugs prior to software being released into production [11]. However, manual code review is expensive and time consuming since many applications have millions of lines of code associated with them, and while automated code review has higher up-front costs, it identifies the low-hanging fruit automatically [12].

 Moving Forward

The fallout of Log4Shell vulnerabilities as organizations such as Check Point research identified nearly 2 million log4j exploit attempts in the immediate aftermath of disclosure, including attacks from threat actors in Iran, China, North Korea, and Turkey [13]. A multi-faceted approach is required to identify bugs and employ a coordinated vulnerability disclosure in which bug hunters and researchers disclose these vulnerabilities in a manner that allows vendors to diagnose, test, and develop updates, workarounds, or additional corrective measures prior to the release of information to the public. It’s now 2023, and it’s apparent that zero-day vulnerabilities are here to stay. Are you prepared for zero day?

By: Lindsey Wizinsky

[1]https://www.lunasec.io/docs/blog/log4j-zero-day/
[2]https://books.google.com/bookshl=en&lr=&id=N62PDgAAQBAJ&oi=fnd&pg=PP1&dq=zero+day+vulnerability+market&ots=jGvA3Atacw&sig=xRJinpROycFxEtxp_fZMIWNB1do#v=onepage&q=zero%20day%20vulnerability%20market&f=false
[3]https://www.thesslstore.com/blog/the-ultimate-guide-to-zero-day-attacks-exploits/
[4]https://www.cynet.com/network-attacks/zero-day-vulnerabilities-exploits-and-attacks-a-complete-glossary/#anatomy-of-a-zero-day-attack
[5]https://www.youtube.com/watch?v=oeEEZWI3cfM
[6]https://www.f-secure.com/us-en/consulting/our-thinking/15-minute-guide-to-fuzzing
[7]https://resources.infosecinstitute.com/topic/fuzzing-mutation-vs-generation/
[8]https://forallsecure.com/blog/the-hacker-mind-shellshock
[9]https://www.zdnet.com/article/google-unleashes-security-fuzzer-on-log4shell-bug-in-open-source-software/
[10]https://labs.f-secure.com/assets/BlogFiles/mwri-bug-hunting-with-static-code-analysis-bsides-2016.pdf
[11]https://owasp.org/www-pdf-archive/OWASP_Code_Review_Guide_v2.pdf
[12]https://labs.f-secure.com/assets/BlogFiles/mwri-bug-hunting-with-static-code-analysis-bsides-2016.pdf
[13]https://threatpost.com/log4j-attacks-state-actors-worm/177088/