PoC Exploits Do More Good Than Harm: Threatpost Poll

exploit PoC

More than half of security experts think that the good outweighs the bad when it comes to proof-of-concept exploits, according to a recent Threatpost poll.

When it comes to the release of proof-of-concept (PoC) exploits, more security experts agree that the positives outweigh the negatives, according to a recent and informal Threatpost poll.

Threatpost Webinar Promo Mobile App Security Last week, Threatpost conducted a reader poll and almost 60 percent of 230 security pundits thought it was a “good idea” to publish PoC code for zero days. Up to 38 percent of respondents, meanwhile, argued it wasn’t a good idea.

The debate comes on the heels of PoC code being released last week for an unpatched remote-code-execution vulnerability in the Citrix Application Delivery Controller (ADC) and Citrix Gateway products. The PoC exploits, which were published to showcase how the vulnerability in a system can be exploited, raised questions about the positive and negative consequences of releasing such code for an unpatched vulnerability.

Some argued that the code can be used to test networks and pinpoint vulnerable aspects of a system, as well as motivate companies to patch, but others in the security space have argued that PoC code gives attackers a blueprint to launch  and automate attacks.

Many security experts point to the role of PoC code publication in motivating impacted companies and manufacturers to adopt more effective security measures. That was the argument of one such advocate, Dr. Richard Gold, head of security engineering at Digital Shadows, who said that PoC code enables security teams to test if their systems are exploitable or not.


“Rather than having to rely on vendor notifications or software version number comparisons, a PoC allows the direct verification of whether a particular system is exploitable,” Gold told Threatpost. “This ability to independently verify an issue allows organizations to better understand their exposure and make more informed decisions about remediation.”

In fact, up to 85 percent of respondents said that the release of PoC code acts as an “effective motivator” to push companies to patch. Seventy-nine percent say that the disclosure of a PoC exploit has been “instrumental” in preventing an attack. And, 85 percent of respondents said that a PoC code release is acceptable if a vendor won’t fix a bug in a timely manner.

When it comes to the recent Citrix vulnerability (CVE-2019-19781) for instance, advocates argue that, though PoC exploits were released before a patch was available, the code drew attention to the large amounts of vulnerable devices that were online. Citrix has also accelerated its patch schedule after PoC exploits were released (though there is no proof of correlation between this and the PoC exploit releases).

“As a result [of the Citrix PoC exploits], there has been a widespread effort to patch or mitigate vulnerable devices rather than leaving them unpatched or unsecured,” Gold stressed.

On the flip-side of the argument, many argue that the release of the Citrix PoC exploits were a bad idea. They say attacks attempting to exploit the vulnerability skyrocketed as bad actors rushed to exploit the vulnerabilities before they are patched. In fact, 38 percent of respondents in Threatpost’s poll argued that PoC exploit releases are a bad idea.

Matt Thaxton, senior consultant at Crypsis Group, thinks that the “ultimate function of a PoC is to lower the bar for others to begin making use of the exploit.”poll 2

“I believe there are more negatives than positives to publishing proofs, and generally, it is not a good idea,” he told Threatpost. “In many cases, PoC’s are put out largely for the notoriety/fame of the publisher and for the developer to ‘flex’ their abilities.”

Joseph Carson, chief security scientist at Thycotic, told Threatpost that while he thinks PoC exploits can have a positive impact, “it is also important to include what defenders can do to reduce the risks such a methods to harden systems or best practices.”

“Let’s be realistic, once a zero-day is known, it is only a matter of time before nation states and cybercriminals are abusing them,” said Carson. “Sometimes they already know about the zero-day and have been abusing them for years.”

Respondents in the poll were also split about the right amount of time that’s appropriate to release PoC code after a flaw has been disclosed, with 29 percent arguing 90 days is the appropriate amount and others opting for one month (25 percent), one week (23 percent) or two weeks (14 percent).

This issue of a PoC exploit timeline also brings up important questions around patch management for companies dealing with the fallout of publicly-released code. Some, like Thaxton, say that PoC exploit advocates fail to recognize the complexity of patching large environments: “I believe the release of PoC code functions more like an implied threat to anyone that doesn’t patch: ‘You’d better patch . . . or else,'” he said “This kind of threat would likely be unacceptable outside of the infosec world. This is even more obvious when PoCs are released before or alongside a patch for the vulnerability.”

At the end of the day, PoC exploits are continuing to be published. In fact, beyond the release of the Citrix PoC code, a slew of other PoC exploits were released last week, including ones for a recently patched crypto-spoofing vulnerability found by the National Security Agency (NSA) and reported to Microsoft; and another for critical flaws impacting the Cisco Data Center Network Manager tool for managing network platforms and switches.

Gold, for his part, argued that distinguishing a fine line between a theoretical vulnerability and a successful exploitation of a real system makes all the difference when it comes to PoC exploits versus active exploits.

“Once that threshold has been crossed, it is understood that attackers will most likely be exploiting this vulnerability in real attacks,” he said. “This often provided impetus to companies to patch their systems.”

Concerned about mobile security? Check out our free Threatpost webinar, Top 8 Best Practices for Mobile App Security, on Jan. 22 at 2 p.m. ET. Poorly secured apps can lead to malware, data breaches and legal/regulatory trouble. Join our experts from Secureworks and White Ops to discuss the secrets of building a secure mobile strategy, one app at a time. Click here to register.

Suggested articles


  • webgator on

    nice article.. really helpful....
  • PeterA on

    PoCs should be released at the same time as patches. Before that time PoCs should be released 14 days after disclosure of the existence of an issue to the public. So timeline: Inform vendor -> 30-90 days (+14) -> disclose existence and maybe publicise mitigations -> 14 days -> publish PoC. This gives everyone involved time to patch, time to mitigate, and time to test without unnecessary exposure.
  • PDRosa on

    We have a robust asset protection and threat management program but it still can take us 7 days to deploy a critical patch as it passes thru dev-test-prod environments. And that's if the patch doesn't actually break production. I akin PoC to publishing a list of all the unlock homes in my neighborhood (not a good practice). This inevitably invites the bad guys to stop by for a visit.
  • BreachBreaker on

    POCs aren't just proving the concept. They are attack tools and they get used all the time. No security expert will debate that. Here's where they are a benefit (as they were to me today): Proving the need to accept a patch or mitigate a problem. Here's what you need before you can do that: A security expert who knows how to demo the POC. This leaves pretty much everyone else out in the cold, dangerous wild. The problem is that good hackers are so plentiful and reverse engineering tools so good that NOT releasing the POC may not mitigate damage as much as we think, and of course they can do good. The day that liability-limiting EULAs become illegal... will be the day that we REALLY see a shift in security posture.
  • Ben on

    I think the Threatpost poll on when to release PoC is a little too generalized. In most situations I think 90 days should be provided to a vendor. However, when the vendor/product claims itself to be improving security, then I think in that situation 30 days makes sense. Pretending like grey-hat and black-hat markets for exploits do not exist is problematic. Citrix Netscaler solution in a high availability configuration may have sold to some enterprises at over $100,000--and that is just in a single sale. An exploit to make a targeted attack against some of the type of customers Citrix sell solutions to should make a PoC on a "darkweb" marketplace worth a lot. Yet, the Citrix knowledgebase article on security issue reporting offers no dollar amount to encourage whitehat disclosure. They have no base payout, no average payout and no minimum payout stated. They claim to have policies and third party auditing such a ISO 27001 and SOC2, but neither of those should be considered a replacement for a security bug bounty offering. Netscaler was sold on the basis of *decreasing* security exposure to make an environment *more* secure. A Proof of Concept that applies to four major versions of the product shows a long time period in which the product increases security exposure. The PoC takes away an excuse a security vendor may have that the attack is "very complex" or that it is not known to be in the wild. Looking back at the Citrix Q3 earnings call in light of this CVE and PoC is extremely damning what Citrix claims to be doing and providing. Citrix CEO David J. Henshall: "Largest companies in the world rely on Citrix. It's a critical part of their IT and security infrastructure." "The other verticals of course where security and compliance is absolutely critical to their business and therefore, our solutions are a perfect fit." "We build security within a lot of this, whether that's just security as a way to access, to manage devices, to enforce policies, etc." "Choices about infrastructure, choice of device, choice of cloud providers and the recognition that those things will change over time, so it's critically important for us to maintain that, and then, of course, inherent security that is built into everything that we do right now, both from an individual security product standpoint and a secure architecture." Citrix CPO PJ Hough: "A second key focus area for our customers today and one that comes up in every conversation that we have is around security, enterprise security. And how customers deal with the potential of the opportunity of the cloud of the potential of a mobile and flexible workforce and at the same time providing the governance and controls that they need to deliver their business securely." "Active adoption means that we not only secure that customer for the long-term, but we also see a significant opportunity to continue to sell them incremental value-based services and expand the overall seat licenses that they're using..." Citrix CFO Arlen Shenkman: "Citrix is uniquely positioned to tap into the potential of our customer base, while also solving significant productivity and security pain points for our customers." When a company is willing to make such strong statements about delivering on security, they should be expected to be held to a higher standard than your common software or appliance vendor. Also, such a company should have the confidence in their own products to offer a stated security bug bounty payment when they fail to deliver on their claims. In the case of Citrix, it appears to me that all their posturing of delivering security has resulted in *NO* stated bug bounty payment structure at all. They expect customers and investors to pay into their claims while apparently lacking any attempt to compete with Zerodium and darkweb exploit auctions. The situation of a PoC being released 30 days after the CVE may seem like not being a good practice, but I believe Citrix was instrumental in making it the best possible response. When a customer chooses a "security solution," they should also take into account what percentage of what they are paying is matched by a minimum security bug bounty payment when the product fails to work as claimed. I believe customers that selected poorly when going with what appears to me is Citrix's complete disregard for a stated bug bounty payment system.
  • Anonymous on

    It seems as of late, that the disclosure aspect of this is the real problem. POC when handled properly are amazing and extremely good proactive elements. The example Citrix 2019-19781 was handled poorly and resulted in a wide scale exposure and didn't not help at all.

Subscribe to our newsletter, Threatpost Today!

Get the latest breaking news delivered daily to your inbox.