Tech

Is it still a good idea to publish proof-of-concept code for zero-days?

Time and time again, the publication of PoC code for zero-days and recently patched security bugs often helps hackers more than end-users.

Written by Catalin Cimpanu, Contributor March 18, 2019 at 4:23 a.m. PT

More often than not, the publication of proof-of-concept (PoC) code for a security flaw, especially a zero-day, has led to the quick adoption of a vulnerability by threat actors who usually start attacks within hours or days, and don't give end-users enough time to patch impacted systems.

Security

There has been a debate about this issue, especially when the PoC code doesn't come from bad guys or other independent sources, but from white-hat security researchers, who in theory, should be focused on protecting users.

The debate around this controversial practice has been going for years, with people in the information security (infosec) field taking both sides of the aisle.

One side argues that security researchers should never publish PoC code because attackers can take that code and automate attacks, while the other side argues that the PoC code is also needed to test large networks and identify vulnerable systems, hence, it should be included where available, as it allows IT departments to simulate future attacks.

In the "Cybersecurity threatscape Q4 2018" report published last month, security experts from Positive Technologies touched on this long-lasting debate once again.

While Positive Technologies experts didn't have an issue with the publication of proof-of-concept code in general, they did have an issue with the release of PoC code too quickly after news of a vulnerability broke, or the release of PoC code for zero-days --both cases that don't leave users enough time to patch, if no time at all.

The company mentioned this issue in its quarterly threat report because such incidents have been happening more and more often.

For example, the list below includes a series of incidents where attacks have taken place immediately after the publication of PoC code, or where researchers published zero-day disclosures accompanied by PoC code, instead of waiting for vendor patches.

A Windows zero-day disclosed on Twitter with a PoC included, was abused in malware campaigns observed by ESET researchers.
PoC code published for an unpatched bug in a Chinese PHP framework led to immediate attacks against millions of sites.
PoC code published for a Cisco flaw disclosed last year and affecting RV110, RV130, and RV215 routers led to attacks against such devices, and a Cisco patch soon followed.
An Internet Explorer zero-day was adopted by an exploit kit within days last year after the publication of PoC code.
The Cobalt hacking group also started abusing a Flash zero-day days after the publication of a patch and PoC code.

ZDNet spoke with Leigh-Anne Galloway, cybersecurity resilience lead at Positive Technologies, to expand the subject further.

"As an industry, we have responsible disclosure guidelines. This isn't followed by all," Galloway told ZDNet in an interview. "Equally it isn't known or understood by all vendors.

"Often the driver for disclosing publicly is because the vendor has not recognised the severity of the issue and is not closing the vulnerability. Or the security researcher may have tried all other avenues for communicating their findings. Of course, the danger is that criminals may use this information to target victims.

"Vendors ask to provide evidence that the vulnerability is actually present in their product and can be exploited when researchers report the vulnerability to them. Researchers need to demonstrate how it can be exploited, and for this, PoCs are created.

"The presence of an exploit also determines the level of danger assigned by the CVSS system. If a vendor pays the researchers for the revealed vulnerabilities within the framework of a bug-bounty, the researchers earn money from this work, but often vendors do not arrange their bug-bounty program, and all that a researcher can get from this is public recognition by the expert community.

"By demonstrating the description of the vulnerability on the Internet, showing an example of operation and PoC code, researchers get recognition and respect," Galloway said.

"Usually, researchers publish the exploit code only after a sufficiently long time after they notify the vendor about the vulnerability, giving product developers the opportunity to close the vulnerability and notify users of the need to install upgrades.

"But very often, vendors delay the release of patches and updates, sometimes for a period of more than six months, so it happens that the publication of the [PoC] exploit occurs literally after the publication of the patch.

"In addition, we can not exclude cases where the exploit is published not by the researcher who told the vendor about the vulnerability, but someone else who just found out about the vulnerability from the Internet and immediately wrote an exploit for it," Galloway said.

"On the one hand, the publication of an exploit increases the risk of successful attacks and simplifies the attack itself, but on the other hand, it is an incentive for companies and ordinary users to follow the basic principles of information security to update their systems regularly and in a timely manner," the Positive Technologies expert concluded.

So, all in all, the publication of PoC code is helpful in some cases, but security researchers who find these flaws, or even those who are studying these bugs, should show some restraint in publishing such code too soon after a patch is released, or at least delay it for a few weeks, to give users time to patch.