Ahhh, summer is upon us. Barbecues, fireworks, swimming pools, and (of course) zero-day vulnerabilities and ransomware. Wait… what?
If you were like me last weekend, you were gearing up for a weekend of fun in the sun when you heard the news of a widespread ransomware event affecting Kaseya VSA customers. The timing couldn’t have been worse, but at this point, it has almost become expected. Attackers love to target their victims during a time they hope to catch them napping.
Let’s dig into what we know and what you can do to prevent yourself from ending up on the victim list.
A Quick Glance at the Vaseya Zero-Day Vulnerability
For those who were not informed, on Friday, July 2, 2021, a ransomware attack was launched on Kaseya’s VSA remote monitoring and management tool. The numbers published are all over the place, but it has been reported there were between 30-60 MSPs and 1000-1500 end-customers impacted in 17 countries.
Once Kaseya became aware of the attack, they advised customers to shut down their on-prem VSA servers. All of their cloud-hosted servers were shut down as well.
Kaseya also released a breach detection tool.
Now, let’s break this down piece by piece: what happened, what is known, what is unknown, and what could have been done to prevent it.
A Deeper Dive
First, I’m sure you’ve all read the news that this is another supply chain attack with comparisons to SolarWinds.
Let’s set the record straight here and now—this was not a supply chain attack.
This attack relied upon the exploitation of vulnerabilities within the Kaseya VSA. In the Solarwinds attack, you will likely recall that attackers were able to manipulate source code and embed malware within an application update—not the case here. Attackers were exploiting zero-day vulnerabilities—the same as we saw with Hafnium (which was not labeled a supply chain attack).
A quick summary of the exploit is as follows:
A Timeline and Disclosure Question
Let’s talk about the vulnerabilities for a minute here.
The Dutch Institute for Vulnerability Disclosure (DIVD) had recently discovered multiple vulnerabilities in Kaseya VSA and had reported those to Kaseya. The vulnerabilities included methods for authentication bypass, arbitrary file upload, and command injection. By all standards and guidelines, these would certainly be considered a critical risk.
Kaseya has acknowledged being aware of these vulnerabilities and has stated they were working to remediate them when the attack occurred.
This is where things get a bit foggy.
No one knows when the DIVD reported the vulnerabilities to Kaseya—only that it had been reported before the attack.
Let’s pause and think about this for a minute. What should have been done by Kaseya when they became aware of the critical risk for all of their VSA servers?
Let’s follow the story of Microsoft for a minute here.
PrintNightmare was discovered sometime last week and there was no patch available (there is now, so go get it!). But, what did Microsoft do? They notified all their customers of the vulnerability along with mitigating controls to put in place while they worked to patch the vulnerability. This is what a responsible vendor should have done. Had Kaseya done this as well, this simple step could have significantly reduced the impact of this event.
I understand there are risks with exposing details of a 0-Day vulnerability, but I strongly believe this could have been responsibly disclosed without imposing unnecessary risk to the vendor and their clients. It is also my belief that consumers should have been advised to shut down all public access to the servers as soon as the vulnerability became known.
Principle of Least Access
Continuing that thought —why in the hell were all of these on-prem servers exposed to the internet, to begin with?
One of the first lessons I learned in information security was the principle of least access. Why is such a simple principle constantly ignored, overlooked, and dismissed?
Let’s go back to SolarWinds attack again. As I’m sure you’ve all heard me mention before, if those servers did not have untethered access to the internet, the secondary payload could not have been deployed. The same thing is true for Kaseya here—if these VSA servers were not exposed to the internet, the exploit would have never occurred.
I’m sure folks will be saying, “But most of these VSAs were managed by MSPs. How are they going to remotely manage without access?”
The answer is simple. Utilize allow-listing with known MSP IPs, or put it behind a properly secured VPN.
This was a spray-and-pray attack that hammered all publicly available Kaseya VSA environments. An ounce of prevention would have gone a long way here.
My message is simple. Stop putting systems on the internet if it’s unneeded, and stop giving all systems untethered access to the internet!
What Else Can You Do?
Zero-day vulnerabilities are here to stay, so you might as well get used to them.
So far in 2021, there have been 33 zero-days exploited affecting multiple operating systems and multiple platforms. To compare, there were only 25 in all of 2020 and only 20 in 2019.
Luckily, as long as you cover the basics, you can help protect yourself against these attacks.
- Don’t expose unneeded servers, applications, ports, etc. to the internet.
- Don’t allow untethered access to the internet.
- Airgap your backups.
- Apply MFA to all publicly available services.
- Train your employees on how to identify an attack.
- Train your employees on how to report an incident.
- Curate a culture that rewards employees for sharing information.
Nailing the basics will take you a long way in security in general.
One Final Note
I must give some very solid kudos to our friends over at Huntress Labs.
They truly did fantastic work throughout this case and have put together a wealth of information regarding IoCs and exploit details.
Below are links to their Reddit thread and Exploit PoCs for reference:
If you feel your business is being impacted by the Kaseya incident, PrintNightmare, any other zero-day vulnerability, or if you’d simply like assistance in improving your incident prevention, detection, and response capabilities, please feel free to reach out to us at [email protected]. We’re happy to help where we can.
Oh, and here’s a fishing picture… just to continue the theme.