At a glance… 

• Kaseya VSA is used by IT organizations and many Managed Service Providers (MSPs) to track IT assets and to deliver software installations and patches to a network of endpoint nodes.  
• Over the 4^th of July weekend, a ransomware attack perpetrated by the REvil gang and its affiliates was delivered through the Kaseya VSA remote management software.  
• Each Windows node on the network runs a Kaseya agent, which is responsible for downloading and installing patches and software packages from the VSA server. It is common practice for an MSP to use a single VSA server to manage all of the MSP’s client networks, meaning that one compromised VSA server can create a downstream impact on hundreds of individual businesses. 
• 1,500 businesses may be effected. 

The fascinating anatomy of the hack 

REvil’s successful hack began with an SQL injection attack against the VSA server. The attacked VSA servers were exposed to the Internet, presumably to allow for remote access to the VSA server by an MSP’s employees. An SQL injection attack was crafted by the hackers to (a) bypass authentication, (b) upload a file, and (c) inject a command to distribute a malicious software patch. This software patch was then dutifully downloaded by Kaseya agents installed on Windows endpoints attached to the compromised VSA server. The technical details of how this was accomplished are explained quite clearly in this article by Sophos. 

The hack itself is fascinating from a technical perspective in multiple ways. First, an authentication bypass renders an entire stack of security technology (authentication providers and MFA) entirely irrelevant. There is no password guessing or credential stealing involved in this attack. Second, the MSP model where client networks are intermingled in a single VSA instance is inherently dangerous in that a single compromised server (whether it be a via a 0-day exploit or a more traditional stolen credential) can spread malicious software across many disparate organizations, geographies, and networks. Third, it is perturbing that a piece of software like the VSA server was directly exposed to the Internet. The lack of any intervening, independent authentication (e.g., a VPN or IIS authentication using certificates or Kerberos) places an inordinate amount of trust in the security architecture of a single piece of software (the VSA server). 

In general, the best way to mitigate hacks of all varieties is to apply a few principles: 

1. Keep independent networks as separate as possible, and always require authentication to move between them. 

2. Authenticate users and devices in layers that rely on disparate software stacks. Software is built by humans, and humans make mistakes that cause security vulnerabilities. Using independent software stacks to layer together multiple forms of authentication ensures that a hacker has to find multiple, independent mistakes that are exploitable in conjunction. 

3. Because there is still no perfect way to prevent endpoint attacks from happening, effective endpoint protection is essential. The Kaseya exploit relied on anti-virus exceptions on the endpoint to allow a malicious file to be downloaded, decoded into an executable, and run via a shell command. This malicious executable then executed a side loading attack to actually launch the encryption process. Effective anomaly detection could have shut down the encrypting process before it got too far, and an alternative approach to using an anti-virus exception would have stopped the attack when it tried to execute the downloaded executable. 

A collective reconsideration of how we protect networks and endpoints is overdue 

This latest attack from REvil confirms the obvious – the business of ransomware is here to stay. Whether it is REvil, a spinoff from REvil, or an entirely new organization that is inspired by REvil’s success, a collective reconsideration of how we protect networks and endpoints is overdue. It has become standard practice to disable security software in order to enable functionality, rather than demanding the opposite – that software declare its intended behaviors in order to enable security software to detect anomalous behavior. 

A system of specific access vs. access to the entire network 

Our LINK system is architected with this last principle in mind. Rather than assume that all mobile devices need access to the company network (e.g., via VPN), LINK assumes that only a small number of applications and data repositories should be mobilized. To configure LINK, IT specifies exactly what intranet applications, email servers, and file repositories (Document Management Systems, One Drive, SMB shares, etc.) should be accessible from a mobile device, and this specification is role-based so that IT can take a pessimistic approach to mobile access (i.e., you can’t access anything unless permission is explicitly granted to you). LINK also uses multiple, independent layers of authentication – SSL certificates to authenticate the device, then traditional password-based authentication if the SSL authentication succeeds. Finally, each LINK installation acts as its own certificate authority for the purposes of SSL authentication. Hence, stealing a certificate for one installation does not grant access to any other installations. 

As we expand LINK beyond mobile, our goal is to promote a different approach to endpoint computing. This approach starts with the idea that users, applications and data need to be integrated explicitly, rather than implicitly. This creates a work environment that is easily encapsulated, encrypted, and protected with limited entry points and exit points to move data in and out of this environment. While no approach is perfect, the more explicit we are about how users, applications, and data interact, the better chance we have to stop the ransomware business before it expands any further. 

-Seth Hallem, CEO & Co-founder, Mobile Helix