Public disclosure of vulnerabilities has always bothered me and I wasn’t able to put a finger on the reason until now. As a person who has been involved personally in vulnerabilities disclosure, I am highly appreciative of the contribution security researchers on awareness and it is very hard to imagine what would the world be like without disclosures. Still, the way attacks are being crafted today and their links to such disclosures got me into thinking whether we are doing it in the best way possible. So I twitted this and got a lot of “constructive feedback”:) from the team in the cyber labs at Ben-Gurion of how do I dare?
One has to wonder whether the growth in #cyber attacks is due to the good work of #infosec research finding and disclosing vulnerabilities
? Dudu Mimran (@dudumimran) April 14, 2015
So I decided to build my argument right.
Vulnerabilities
The basic fact is that software has vulnerabilities. Software gets more and more complex within time and this complexity usually invites errors. Some of those errors can be abused by attackers in order to exploit the systems such software is running on. Vulnerabilities split into two groups, the ones which the vendor is aware of and the ones who are unknown. And it is unknown how many unknowns are there inside each piece of code.
Disclosure
There are many companies, individuals, and organizations which search for vulnerabilities in software and once they find such?they disclose their findings. They disclose?at least the mere existence of the vulnerability to the public and the vendor and many times even publish proof of concept code example which can be used to exploit the found?vulnerabilities. Such disclosure serves two?purposes:
- Making users of the software aware of the problem as soon as possible
- Making the vendor aware of the problem so it can create and send a fix to their users
After the vendor is aware of the problem then it is their responsibility to notify the users formally and then to create an update for the software which fixes the bug.
Timelines
Past to Time of Disclosure – The?unknown vulnerability waiting silently and eager to be discovered.
Time of Disclosure to Patch is Ready – Everyone knows about the vulnerability, the good and the bad guys, and it is now on production systems waiting to be exploited by attackers.
Patch Ready to System is Fixed – Also during this time period, the vulnerability is still there waiting to get exploited.
The following diagram demonstrates those timelines in relation to the ShellShock bug:
Image is taken from?http://www.slideshare.net/ibmsecurity/7-ways-to-stay-7-years-ahead-of-the-threat
Summary
So indeed the disclosure process eventually ends with a fixed system but there is a long period of time where systems are vulnerable and attackers don’t need to work hard on uncovering new vulnerabilities since they have the disclosed one waiting for them.
I got thinking about this after I saw this stats via Tripwire
This stats means that half?of the exploits identified during 2014 were based on published CVEs (CVE is a public vulnerability database) and although some may argue that the attackers could have?the same knowledge on those vulnerabilities before they were published I say?it is far-fetched. If I was an attacker what would be easier for me than going over the recently published vulnerabilities and finding one that is suitable for my target and later on building an attack around it. Needless to say that there are tools which provide also examples for that such as?Metasploit. Of the course, the time window to operate is not infinite such as in the case of an unknown vulnerability which no one knows about but still, a month or more is enough to get the job done.
Last Words
A new process of disclosure should be devised where the risk level during the time of disclosure up to the time a patch is ready and applied should be reduced. Otherwise, we are all just helping the attackers while trying to save the world.