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

0


In the wake of Microsoft Exchange ProxyLogon’s zero-day and F5-BIG-IP security exploits earlier this year, many wondered if and when researchers should release proof of conceptions for vulnerabilities and associated patches.

Hafnium hackers were able to identify three security flaws in MS Exchange, including one (ProxyLogon) that allowed them to perform server-side request forgery that enabled them to gain administrator 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 assumed that more than 100,000 servers worldwide were initially affected, including 30,000 in the USA

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

While it is common practice to publish PoC exploits for patched vulnerabilities, it carries an increased risk that threat actors will use them to attack thousands of unprotected servers. Indeed, we saw the DearCry ransomware attack on March 9th, the Lemon_Duck cryptomining attack on March 12th, and the Black Kingdom ransomware attack on March 19th. In fact, an estimated 25,000 servers were still vulnerable by the end of March, 10 of which advanced hacker groups had already exploited Microsoft Exchange servers, four of which were only created after the PoC for the patch was published.

When evaluating the costs / benefits of publishing the PoC for ProxyLogon, there are some factors to consider that we believe must be taken into account. On the one hand, publishing PoC exploits helps researchers understand the attack so they can build better protection. We also value the concept of freedom of expression. But on the other hand, who do you think is using a fully functional PoC script? Among them, hacking groups and script kiddies are clearly the most important.

How high was the risk to the global community when the PoC was published? A week after the patch was released and the PoC released, perhaps half of the vulnerable global servers were still unprotected. The hacks, which caused an estimated 100,000 infections, were identified by a Radware Threat Alert as “critical” for all industries around the world. Obviously, the timing of the published PoC played a role in the global devastation.

Let us now come to an example in which researchers reverse-engineered a patch and released it. On March 10, F5 announced that it had fixed an unauthenticated remote command execution bug in its BIG IP and BIG IQ corporate network infrastructure that allowed attackers to take full control of vulnerable systems. From there, they could move around virtually anywhere on the network. To mitigate the risk, F5 has not released details to allow customers 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 this vulnerability with multiple groups of threat actors attacking F5 network devices around the world. The National Vulnerability Database classified these vulnerabilities as critical. On top of the problem, many organizations were still focused on Microsoft’s ProxyLogon problem and were therefore slower to respond to the F5 vulnerability problem.

It’s one thing to reverse engineer malware and let the community know how to spot a particular attack and what tactics are used to more effectively protect systems. We should exchange indicators of compromise (IoCs) and create YARA rules to identify malware examples. Nmap scripts and RegEx help organizations identify if they have vulnerable systems, etc. However, I doubt how many people use PoC scripts for good causes compared to threat actors who use them to spread malware.

I understand why researchers want to create these scripts, but when they publish them publicly they open a Pandora’s box. All that is really needed is an indicator of compromise – there is no need to publish work programs that allow attackers to reproduce the attack.

I wonder if, in this case, posting PoC scripts is less about supporting secure systems and celebrating freedom of expression, or more about bragging rights within the security community. While it’s true that nation-states and advanced threat actors have the ability to reverse engineer patches to exploit them for themselves, that doesn’t mean researchers should empower the less experienced and make the work of each threat actor easier.

In summary, we give the reversal of malware a thumbs up by providing a detailed description of attacks discovered in the wild and posting helpful tools like IoCs, Yara rules, Nmap scripts, RegEx, and behavioral patterns. But draw the line when posting details of reverse engineering patches; Create, fork, and improve fully functional exploit scripts; and the release of fully functional PoC scripts to the world – including threat actors – before patches can be fully implemented.

Contributing Author: Daniel Smith, Director of Safety Research, Radware.



Source link

Share.

About Author

Leave A Reply