If the Kaseya attack was a “supply-chain attack” in terms of the industry accepted definition then it is a stretch of that definition. The distinction is important, because software supply-chain compromises are harder for customers of software solutions to detect using usual defensive measures, and generally involve exploitation techniques that fall outside the scope of web application penetration testing standards. So there is a feeling that essentially no blame rests with the software customer, and perhaps reduced blame rests with the software vendor. In this post we explore the implications for Kaseya of mis-categorising this attack as a supply-chain attack.
How The Attack Was Conducted
The way in which the Kaseya vulnerability was used reflected supply-chain of IT services. It intentionally leveraged the fact that Kaseya is used by IT managed service providers (MSPs) to control a large numbers of computers (laptops, workstations, and servers) across multiple of the MSP’s own customers, in a similar way that Microsoft Active Directory domain controllers, and Azure Active Directory, do. That explains why the Kaseya Virtual System Administrator (VSA) application was a juicy target.
However it is important to recognise that the attack does not appear to have involved any of the characteristics of a software supply-chain compromise as far as the software vendor (Kaseya) and the software customer (the MSP) are concerned. As far as those two parties are concerned, this attack was facilitated via a traditional web application authentication bypass vulnerability, without any exploitation of a software supply-chain being required. The ability to exploit a large number of MSPs was clearly what made this an attractive target, and the impact from exploitation was widespread, again because of the nature of the application and the way in which MSPs tend to deploy it. But that doesn’t make it a software supply-chain compromise.
Why Does That Matter?
We recognise why this perhaps seems to some like a “supply-chain attack”, given that the recent and high profile SolarWinds attack was very much was a classic software supply-chain compromise. The characteristics of that attack, however, can be clearly distinguished from the Kaseya attack. The complexity, time and most probably (state-sponsored) person-hours required to make the SolarWinds supply-chain attack happen are quite different from those likely required in the Kaseya attack.
OK, fine, so what if it wasn’t a software supply-chain compromise? We think it’s important to address this use of the term “supply-chain”, and not let that cloud our understanding what really went on here. Having affected around 1,500 organisations, and perhaps around 10,000 computers, this was one of the largest and most amplified ransomware attacks in history, alongside WannaCry. There are lots of ways to measure and grade attacks, and certainly there have been attacks that have affected more people, and more significantly, and the actual ransom collection from this attack has apparently been quite unsuccessful due to the configuration of the ransomware. But in terms of the effectiveness of the ransomware distribution this was a big one, and it is important to have a clear perspective on how it happened, how it could have been avoided, and where the responsibility lies in high-profile, high-impact cases such as these.
Kaseya’s Response
There has been a lot of focus on the response of Kaseya as an organisation, and the response of MSPs as the customers of the software. The importance of this response is not to be understated, since all software (outside of that used by space agencies for orbital and extra-orbital missions, perhaps) has bugs and vulnerabilities, and no-one is immune from attack – so the quality of response by affected parties is important.
However, in this case we see that almost all of the attention has been on the response, and on the labelling of this as a supply-chain attack, and that seems to miss or at least cloud the more important point.
Web Application Vulnerabilities
The more important point is that these were standard web application vulnerabilities, potentially exploitable by anyone or any system, from anywhere in the world, at least for Kaseya VSA systems that exposed HTTPS to most/all of the internet. There were high severity vulnerabilities discoverable by Kaseya, that probably existed for a period of time before they were alerted to them by Dutch researchers (who discovered them just like anyone else, not having access to the source code or software supply chain, could have). Kaseya were also alerted by Mandiant about another basic vulnerability that had existed in the billing and customer support of their VSA product since 2015, and although there is no evidence that this particular vulnerability was used in this attack, this was another vulnerability exploitable by an unauthenticated attacker that remained unpatched and potentially exploitable from the internet for a long period of time.
At this point we want to emphasise that the way in which the vulnerability was used was quite particular, and certainly contributed to the ultimate success and profile of this attack. It took less than two hours from first exploitation to first encryption of target systems, so this certainly has the hallmarks of a ransomware actor being ready and waiting for some kind of usable Kaseya (and/or other similar application) weakness. The Sodinokibi ransomware, used by REvil in this attack, is state-of-the-art in terms of how it performs its encryption, and the flexibility it provides to its operators (both REvil and its affiliates). In this case it was deployed in what is these days considered a slightly archaic manner, which did not involve exfiltrating data before encryption, or actively attacking data backup repositories and services, so it didn’t turn out to be very successful in collecting ransoms (and REvil has since disappeared from the internet and darknet – a subject for another post). So we certainly recognise that this was an attack that was prepared, ready and waiting to exploit the MSP service supply-chain. But that doesn’t make it a software supply-chain attack, and the implications for the participants are different as a result.
Could It Have Been Avoided?
Kaseya refers to its SOC 2 report and ISO 27001:2013 certification, and to the (at least) annual penetration testing that are required by those sources of VSA customer assurance. Although the full facts are not forthcoming, the assertion that all best practices have been met for an application with this potential security and privacy impact to customers (and customers-of-customers) seems somewhat challenged by the evidence that is available.
Unless this vulnerability was introduced to the platform within the past quarter, which seems highly unlikely given what we understand about the vulnerability (also see this description that Kaseya describes as most accurate), then it should have been detected by a penetration testing programme of the type required for an application with this deployment model and usage profile. Although penetration testing is always subject to limitations, for example in terms of time, budget, testing standard, and the selected level of that testing standard, it is hard to see how Kaseya can have been specifying their penetration testing requirements adequately for this application.
Kaseya obviously became aware of the vulnerability when it was responsibly disclosed to them by researchers (who were of course not employed by Kaseya as part of any penetration testing or security assessment investment by Kaseya). That researchers can find vulnerabilities which a penetration testing programme did not find is not completely abnormal or interesting – those activities have different funding structures, for example. It is excellent that researchers are incentivised to add to the body of knowledge with potentially high impact applications such as Kaseya, and there are of course other more commercial structures, such as through HackerOne, that commercial software vendors can and should use to crowd source vulnerability discovery.
We don’t comment here on Kaseya’s participation or investment in such services. However, it is notable that, although Kaseya was apparently responsive to the responsible disclosure from the researchers, and active in their engagement, they did not actually take steps to alert their customers particularly quickly, and the exploitation was carried out before Kaseya had taken any practical defensive steps on behalf of themselves or their customers.
Conclusion
Any clouding of these facts through the use of the term “supply-chain attack” in the media, or by Kaseya, either actively or tacitly, muddies the waters in a way that misses the opportunity to take useful lessons from this unfortunate event.
We believe that both Kaseya and their customers have some responsibility to consider how and where this software is deployed and configured. Certainly the possible impact from a common web application exploit of a Kaseya VSA server, from anywhere on the internet, is going to be high. Placing Kaseya’s management portal on the “raw internet” is tantamount to putting your domain controllers on the internet. If your domain controllers had super admin access to all of your customer’s computers, that would take on an even more hefty significance, and is something no-one in their right mind would consider doing. Yet, that is how Kaseya VSA is deployed by many MSPs, and the impact of any web application security vulnerability is not difficult to predict.
For now, we leave you with the observation that, whereas cloud-served applications offer obvious and significant benefits, they come with the downside of being attackable by anyone and anything on the internet. This is not true of traditional corporate network designs, where the network border is well-defined and the opportunity to directly attack the assets within that private network is substantially lower. When solutions like Kaseya VSA are deployed with internet-facing interfaces, the responsibilities of the software vendor (and the customer) are greater, and we think that use of the term “supply-chain attack” is both inaccurate and unhelpful to greater understanding of such events, and to improvements in practices that should flow from these.
