The Kaseya Attack: What We Know Now
July 26, 2021 • RBS
July has been a tough month for global IT infrastructure provider Kaseya. If you haven’t heard, Kaseya has made headlines for experiencing one of the largest criminal ransomware attacks in history. Check out our article, The Kaseya Attack: Everything to Know for a full detailed account of what happened, who’s affected, and our theories on how the attack may have happened.
Since the publication of our original Kaseya dissection, new details have provided deeper insights into the attack in addition to Kaseya’s internal security practices.
The Kaseya Attack: Why Did This Happen?
In our previous write-up, based on the limited information available, we were able to piece together the basics of how the attack took place. But some of the exact details of the attack, including the time it took to breach Kaseya, were not yet known. Now, new findings from SophosLabs reveal that the attacks occurred on July 2, 2021 at 8:47am:
It took under two seconds to wreak havoc on potentially over 1,500 global businesses and millions of individual systems. This revelation seems to strengthen our initial theory of how the threat actors discovered CVE-2021-30116, the vulnerability exploited in this recent hack. It also makes us reflect on Kaseya’s earlier statements, in which they cited the incident as “sophisticated”. The new information provides context that it was actually quite simplistic. It reminds us of a time not so long ago when it seemed like companies were consistently blaming data breaches on APTs, since everything was so Advanced and so Persistent and such a Threat what else could have been expected. In this case, those words have been replaced with “sophisticated”.
Deflecting Responsibility with Sophistication
According to DIVD, the proof of concept for CVE-2021-30116 is simple to understand. However, this contradicts the Kaseya advisory where they described the incident as a “sophisticated cyberattack”. That description appears ten times in their advisory. But if you consider DIVD’s professional opinion, our outlined history of documented supply chain attacks, and the new details on the attack itself, “sophisticated” may not be the best description. Even if it was, it doesn’t excuse what happened. But when this attack, as well as every so many others we hear about, is described as “sophisticated”, we have to ask, “is it really?”
When organizations are hacked, there is a tendency to position the incident as unavoidable, as Kaseya has done in this case. Hundreds of high-profile compromises including the previously mentioned RSA Breach have been called sophisticated, often with colorful modifiers such as “extremely sophisticated” or “sophisticated state hackers”. Yet after the RSA hack, Timo Hirvonen said it “wasn’t particularly sophisticated” and he was the one who performed an external analysis of the incident!
Wait, this sounds eerily similar:
Defaulting to such terminology has become a common way for companies to deflect responsibility by essentially suggesting “no one could have stopped it”. If these attacks are simple to execute, then it means unsophisticated attackers are pulling off incredibly damaging attacks. But if these claims are correct, then it means even the largest companies stand no chance in the face of seasoned attackers. So we must ask if Kaseya truly thought the attack warranted the description, or if this is a classic example of deflection.
Alleged Track Record of Irresponsibility
Newly introduced discoveries about Kaseya’s own security imply that their advisories and press releases have been another case of passing the blame. DIVD’s description includes glowing praise for Kaseya:
“During the entire process, Kaseya has shown that they were willing to put in the maximum effort and initiative into this case both to get the issue fixed and their customers patched. They showed a genuine commitment to do the right thing.”Victor Gevers, Chairman and Head of Research at DIVD
On the other hand, Ryan Gallagher and Andrew Martin’s article for Bloomberg stands in stark contrast. According to Bloomberg’s investigation, many Kaseya employees had addressed their concerns to upper management over the past four years and were let go as a result. One employee even provided their own version of the “95 Theses”, writing a 40-page memo highlighting their security concerns. He was fired two weeks later.
Many employee concerns involved issues that were exploited in the recent Kaseya attack. One of those fired employees also even went so far as to say that VSA “was so antiquated and riddled with problems that it should be replaced”. At the time of writing, our VulnDB(R) offering now has tracked at least 76 known vulnerabilities in Kaseya’s VSA product. Out of those vulnerabilities, only 10 have CVE IDs assigned.
Several vulnerabilities in VSA patched this year could have also led to a full compromise if left unpatched. Those vulnerabilities include:
|VulnDB ID||CVE ID||Description|
|260777||CVE-2021-30117||A SQL injection vulnerability|
|260776||CVE-2021-30121||A local file inclusion vulnerability|
|260774||CVE-2021-30118||A remote code execution|
Why the Kaseya Attack Will Likely Happen Again
At this moment, patch 9.5.7a has brought all VSA SaaS customers back online. But even if VSA servicing returns to normal, it is not clear if or when Kaseya will put this situation behind them. One thing that is certain is that this will not be the last attack of this type or scale, whether it happens to Kaseya or a similar organization. How could we say that? Well…
1. This is not the first time Kaseya have been hit by ransomware
Evidence that a similar attack could happen again is that the REvil attack was not an isolated instance of when VSA software was used to push ransomware. Back in 2019, Kaseya VSA was used to execute Gandcrab ransomware.
In that attack, an affected MSP customer had nearly 2,000 systems shut down. The cause of the compromise was traced to a vulnerable plugin for Kaseya’s VSA software. Since that attack, Gandcrab had disbanded due to increased attention and shut down their websites.
Several sources state that there is a high possibility that the Gandcrab team regrouped behind REvil. However, even if the developers are the same people, it’s important to note that the “affiliates” who selected the targets, launched the attack, and negotiated the ransoms of the Kaseya Gandcrab event are not the same as this recent REvil attack.
2. Breaches can be profitable on both sides
Obviously, breaches are profitable to attackers. But while Kaseya isn’t likely to pay for a questionable decryptor on behalf of their customers’ customers, it is also folly to think the 1,000+ downstream impacted parties would collectively come together to raise the $50 million amount. Regardless, if even a small percent of the downstream customers choose to pay a nominal amount for a decryption key, this will most likely be a profitable attack.
Instead, a more interesting view to consider is, “are breaches profitable to the breached company?” Ycombinator user “genmud” offered an interesting view on the topic:
It may be easy to dismiss this as a joke but this kind of math can influence decision-making. If security teams are unable to demonstrate how the investment in new or improved security initiatives will benefit the company, it is unlikely resources will be allocated to the project.
However one aspect is demonstrably false. Cyber insurers can lessen the financial blow brought on by breach by covering unexpected costs like outside response assistance, legal fees, and yes, even payment of a ransom demand. But no insurer will pay “for your technology/security program” or repair the damage to the company’s reputation.
Any Silver Linings?
Aside from the doom and gloom of these cyber-extortion-ransom-threat-attacks, are there any silver linings?
We generally don’t associate crippling computer attacks against large organizations with positive things, but Halvar Flake brings up an interesting point. He points out that ransomware gives a direct correlation between vulnerability and “concrete economic cost” that may “be good for improving security in the long run“. This is an interesting point and speaks to the economics of vulnerability, rather than the vulnerability market.
Given the rapid adoption of cyber insurance over the past 10 years, these ransomware incidents have already re-shaped some of the assumptions used by actuaries at insurance companies. As ransomware events continue to occur and the average cost of ransomware incidents jumps considerably, the associated insurance premiums will rise as well – a trend that is already playing out in the industry. Will that in turn lead to higher underwriting requirements, or companies forgoing such policies due to the cost? We have been talking about cyber insurance and issues with policies for years, in particular the pricing!
The final silver lining, that we have been hoping for after every single big incident and specifically a systemic cyber event, is will this be the wake-up call? What will it take for organizations to examine their security budgets and protocols to determine if they need enhancement? If a $70 / $50 million MSP ransomware incident isn’t it, we’re not sure what is.
Possible Targets for the Next Big Attack
After the high-profile compromises of SolarWinds and Kaseya, along with smaller MSPs like TSM Consulting, threat actor groups are certainly going to keep targeting these types of companies. These attacks will likely continue as companies like SolarWinds are still getting hacked. Injecting themselves into the supply chain clearly yields great results in the far-reaching impact of compromised systems as well as the ransom potential.
That prompts us to wonder which companies might have targets on their backs. Instead of speculating and listing specific companies publicly (which is very tempting), consider the following types of organizations that produce:
- Managed Service Provider (MSP) software products
- Remote Monitoring and Management (RMM) software
- Unified Endpoint Management (UEM) solutions for desktop and mobile
- Automation and Orchestration products considering the privileges required and functionality, it could be a devastating vector
- On-prem software that offers remote computer management for desktop and mobile
- Remote IT infrastructure management software
- Software in previously mentioned categories that have been previously compromised
- Software advertised with statements such as “keep your business secure“, “high-quality remote security” or “unbreakable“
The list could continue, but what’s likely next after that? How about mobile device management (MDM) software or services, since every phone is a viable target for ransomware? What will an organization do when both desktops and mobile devices are locked? With some solutions offering RMM for both desktop and mobile in a single solution it’s a matter of “when” this happens, not “if”.
Avoiding the Threat Intelligence Trap
Trust is an integral part of security. We live in a time in security where supply chain attacks using automatic updates are treacherous, and history shows organizations are not the best at patching. As a colleague framed it:
“If auto-updates are an unacceptable risk because patches are always applied, and manual updates are an unacceptable risk because patches are never applied, well what then?”
The Kaseya attack has revealed uncomfortable truths about the software and processes we often take for granted. It often takes an eye-opening event to expose how intertwined we all are to one another and it doesn’t matter what country we are in, what industry we are in, or the size of our organization. Will the Kaseya hack finally be the straw that breaks the camel’s back?
With Biden’s new cybersecurity executive orders, and a “red line” stance on cyber attacks from state sponsored actors, it appears that it possibly could be. But as new details emerge and security buzzwords are thrown around, regardless of whether they are accurately applied, we need to be careful that we don’t fall into the threat intelligence trap. If we can’t correctly identify what and how it happened, who was affected, and what a supply chain attack actually is, as an industry we cannot move forward to fix the problems.
Instead, we may try to fix the wrong things, or convince ourselves that nothing could have been done. However, something can always be done. Let’s start by making sure that we and the people we do business with take security seriously.