Log4j Proved Public Disclosure Still Helps Attackers

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:

• Researcher informs vendor about vulnerability with accompanying PoC.
• Vendor confirms vulnerability and works on a fix with approximate timeline.
• Once the fix is in place, vendor asks researcher to confirm fix works.
• After researcher confirms the fix, vendor implements patch.
• A certain time after the patch release, details of the vulnerability can be published if vendor agrees to it (anything up to 90 days is normal).
  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:

To read the complete article, visit Dark Reading.