Is Cloud Automate (aka Hosted RMM) more secure? In light of the recent ScreenConnect vulnerability, ConnectWise has touted the security benefits of using their cloud-based products. The software and features are approximately the same no matter the hosting configuration (some space restrictions notwithstanding), so ultimately, the hosting decision is a business decision.
However, when it comes to security, you can achieve more comprehensive security controls with an on-premise Automate deployment. While we can still leverage reverse proxy and WAF technology to secure Cloud Automate, there are problems with enumeration and surface area that cannot be fixed without controlling the underlying infrastructure.
Background: Cloud Automate architecture
When we discuss security, we need to know what exactly we’re securing. Cloud Automate is different from a traditional SaaS platform (like the cloud version of ConnectWise PSA/Manage or ScreenConnect) that are multi-tenant. Cloud Automate is a single-tenant instance of the application hosted on an EC2 instance in AWS.
This is an important distinction, since it changes the security paradigm. With other SaaS applications, there’s a single application instance that is covered by multiple security layers (WAF, failover protections, anti-bot technology, etc.). Multitenancy makes implementing these controls simple and effective, and fairly seamless to the end user.
Since Cloud Automate is a collection of single-tenant instances, these security technologies are absent (as far as our passive external analysis can determine), and it is unlikely that they would be implemented (especially when partners can achieve partial implementation themselves using IP restrictions).
The benefit of Cloud Automate is that the application and server OS patching are handled automatically (and the OS layer security is also managed). While most MSPs can manage a server easily, the outsourced management can be appealing from a business perspective (and is also beneficial for new IT providers who don’t have hosting infrastructure).
We’ve been discussing with several MSPs recently how to balance the Cloud Automate platform’s business appeal with its security implications.
Enumeration woes
The biggest problem MSP tools face is enumeration – the ability of bad actors to discover them. Reconnaissance is the first phase of a cyber attack, and attackers can’t hit a target they can’t see. Since Cloud Automate is a collection of single-tenant EC2 instances, Shodan can enumerate all of them (even if in-app IP restrictions are enabled).
These servers appear when searching for Automate servers in general, but in this instance, we use the certificate name to identify the instances belonging to the Cloud Automate offering:
While improvements have been made in certain hardening aspects (the team at ConnectWise does appear to be trying to improve this), this level of enumeration is certainly undesirable from a security perspective. This is why Cloud Automate instances receive security patches first (often times before the security notifications are posted) – vulnerabilities turn into exploits very quickly, and ConnectWise does this to try and protect this otherwise visible surface area from exploits.
In a similar vein, it’s also possible to enumerate a large number of Cloud Automate servers via typical search engines. About 23% of known Cloud Automate servers appear in a Google search for the domain and default page name:
This area is also improving – we can see that ConnectWise is configuring HTTP headers to deter search engines (on what we’re assuming is a go-forward basis). However, we determined this by analyzing the Shodan data, which is not impacted by the header configuration.
Surface area
In November of 2022, ConnectWise added support for IP restrictions in all versions of Automate, including Cloud Automate. This sounds like a wonderful security enhancement (and we’re happy to see it!), but it’s not the comprehensive security control you might assume it is.
The in-app IP restrictions don’t cover the whole application. The notable outlier in coverage is the agent traffic, which was likely excluded for reasons of supporability. The underlying issue isn’t necessarily the lack of protection for the agent traffic, but the gap it creates with the architecture of Automate.
Automate has a robust integration ecosystem, including plugins. To facilitate plugins that have two-way communication, integrators can have web callbacks to Automate, and those reside in the agent part of the application. These callbacks are used by the ticket sync between Automate and Manage/CW PSA, along with many backup, endpoint security, and other plugins.
Authentication and input validation are performed by each individual integration — which leaves the possibility for various potential attacks if individual vendors didn’t implement security best practices (keeping in mind that some “vendors” might include individual developers who wrote plugins years ago and no longer maintain them). These integrations are not a common point of security research either, so the scenario of a bad actor finding an exploitable flaw in a common integration and attempting mass attacks is entirely plausible – and in this scenario, it would be very difficult to defend Cloud Automate servers apart from patching the vulnerable plugin (something that partners would likely need to do themselves).
Overall security picture
As previously mentioned, hosting is ultimately a business decision that considers more than just security. Each MSP must make an educated decision, considering all factors, when choosing the best hosting model for them.
We write this blog to the MSPs who are on-prem (because that was the best hosting arrangement for their business model) who are led to believe that the cloud variant is inherently more secure. For those on-prem MSPs, better security can be achieved by implementing additional security layers in their existing environment—moving to Cloud Automate would not reduce surface area but rather make it impossible to close.
For any MSPs looking to implement additional security layers in either deployment configuration, we are happy to assist.
