Should Exploit Code be Published When Vulnerabilities are Made Public?
On the heels of a recent report from Kaspersky Labs, discussions among security professionals have been stirred-up regarding the risks of publishing proof-of-concept code that may be helping hackers more than benefiting security. The topic has history and continues to be vigorously debated.
I think the emerging industry data is telling, but the inference that responsible reporting of vulnerabilities is causing unnecessary risk is a bit misleading. The situation is not clear cut, so let’s break it down.
First, Office is a popular target for researchers and malicious hackers because of its broad distribution as well as the files are often sent electronically. This opens massive avenues of misuse via phishing and document sharing, therefore a great distribution platform for threats to leverage. Success can have its drawbacks. In this case, the data shows how Office is becoming a preferred method of initial ingress by attackers, to victimize reach professionals and students who have Office installed.
Secondly, these vulns can date back several years and really should have been patched by users. Without a good foundation of security, malware can leverage the many holes to stack or chain together vulnerabilities to achieve their objectives.
Third, this is great data (thanks to Kaspersky Labs for always being on the cutting edge to share research findings) but is unclear if this is a temporary shift or if it represents the beginning of a long-term trend. Attackers are agile and their maneuvers can shift when they see opportunities. The vulnerability research business is constantly adapting while it seeks to find the best balance between confidential and public reporting.
One of the subtle points of contention is actually around publishing exploit code/examples when the vulnerability is reported. This is still a bit controversial, as it is not required, but has a valid history. Researchers can report weaknesses, without the proof-of-exploit code, but the likely attention and priority may be discounted. Malicious hackers on the other hand, are more than happy to use such code to rapidly create and distribute attacks. However, it is important to note that if it was disclosed responsibly, the vendor should have had ample time to create and distribute a patch before the exploit code was made public.
The conversations gets more heated when discussing zero-day vulnerabilities that have not been responsibly shared with vendors in advance, which may not give the overall process enough time to deploy viable patches to users. This is widely frowned upon and not in alignment with generally accepted reporting practices. It happens, but is rare. The purpose of white-hat hacking is to make technology more secure, which requires the vendor be informed and sometimes assisted in making corrections for improved security.
Timing is key
What we must prioritize, as members of digital society, is the reduction of overall risk to the technology and services we use. The risk of impacts due to unmitigated vulnerabilities increases over time. This is the exposure window that must be minimized. However, in the past many vendors lagged in their responsibilities to evaluate and produce necessary patches, sometimes claiming that the risk of misuse was low or technically infeasible. Researchers are able to up-the-ante by publishing an exploit to prove the severity and it forces vendors to react much faster. It is not exactly friendly as it puts tension in the system, but on the other hand, neither is ignoring a vulnerability that has been reported.
Successful vulnerability mitigation requires teamwork and everyone has a role. Researchers must responsibly report new discoveries, vendors must publish an effective patch in a timely manner, and end-users are key to applying the patch as soon-as-possible. Failure in any of these areas increases the window of opportunity for attackers and the risks to everyone.
What is best?
From one view, researchers publishing exploits with their vulnerabilities facilitates the faster creation of malware. On the other hand, it also motivates vendors to accelerate the patching to close the vulnerabilities. This is the accelerated dance that is happening. But what is the correct balance? Well, it is very complex given the variables across the economics of the vulnerability business, response of vendors, actions of end-users, benefits and focus of threat agents, and the shifting motivations of all groups involved. It becomes an exercise in partial differential equations that has yet to be figured out. Until then, the market moves in jumps to find optimal routes and processes.
White hat hackers/researchers will continue to push vendors for faster responses and malicious hackers will continue to leverage the same public research to develop their selfish wares as fast as possible. Continual adaptation will optimize the conflict-equation over time. The most we can do as end-users is focus on applying patches as fast as possible to our devices.
Interested in more? Follow me on your favorite social sites for insights and what is going on in cybersecurity: LinkedIn, Twitter (@Matt_Rosenquist), YouTube, Information Security Strategy blog, Medium, and Steemit