News and Notes from the Makers of Nexus | Sonatype Blog

Kaseya ransomware: A software supply chain attack or not?

Written by Matt Howard | July 06, 2021

Following the 4th of July weekend, our industry finds itself digesting the details of yet another large-scale and high-profile ransomware attack. This time it's the exploitation of Kaseya's network monitoring and remote management software. First surfacing on Friday afternoon July 2, 2021, this story quickly spread over the weekend in mainstream media and hacker news sites.

With most Americans now returning from their holiday, we're beginning to gain more perspective on what actually transpired. We’re also seeing an interesting, and admittedly nuanced, debate emerge on whether the Kaseya attack actually qualifies as a software supply chain attack.

NOTE: Kaseya's customer base includes individual companies, as well as a large number of Managed Service Providers (MSPs). These MSPs in turn provide IT outsourcing services to hundreds, and possibly thousands, of downstream business customers that are typically small and medium size organizations with limited or non-existent IT departments (think doctors, dentists, accountants, lawyers, etc.).

What happened?

As reports began to surface of the Kaseya attack, there was initial speculation that the ransomware gang might have gained access to the company's backend software development pipeline, including their build infrastructure. With such access, the attackers could then inject malicious code into the VSA software running on-premises in support of Kaseya business and MSP clients. In other words, the expectation was that the bad actors might have exploited Kaseya in the same way SolarWinds was exploited.

However, we now know that Kaseya was not the same as SolarWinds. Instead, the Kaseya attackers exploited a never-before-seen, or zero-day, security vulnerability (CVE-2021-30116) in the Kaseya software. The newly discovered vulnerability, initially known only to the attackers, allowed them to exploit the on premise version of the Kaseya software, and ultimately conduct the ransomware attack. And, because so many of Kaseya's customers are MSPs, the attackers were able to pass the ransomware attack downstream to as many as 1,500 small and medium size businesses who outsource everyday IT functions.

According to the incident report published by Kaseya, "the attackers were able to exploit zero-day vulnerabilities in the VSA product to bypass authentication and run arbitrary command execution. Although this exploit path allowed the attackers to leverage the standard VSA product functionality to deploy ransomware to endpoints, there is no evidence that Kaseya's VSA codebase has been maliciously modified." In other words, the attackers did not poison Kaseya’s software using the same method as the SolarWinds attack (e.g. by compromising the upstream build process).

Software supply chain attack or not?

Earlier today I began seeing posts from respected colleagues on LinkedIn and also some Tweets suggesting that certain people did not consider Kaseya to be a software supply chain attack.


Twitter user Eloy asks if it’s a pre-auth RCE vulnerability.


Twitter user Oleksy references example of a downstream target.

Having followed very closely the evolution of software supply threats for the past six years, here's my two cents on the debate. I believe there are different types of "software supply chain attacks" including those that target:

  1. Upstream open source dependencies (event stream, octopus scanner/netbeans, name space confusion, etc.).
  2. Upstream build infrastructure (SolarWinds).
  3. Upstream update mechanisms (NoxPlayer).
  4. Upstream MSPs and their apps of choice (Kaseya).

Indeed, while there are different paths from which to exploit software supply chains, they all have one thing in common: all attack vectors are aimed at upstream targets for purposes of scaling downstream exploitation.

So on one hand, Kaseya was definitely different from SolarWinds. On the other hand, it was also somewhat similar, and both classify as "supply chain" attacks in my mind.

Furthermore, if Kaseya is not a supply chain attack, what is it? It's an external service, that you pay for, that you give (highly!) trusted access to your fleet of computers. Feels like the very definition of supply chain attack to me.

A rising tide continues

For myself and my colleagues at Sonatype, this episode represents yet another incident in a long trend observed over many years: in order to scale exploitation of downstream victims, bad actors are increasingly targeting technology assets and providers that live upstream within the digital value stream. This includes open source libraries, IDEs, build servers, update servers, and, most recently in the case of Kaseya, MSPs.

Although there are many tools designed to protect the perimeter of downstream technology assets, the truth of the matter is this: software itself is increasingly the soft underbelly of digital risk. If the past few months are any indication, we expect that attackers will continue to target upstream software supply chain assets as a preferred path to exploiting downstream victims at scale.

It's time for our industry and cyber defense teams to shift more of their attention left. By working together with our colleagues building code, we can protect the upstream portion of the digital supply chain with the same energy and vigor that has long protected the downstream portion. Simply stated: we need to focus more on building and maintaining software applications that are secure by design.

Key takeaways

  • Speed matters. Because zero-day attacks are constantly getting discovered, being able to move quickly is crucial. This means shifting left in your development cycle, cybersecurity policy, and best practices.
  • Understanding your supply chain matters. Open source and third-party dependencies are a huge part of modern software development. Understanding the provenance and hygiene of these software dependencies is fundamental to good development process.
  • Having fresh software matters. The older your open source dependencies, the more likely they are to have defects (security, architectural, licensing). If you're not updating them regularly, you're falling behind. As we're fond of saying, software ages like milk not wine, so keep it fresh.