The Log4j debacle showed again that public disclosure of 0-days only helps attackers

On December 9, 2021, a (now deleted) tweet linking to a 0-day proof of concept (PoC) exploit (also now deleted) for the Log4Shell vulnerability on GitHub set the internet on fire and sent companies scrambling to mitigate, patch and then patch again as additional PoCs appeared.

Public vulnerability disclosure – i.e., the act of revealing to the world the existence of a bug in a piece of software, a library, extension, etc., and releasing a PoC that exploits it – happens quite frequently, for vulnerabilities in a wide variety of software, from the most esoteric to the most mundane (and widely used).

Over time, research and experience have shown us that threat actors are they only ones who benefit from the public release of 0-day PoCs, as this suddenly puts companies in an awkward position of having to mitigate the issue without necessarily having something concrete to mitigate it with (i.e., a vendor’s patch).

How does responsible vulnerability disclosure usually work?

All kinds of responsible vulnerability disclosure mechanisms exist today. Some companies have an officially sanctioned and widely publicized vulnerability disclosure program, others organize and run it through crowdsourced platforms. Generally, companies offer money for information about vulnerabilities in their products (aka “bug bounties”).

Those disclosures often go through a specific process, and there are clearly defined timelines for the release of a vendor patch so that users may have ample time for implementing it (90 days is the accepted standard for this). It is also often stipulated that a PoC can only be released publicly with vendor approval (this is also known as “coordinated disclosure”). On top of this, bug bounty platforms occasionally require participating security researchers to agree to a non-disclosure agreement, meaning that PoCs may never end up being published even if the vulnerability has long been fixed.

The process of disclosing a vulnerability to the affected vendor usually follows this sequence (if all goes smoothly):

• The researcher informs the vendor about vulnerability and provides an accompanying PoC
• The vendor confirms the existence of the vulnerability and provides an approximate timeline for the release of a fix
• Once a fix has been developed, the vendor asks the researcher to confirm whether the fix works
• After the researcher “confirms” the fix, the vendor implements the patch
• If the vendor agrees to it, a certain time after the patch is released the details of vulnerability can be published (anything up to 90 days is normal)

In regard to the Log4Shell vulnerability, the disclosure process was already underway when it was publicly revealed (as evidenced by the pull request on GitHub that appeared on November 30). According to information provided by the Apache Software Foundation, the timeline of the disclosure looks like this:

• November 24: The Log4j maintainers were informed
• November 25: The maintainers accepted the report, reserved the CV, and began researching a fix
• November 26: The maintainers communicated with the vulnerability reporter
• November 29: The maintainers communicated with the vulnerability reporter
• December 4: Changes were committed
• December 5: Changes were committed
• December 7: First release candidate created
• December 8: The maintainers communicated with the vulnerability reporter, made additional fixes, created second release candidate
• December 9: Patch released

While user comments on the Apache Log4j GitHub project page indicated frustration with the speed of the fix, this is par for the course when it comes to fixing vulnerabilities – as everyone keeps pointing out, the patch was, after all, built by volunteers.

The reasons for releasing 0-day PoCs, and the arguments against it

There may be legitimate and understandable reasons for releasing a 0-day PoC. The most common of those is the breaking down of the vulnerability disclosure process: the vendor may not be or may stop being responsive, may consider the vulnerability as not serious enough to warrant a fix, may be taking too long to fix it – or any combination of the above. In cases such as these, security researchers often decide to release the PoC for the “common good”, i.e., to force the vendor to release a fix, and quickly.

There may also be other reasons, such as publicity (especially if the researcher is linked to a security vendor) – nothing gets faster press coverage than a 0-day PoC exploit for a widely used piece of software, especially if there is no patch available.

But it must be pointed out that the evidence against releasing PoC exploits is now robust and overwhelming.

A study completed by Kenna Security has shown that publishing PoC exploits mostly benefits attackers. Several years ago, a presentation at Black Hat walked through the lifecycle of zero-days and how they were released and exploited, and showed that if PoC exploits are not disclosed publicly, the vulnerabilities in question are generally not discovered for an average of 7 years by anyone else (threat actors included).

Sadly, this was realised a bit too late during the log4j scramble. Initial tweets and disclosures were promptly walked back but the damage was done. Even the most recent disclosure which caused the release of patch 2.17.1 received so much flak from the security community that the researcher issued a public apology for the poor timing of the disclosure.

It’s good to see that the attitude towards public disclosure of PoC exploits has shifted. The criticism of researchers who decide to jump the gun is deserved but, collectively, we need to focus on setting up more robust disclosure processes for everyone so that the public PoC scenario is not repeated the next time a vulnerability like Log4Shell is discovered.

Source: https://www.helpnetsecurity.com/2022/01/06/log4j-debacle/