Supply chain attacks exist when a 3rd party’s software or hardware used in an organization’s processes are used to attack it. Because a supply chain attack is launched from a partner or peer, it is often extremely difficult to detect as it is delivered from a trusted channel. Additionally, by compromising a single supplier, the attacker is able to compromise each of its users. With a single well placed supply chain attack, hundreds or thousands of victims can be compromised.
Supply chain attacks are not new - one of the creators of Unix, Ken Thompson, famously backdoored the compiler used to create the login command and the login command itself in 1984. Since then, a number of interesting supply chain attacks have been discovered including the 2011 targeting of industrial control system software by the group ‘DragonFly’, the Target compromise via its HVAC provider, the Elemental hardware ‘seeding’ attack, backdoored open source libraries, and recently the SolarWinds attack where a backdoor was installed in the SolarWinds software itself and pushed to each victim customer via the auto-update functionality.
In this blog, I will use the most recent Kaseya VSA attack as an example of a supply chain attack, and use it as an illustration of why supply chain attacks require special security considerations as well as offer guidelines as to how to protect against these attacks.
The Kaseya Attack
In the most recent Kaseya VSA supply chain attack, the attacker chose to infect each victim with REvil ransomware. Kaseya VSA is a Remote Monitoring & Management (RMM) Software package that is often used by Managed Service Providers (MSP) to remotely manage their customer’s endpoints. As a result, the end victim may have little understanding that they were exposed to the Kaseya vulnerability or its resulting ransomware. When a payload like ransomware is distributed entirely via trusted channels it is particularly difficult to stop.
The Kaseya attack began when an authentication bypass vulnerability in Kaseya’s VSA was used to to upload files, and a third vulnerability was used to execute the command necessary to push the attack files to the VSA child agents and launch the attack. Deployment of the attack payload via a supply chain like Kaseya VSA rapidly amplifies the number of victim endpoints as the attacker does not compromise endpoints individually, but rather compromises one Kaseya server and uses it to push the payload out to all of the endpoints under its control. The attacker went one step further in this amplification in that they set the ransomware payload to detonate at 1630 UTC on July 2 across all victim endpoints.
Protecting Against Supply Chain Attacks
Let’s take a moment to discuss the Kaseya VSA supply chain attack from the perspective of the MSP’s customers and understand what actions they should take to armor against similar attacks. To fully set the stage, let’s say the MSP’s customer did not know that the Kaseya VSA agent was even running in their environment.
The attack would have been first experienced with the 1630 UTC coordinated detonation of the REvil ransomware and the encryption of files. Understanding of the infection vector and containment would have been murky at best. Not a good situation to be in to say the least.
What should have happened prior to the incident is for the end customer to have a comprehensive understanding of their supplier network and all of its suppliers(including Kaseya VSA in this case). The end customer should have a solid understanding of their entire software bill of materials(SBOM) and have regular dialog with its suppliers on current security posture and improvements. Dialog, not dictation, is important here. A component of understanding one's supplier network is reducing it where possible. This is where things get tricky - particularly for high reliability networks, it might be necessary to take actions such as introducing ecosystem diversity into the supply chain. In these situations, it may be necessary for the end customer to use 2 discrete MSP ecosystems so that not all of the high availability systems have the same RMM software on them.
Once the supply chain is well understood and reduced as much as possible, one needs to ensure that all supply chain elements are included in relevant detection and response plans. This is twofold -- first your SOC needs to understand how to threat hunt and investigate threats with consideration of your supply chain, and second, all response plans need to include actions that leverage the full supply chain understanding and relationships.
Interested in how ActZero MDR can help protect you and your supply chain against ransomware and more? Check out our white paper, 6 Steps to Secure Your IT Supply Chain now.