At 2:25 p.m. on Dec. 9, 2021, an infamous tweet (now deleted) linking a zero-day proof-of-concept exploit for the vulnerability that came to be known as Log4Shell on GitHub (also now deleted) set the Internet on fire and sent companies scrambling to mitigate, patch, and then patch some more as further and further proofs of concept (PoCs) appeared on the different iterations of this vulnerability, which was present in pretty much everything that used Log4j.
Known as public disclosure, the act of telling the world something is vulnerable with an accompanying PoC is not new, and happens quite frequently for all sorts of software, from the most esoteric to the mundane. Over time, however, research and experience have consistently shown us that the only benefit to the release of zero-day PoCs is for threat actors, as the disclosures suddenly put companies in an awkward position of having to mitigate without necessarily having anything to mitigate with (i.e., a vendor patch).
How Does Disclosure Usually Work?
There are all kinds of disclosure mechanisms that exist today, whether companies have a vulnerability disclosure program that’s officially sanctioned (think of Google and Microsoft) or those that are run via crowdsourced platforms that are often referred to as bug bounties. Disclosures in these scenarios often go through a specific process and have adequate timelines where the vendor patch is released and given ample time for take-up by the users of the software in question (90 days is the accepted standard here), as well as the PoC being released publicly only with vendor approval (also known as coordinated disclosure). Bug bounty platforms also apply nondisclosure agreements to their security researchers on top of this so that often the PoCs remain sealed, even if the vulnerability has long been fixed.
Having gone through many disclosures myself, both through the common vulnerabilities and exposures (CVE) format or directly through vulnerability disclosure processes, it usually works like this if it goes smoothly:
Returning to the Log4j vulnerability, there was actually a disclosure process already underway as shown by the pull request on GitHub that appeared on Nov. 30. The actual timeline of the disclosure was slightly different, as shown by an email to SearchSecurity:
While the comments in the thread indicate frustration with the speed of the fix, this is par for the course when it comes to fixing vulnerabilities. As everyone points out, the patch was built by volunteers.
Reasons for Releasing Zero-Day PoCs, and Evidence Against
On the surface, there may appear to be legitimate reasons for releasing a zero-day proof of concept. One of the most common is that the vulnerability disclosure process with the vendor has broken down. This can happen for many reasons, including an unresponsive vendor, not viewing the vulnerability as serious enough to fix, taking too long to fix, or some combination. The stance then is to release it for the common good, which evidence has shown is rarely for the good of users of the software.
There are also peripheral reasons that are less convincing for releasing a PoC, namely publicity, especially if you are linked to a security vendor. Nothing gets press coverage faster than a PoC for a common piece of software that everyone uses but has no patch yet, and this is unfortunately a mainstay of a lot of security research today.
The evidence against releasing a PoC is now robust and overwhelming. A study completed by Kenna Security effectively showed that the only benefit to PoC exploits was to the attackers that leveraged them. Even several years ago, a presentation at Black Hat, “Zero Days and Thousands of Nights,” walked through the life cycle of zero days and how they were released and exploited. It also showed that if PoC exploits were not disclosed publicly, they weren’t discovered, on average, for seven years by anyone, threat actors included. Sadly, this was realized a bit too late during the Log4j scramble. While all the initial disclosures were promptly walked back and deleted, even the most recent 2.17.1 disclosure ran into the same trouble, receiving a lot of flak to the point where the researcher issued a public apology for the poor timing of the disclosure.
It’s good to see that attitudes toward public disclosure of PoC exploits has shifted, and the criticism of researchers who decide to jump the gun is deserved. But collectively, it seems like the work needs to focus on putting in more robust disclosure processes for everyone so that we don’t fall into the trap of repeating this scenario the next time a vulnerability like this rolls around.
Source: www.darkreading.com