White hats reported key Kaseya VSA flaw months ago. Ransomware outran the patch One of the vulnerabilities in Kaseya's IT management software VSA that was exploited by miscreants to infect up to 1,500 businesses with ransomware was reported to the vendor in April – and the patch just wasn't ready in time. As we've covered this week, deployments of Kaseya's flagship Virtual System Administrator (VSA) …
That's certainly possible. However, this really highlights the biggest problem with so-called responsible disclosure (i.e., reckless non-disclosure of bugs): it coddles vendors and removes all sense of urgency in getting fixes out. April was 3 months ago; we all know that testing software is difficult and can be time-consuming, but given that this bug wasn't found in the first place one has to wonder what kind of test suite needed to be run.
Let's put it another way: if DIVD had simply disclosed publicly, would the bug have been fixed by now? I think we all know that the answer is yes. The correct assumption must always be that any bug of this kind is known to and being actively exploited by criminals, whether or not there is any specific evidence of that. Even if it isn't, it soon will be, because while the people who found and reported it are certainly clever and capable, they are probably no more clever and capable than anyone else, and there's a good chance someone else actually found it first. To assume otherwise is simple hubris.
The conclusion one ought to draw is that there is never any time to waste: fixing serious bugs like this is an extremely urgent matter that should generally be done in days, not months. Giving vendors extremely long periods of time to fix reported bugs (many people start with 90 days and grant numerous extensions) only gives attackers more time to find the bugs themselves -- or to learn of them through backchannels -- and exploit defenseless and ignorant customers. If one insists on this style of engagement, the timelines need to be tightened dramatically: start with 7 days and offer a 14-day extension if the vendor has a patch ready to test after the first week. No more than that: customers are vulnerable and under attack while you dither. If a fix is too complex or too difficult to test in that time, then offer customers some other mitigation while you work on it. Keeping them in the dark results in... this.
You failed to mention the fact that if such a critical bug was reported publicly without "responsible disclosure" yes the bug would of been fixed faster, but it is much more likely that such a bug would be exploited even faster(faster than the bug could be fixed). I have no idea how this VSA software even works but even if a patch was released fast would the customers have been quick to patch? (or are their patches applied automatically?)
You can see this in real time right now with the "print nightmare" stuff from MS. Fumbling about releasing patches that don't fix the issue and cause other major issues(reports of people not being able to print with certain kinds of printers) etc. And in that case the disclosure of the bug if I recall right was an accident with the reporter thinking it was already fixed.
It is very unfortunate though that security plays such a low priority in software development for the vast vast majority of organizations out there. Add to that security plays such a low priority in the operation of such software in the vast majority of organizations out there just look to how many times there are reports of compromises because of some issue that had a patch released but never applied, assuming they were even aware such software was in use(if you are running an insecure vpn appliance it should be obvious(obvious = patches available from vendor), but if you have code running insecure libraries it may not be obvious). Or even worse, organizations that expose systems such as databases directly to the internet, or "cloud" file shares that are meant to be private.
I don't know what the solution is, if there even is one. The cost of security issues hasn't gotten to the breaking point where companies are willing to invest more in security seems like anyway.
As mentioned above, this case highlights the major failure mode of "responsible disclosure". Kaseya had a major problem. They knew they had a major problem. They refused to do anything to protect their customers that might have damaged their reputation. Now this.
The motto of SRE at Google is "spes consilium non est". Kaseya better hope that they don't get sued by each and every end user whose system was compromised because they knowingly, willingly, left them twisting in the wind.
Unless Kaseya can show that they devoted significant resources to patching the software within days of being told of the vulnerability, I'm assuming they just ignored the problem for months. And I don't believe they were ready to patch just after it was going to be disclosed - responsible disclosure allows for an extension if the vulnerable company is acting in good faith.
Responsible disclosure benefits the IT community as a whole. Three months seems reasonable.
And I don't buy the "inside source" conspiracy theory. If an inside source wanted to help the hackers, they'd have told them three months ago.
The Register 
Biting the hand that feeds IT
Copyright. All rights reserved © 1998–2024
