Did Kaseya Wait Too Long to Patch Remote Software Flaw?

•
July 6, 2021    

Ransomware-wielding criminals continue to hone their illicit business models, as demonstrated by the strike against customers of remote software vendor Kaseya.

See Also: Live Panel | Zero Trusts Given- Harnessing the Value of the Strategy

A full post-mortem of the attack by REvil – aka Sodinokibi – has yet to be issued because Kaseya has yet to patch the flaw exploited by attackers in its on-premises software. But one question sure to be leveled at the vendor is this: Should it have fixed the flaw more quickly?

“The word ‘responsible’ evoked a lot of emotional responses for people.” 

Attackers exploited Kaseya’s on-premises VSA software via a zero-day flaw, so called because no patch or other mitigation for the vulnerability was yet available and because the existence of the flaw was not public knowledge.

Kaseya had been notified about the underlying flaw at some point by the Dutch Institute for Vulnerability Disclosure, which has so far declined to state when that happened, except to say that it has been following a coordinated vulnerability process. The typical standard for such a process is for a notified vendor to push a patch within 90 days – or much sooner if the exploit is being actively exploited in the wild – at which point the researcher who found the flaw would typically publicly describe it (see: Kaseya Was Working on Patches Before Ransomware Attack).

Open questions: When did DIVD first notify Kaseya about the flaw, when did Kaseya confirm the flaw back to DIVD – in general, this process does not always go smoothly – and by when it had agreed to release a patch?

Reached for comment, a Kaseya spokeswoman tells me: “All details we are able to share will be made available after the criminal investigation has closed.”

But an entry was reserved for the flaw with the U.S. National Vulnerability Database, designated CVE-2021-30116, on April 2.

As a disclaimer on NVD’s site states: “The record creation date may reflect when the CVE ID was allocated or reserved and does not necessarily indicate when this vulnerability was discovered, shared with the affected vendor, publicly disclosed or updated in CVE.”

Still, the CVE ID was reserved 91 days before REvil struck, which suggests several possible scenarios, including the vendor having not yet prepped a patch more than 90 days after learning of the flaw. Again, 90 days is a typical time frame in what is commonly referred to as “coordinated vulnerability disclosure.”

The process is sometimes referred to as “responsible disclosure,” including by Kaseya on its website, although this more value-laden description long ago fell out of fashion.

As Microsoft’s Mike Reavey, who formerly headed the Microsoft Security Response Center, told me in 2011: “The main reason for that shift was because the word ‘responsible’ evoked a lot of emotional responses for people.”

In other words, what Microsoft considered a “responsible” amount of time for it to be allowed to fix a flaw before a researcher disclosed it publicly often wasn’t what the researcher might have considered to be responsible. So Microsoft began using the word “coordinated” instead.

How Did REvil Find Flaw?

Another unanswered question is how REvil learned about the flaw, which it then used Friday to push malicious updates via VSA. One possibility is that someone – an initial access broker who may have first hacked into the Kaseya network, or a REvil admin, or an affiliate of the ransomware-as-a-service operation – was camped out inside Kaseya’s network for weeks or months, monitoring internal communications.

To its credit, Kaseya maintains a clear vulnerability disclosure page on its website, inviting any researcher who wants to report flaws to contact the software vendor at “security@kaseya.com.”

Of course, if you were a member of a ransomware operation that takes an interest in MSPs and their software providers, and you had access to Kaseya’s network, then keeping an eye on any bug reports sent to that email address might be your No. 1 priority.

Well-Timed Attack

Again, this is conjecture. But the REvil operation managed to pull off an attack that was audaciously timed, with a degree of sophistication that was sufficient to infect what Kaseya says is up to 60 MSPs and 1,500 of their collective customers.

REvil’s decision to target the flaw at the beginning of the July 4 holiday weekend in the United States was pulled straight out of the criminal-hacking playbook. The 2016 heist via the SWIFT money-moving system that targeted Bangladesh Bank, for example, began on a Thursday evening – the weekend starts on Friday in the country. This past Christmas Eve, Conti ransomware attackers struck the Scottish Environment Protection Agency. Hitting targets on a weekend or over a holiday makes it more likely that defenders will take longer to spot the intrusion, respond and successfully mitigate it (see: Hackers Love to Strike on Saturday).

The timing of the attack and numerous other attributes of the Kaseya-targeting campaign – including hitting a supply chain, using zero-day flaws, distributing malicious updates and targeting MSPs – have all been seen before.

Indeed, when REvil apparently emerged from the ashes of the GandCrab RaaS operation in mid-2019, one of the lures for former GandCrab affiliates was that REvil had better functionality for attacking MSP customers to make it easier to negotiate with and restore systems for each individual MSP customer, ransomware incident response firm Coveware told me at the time.

MSPs have long been attractive to ransomware attackers because these IT service providers typically have remote, administrative-level access to their clients’ endpoints. If attackers can gain access to MSPs’ remote management software, then they can use it to distribute ransomware directly onto endpoints.

In the wake of this precise type of VPS-enabled hit on Kaseya’s MSP customers – and those MSPs’ clients – REvil on Monday said it would release a single decryptor to decrypt every victim, for $70 million in bitcoins, although the offer later appeared to have been reduced to $50 million in bitcoins.

This offer may have been based on logistics, given the challenge REvil would face in attempting to negotiate individual ransoms with some of the 1,500 victims.

Brett Callow, a threat analyst at security firm Emsisoft, says REvil’s payment portal has been intermittently down since the attack – perhaps because it’s been overwhelmed, or by design. “This could create real problems for victims – they can’t even begin to negotiate because REvil’s portal is inaccessible,” he tells me. “It could also be an intentional play by REvil to put pressure on Kaseya and/or insurers. The more time recovery takes, the greater the losses” – for victims.

On-Premises Patch Not Ready Yet

Kaseya says it’s still prepping that CVE-2021-30116 fix for its on-premises software. The company took its software-as-a-service version of VSA offline Friday as well – just to be safe, it was not exploited – and says it could be back online on Wednesday, with the on-premises patches due to be released 24 hours later, although that’s all subject to change.

“In the spirit of responsible disclosure, Kaseya will be publishing a summary of the attack and what we have done to mitigate it,” the company says.

Stay tuned for more questions concerning whether the software vendor should have patched the exploited flaw in a more timely manner.

Updates (July 7): This blog has been updated with a comment from a Kaseya spokeswoman, as well as to note that the company’s target of releasing patches beginning on Tuesday has been delayed.