Is it OK to publish PoC exploits for vulnerabilities and patches?

In the wake of the Microsoft Exchange ProxyLogon zero-day and F5 BIG-IP security exploits earlier this year, many are questioning if and when should researchers publish proof of concepts for vulnerabilities and associated patches.

Hafnium hackers were able to identify three MS Exchange vulnerabilities, including one (ProxyLogon) that enabled them to perform a server-side request forgery that allowed them to obtain admin access by sending a crafted web request. Volexity identified this exploit in early January 2021 and Microsoft released a security update on March 2. Security researchers believed that more than 100,000 servers globally were initially affected, including 30,000 in the U.S.

On March 9, with most servers still unprotected by the security update, a researcher published a proof of concept (PoC) for the hack on Github, which Microsoft subsequently pulled and, by consequence, was faced with a lot of criticism. (Today you can find dozens of PoCs for this on Github.)

While publishing PoC exploits for patched vulnerabilities is common practice, this one came with an increased risk of threat actors using them to attack the thousands of servers not yet protected. And, indeed, we saw the DearCry ransomware attack on March 9, the Lemon_Duck cryptomining attack on March 12 and the Black Kingdom ransomware attack on March 19. In fact, by the end of March, with an estimated 25,000 servers still vulnerable, 10 advanced hacking groups had already exploited Microsoft Exchange servers, four emerging after the PoC for the patch was published.

When evaluating the cost/benefit of publishing the PoC for ProxyLogon, here are some factors that we believe need to be considered. On the one hand, publishing PoC exploits helps researchers understand the attack so they can build better protections. We also value the concept of free speech. But on the other hand, who do you think uses a fully functioning PoC script? Clearly hacking groups and script kiddies are chief among them.

What was the risk to the global community when the PoC was published? A week after the patch was released and the PoC was published, perhaps half of vulnerable global servers still weren’t protected. The hacks that caused an estimated 100,000 infections were described by a Radware Threat Alert as “critical” for all industries across the globe. Clearly the timing of the published PoC played a role in the global havoc.

Now let’s turn to an example where researchers reverse engineered a patch and published it. On March 10, F5 announced that it had fixed an unauthenticated remote command execution flaw in its BIG IP and BIG IQ enterprise networking infrastructure that allowed attackers to take full control over vulnerable systems. From there they could move practically anywhere in the network. F5, in an attempt to mitigate the risk, didn’t release details publicly so that customers would have time to update and patch their systems. The problem was that several researchers then reverse engineered the Java patch and published detailed blogs and PoCs by March 15.

Within three days, we saw mass scanning activity for that vulnerability with several groups of threat actors attacking F5 network devices around the world. The National Vulnerability Database had ranked these vulnerabilities as critical. Adding to the problem was the fact that many organizations were still focused on Microsoft’s ProxyLogon issue and so were slower to respond to the F5 vulnerability issue.

It’s one thing to reverse engineer malware and inform the community on how to detect a given attack, and describe which tactics are being used so that systems can be more effectively secured. We should share indicators of compromise (IoCs) and build YARA rules to identify malware samples. Nmap scripts and RegEx help organizations discover if they have vulnerable systems, etc. But I question how many individuals use PoC scripts for good purposes vs. threat actors who employ them to distribute malware.

I understand why researchers may wish to create these scripts, but when they post them publicly, they are opening a Pandora’s box. All that is really needed is an indicator of compromise – there is no need to publish working programs that allow threat actors to recreate the attack.

I wonder if publishing PoC scripts in this case is less about helping secure systems and celebrating freedom of speech or more about bragging rights within the security community. While it’s true that nation-states and advanced threat actors have the capability to reverse engineer patches to exploit them on their own, it doesn’t mean that researchers should enable the less experienced and make the job easier for every threat actor.

In summary, we give a thumbs up to reversing malware, providing detailed description of attacks discovered in the wild and publishing helpful tools such as IoCs, Yara rules, Nmap scripts, RegEx and behavioral patterns. But draw the line at publishing details about reverse engineered patches; creating, forking and improving fully functional exploit scripts; and handing over fully functioning PoC scripts to the world – including threat actors – before patches can be fully implemented.

Contributing author: Daniel Smith, Head of Security Research, Radware.