Recent world events lead many to conclude that cyber-attacks may be imminent for many countries, and protecting Connectwise Automate from such attacks is on the mind of many MSPs. Below we discuss some background on the threat, and what MSPs can do to defend ConnectWise Automate in a cyberwar.
Cyberwar: Are MSPs a target?
As defined by Wikipedia, cyberwarfare is:
the use of digital attacks against an enemy state, causing comparable harm to actual warfare and/or disrupting the vital computer systems.
The general idea is that attacks on the underlying computer systems can cause damage to infrastructure (electrical grids, water supply, etc.) or transportation, financial, or communication systems — and this is common knowledge. What makes MSPs a target specifically for war (not necessarily a ransom) would be the wide adoption of managed IT services, and the disruption that can be caused via MSP RMM systems.
With attacking a single MSP, it’s possible to disrupt multiple sectors very easily. An MSP may have local financial, municipal, and industrial clients under management. History from other ransomware attacks against MSPs bears this out; looking at the financially motivated Kaseya attacks last year many localities saw disruption in critical systems. The Colonial Pipeline attack (not MSP related) also demonstrates the downstream impact that cyber attacks can cause in terms of public panic. The disruption and panic are both things an attacker would want to cause in a war, and this makes attacks against ConnectWise Automate very likely in a cyberwar.
Cyberwar: What are we up against?
Here at Automation Theory, we know our reading audience is international. We’re writing this from the United States point of view, which may apply to other countries as well.
A quick search of news sources would quickly show that we’re expecting cyberattacks from Russia — and we have a long case history of attacks from that region of the world (including the aforementioned Kaseya VSA and Colonial Pipeline attacks). Historic attacks can’t be linked to state sponsorship, but there have been documented cases of Russia using cyber attacks against other countries as early as 2007, so we know that attacks can come from both state actors and 3rd party ransomware gangs.
From the attacks against Kaseya VSA, we can see the technical caliber of the bad actors. The CVEs were for credential leaks/flaws, 2FA bypasses, and XSS. These were of course underlying implementation flaws of the Kaseya software, but it demonstrates that MSPs aren’t trying to defend against script kiddies, but rather well-trained and well-funded attackers, who potentially have undisclosed zero-day flaws lying in wait.
How to defend ConnectWise Automate in a Cyberwar?
MSPs have the unenviable task of playing defender against a more powerful opponent. However, the laws of technology don’t change, and it’s quite possible to create strong defenses. A lot of these practices come down to tried-and-true security basics, but since MSPs may be front-line defenders in international conflicts, we believe they are worth repeating.
Restrict Automate Internet surface area
The first step of an attack is enumeration — the attacker must find the target. A quick search of Shodan for one part of the Automate web UI returns 241 results (165 in the United States). If a zero-day is discovered, any Automate instance discoverable on the Internet is a prime target. We recommend implementing GeoIP restrictions for connections coming in to Automate, and using access control techniques (such as a reverse proxy) to limit what parts of Automate can be accessed over the WAN. Blocking access to sensitive parts of the application via a proxy can prevent exploit in certain scenarios, even if the application is vulnerable to a zero-day.
It’s also recommended to disable plain-text HTTP connections to Automate and to harden the TLS cipher suites on the server. It’s also worth reviewing the inbound NAT rules to Automate; unless legacy redirectors are used the only ports that need to be open to the internet are 443/TCP for the agent web traffic, and 75/UDP for the agent heartbeat.
We’d also like to call out that port 3306/TCP (MySQL) and port 12413/TCP (CWA File Service) should NEVER be open to the WAN.
Harden the Automate server
Hardening the operating system of the Automate server is something that should be normal practice, but unfortunately, it is not. Last year some suggestions were provided to partners, but they were lacking in some areas — and MSPs are needing to protect against highly skilled and well-funded attackers. For a more robust hardening, we recommend the open-source project HardeningKitty. It is a PowerShell script that can apply CIS, DoD, Microsoft, and other security baseline standards to a machine. It can also run in audit-only mode, and create backups of the impacted registry keys. Please note that the aggressive templates can cause issues, and even the default template will disable RDP and create deny rules in the Windows Firewall for SMB — so good backups are highly suggested.
Additionally, we suggest moving the Automate server into an isolated network segment. Internal network security for Automate is worthy of separate treatment, and we have a blog post (complete with hacking demo) here.
Keep secondary components patched
Automate as an application runs an IIS server, with a MySQL database. IIS patching happens with Windows Update, but MySQL patching requires manual intervention. From the trends we’ve seen among MSPs using Automate, the average MySQL install is several years out of date, and on average has 468 known vulnerabilities (and that’s excluding the MySQL connectors, which have vulnerabilities too). Often vulnerabilities are chained together to attack a system, and reducing secondary vulnerabilities can prevent exploitation in certain circumstances.
Upgrading MySQL can be a challenging task, and here at Automation Theory we’re certified DBAs, and we can typically upgrade MySQL in 1-2 hours as a part of our MySQL Maintenance Plans.
Create access choke-points
Most high-security facilities have fixed ingress/egress points (where guards, gates, man traps, etc. are installed). This makes it easy to apply security layers and maintain control, and it’s typically cost-effective as well (not to mention very secure).
The same choke-point style access can be achieved with Automate. Technical implementations can vary, but the idea is that all users who are accessing Automate must come from a specific set of IPs, and to get onto that network all the security controls must be met. The easiest implementation of this is publishing Automate as a RemoteApp on a terminal server (insert your favorite alternative technology here). The server can be configured with all the necessary security software, and it can be hardened and equipped with MFA on login. From this point, you configure Automate to only allow technician traffic from the TS (via a proxy or IP restriction) and you have successfully created a choke point.
All the access to Automate is thus protected by all the technology layers — DNS filtering, EDR, SIEM, etc., and it also offers the ability to implement DLP and prevent exfiltration (patch report data can be used to attack clients with vulnerable devices!). Nobody can go in or out (except for agent traffic) without being logged, scanned, etc. This eliminates the need to manage the security of every endpoint device staff might be using (and it prevents the accessing of Automate on unauthorized personal devices).
Preparing for the future
While we can’t see the future, the adage “hope for the best and prepare for the worst” would be a fitting approach to take. There are certain aspects of cyberwar that might be outside of our control, but every MSP can take additional defensive measures before attacks occur.
Below is a recording of a fireside chat done with our friends at MyersKing Consulting about protecting Automate from cyberwar. It expands on the discussion above about threats, prevention, and the road ahead.
