cash app slots

Cybercrime and Dark Web Research / To Disclose, or Not to Disclose: The PoC Dilemma

To Disclose, or Not to Disclose: The PoC Dilemma

To Disclose, or Not to Disclose: The PoC Dilemma
Sean Nikkel
Read More From Sean Nikkel
November 30, 2021 | 6 Min Read

At the beginning of our conversation on vulnerability intelligence a couple of weeks ago, I briefly touched on a fictional weeklong scenario that involved vulnerability disclosure, PoC (proof-of-concept) release, and mass scanning that ended with victims hit by exploits. I get it, a week to go from vulnerability to working exploit may seem like hyperbole, but we’ve seen recent cases where things moved almost that quickly–from just a couple of weeks to a month.

Probably, hardly enough time for the defenders to react and patch, to be perfectly honest.

R&B singer Craig David, with a much better use of a week’s time.
R&B singer Craig David, with a much better use of a week’s time.

Researchers developing PoCs are a natural byproduct of the existence of imperfect code and the greater need to secure all the things. It’s likely *most* researchers mean well when they release a PoC, but done incorrectly it can exacerbate the vulnerability problem.

How Soon is Now?

It’s not just a by the Smiths, it’s also a fairly spirited debate that can be separated into two arguments. 

On one side, there’s the thought that publicly disclosing a proof-of-concept in the wake of a vulnerability announcement forces the hand of everyone with a stake in the security game. It gives teams the ability to independently verify whether a network’s systems are exploitable, which enables better understanding of scale and severity, and leads to informed decisions about remediation. Best of all, it makes vendors develop fixes more quickly, and pushes end users to apply the patches.

On the other hand, there are some who advocate making patches available immediately when vulnerabilities are announced, and slowing down the release of PoCs until organizations are patched. In theory, this allows time for everyone to get their collective acts together so that they’re secured by the time vulnerabilities reach exploitation.

Now, there are flaws in each argument. The first argument assumes that every organization has the technical expertise or available resources to basically “red team” their infrastructure, and has all kinds of free time because they’re already caught up on all of the other patching and maintenance. As Chris touched on in an earlier blog, the reality is that there are competing priorities in every organization, which often boil down to time and resources devoted to patching.

The second argument assumes a high barrier to entry for developing workable exploits. Nation-states and the more well-financed criminal groups out there are already buying up zero-days, and are likely sophisticated enough to figure out how to exploit a vulnerability based on what was fixed in a patch, or in a PoC demonstration that might’ve left out a few steps. As we found out in our vulnerability research, criminal forum users are more than happy to share their knowledge or otherwise rent out their expertise, so it may not always be the bigger players who get the win on exploits.

Those who were paying attention to the Great Exchange ProxyLogon Disaster we all felt earlier in 2021 got a front-row seat to the debate. While the activity itself was known around December and into January, in the middle of the investigations, a researcher posted a public PoC that made it easy for actors to make the leap into exploit in pretty short order. Within 20 days of that PoC publication, the number of adversaries attempting to exploit the ProxyLogon vulnerability increased exponentially. At the time, many prominent researchers and security firms were erring on the side of caution, and it’s likely that this researcher felt some of the internet’s wrath on this one.

When Vulnerabilities Go Bad

As it turns out, there was a wealth of examples just this year where vulnerabilities went to the dark side of the Force.

Besides the aforementioned Exchange vulnerability that saw mass exploitation in less than a month after the PoC was published, we saw a similar story in a few recent case studies. Pulse Secure was one that not only saw the use of an out-of-cycle security advisory in April 2021, and within roughly 3 days of that announcement, cash app slots Shadows saw the first working PoC appear on GitHub. Sadly, it took nearly two more weeks before Pulse Secure was able to catch up with a patch. 

VMware had a similar problem on its hands with a PoC that came about within two weeks of its own announcement involving vulnerabilities with vSphere during the summer of 2021. With vSphere playing such a major role in virtual server management, the patching and mitigations may have left network teams overwhelmed when trying to sort out the question of maintenance. 

Vulnerability intelligence just might save the day

As we’ve been harping on over the last month, talking about vulnerability intelligence, knowing that critical context behind vulnerabilities just might make deciding to patch or mitigate an easier decision. There’s some oft-cited research out there that indicates a small percentage of vulnerabilities even get to the proof-of-concept stage, much less exploited. It helps to have that understanding of how they’re using it, or if they’re even using it to know how at-risk you might be.

You might have a stack of critical vulnerabilities to worry about, but knowing whether they’re getting into the proof or exploit neighborhoods just might be what you need to bump up the patching schedule. It could be a matter of days or weeks before adversaries not only discover your vulnerable infrastructure, but are then able to leverage an exploit to get in. Ransomware operators might be using it to extort you financially, nation-states could be after the accesses or other secrets you offer, or it might just be an opportunity for criminals to steal data for resale elsewhere. 

Level up the defenses

There’s a reason why Sun Tzu’s quotes get reused so often when talking about security. To loosely paraphrase, knowing what your adversary is up to can help you win the battle, or at least give you a fighting chance (my add). Having intelligence as a layer in your defenses arms you for the fight, and should coexist within a risk-based vulnerability management model, as my team discussed in a previous blog. To use another tired security proverb: Defenders need to be lucky all the time, an adversary only needs that luck once.

If you’re curious how intelligence can help you in the fight, you can always take Searchlight for a ; or, if you have some pretty specific needs, there’s a chance we have some ideas that we can discuss sometime.