MSPs everywhere are concerned about RMM security, and with good reason — cyber attacks against MSPs are increasing. Bad actors know that the RMM system is the entry point to all downstream client environments. This ability paints a large target on any RMM, making them challenging to defend (especially since attackers likely have a more significant budget and resources than the defenders do).
This risk leads many MSPs to implement additional security layers to filter the inbound traffic. We’ve written extensively about reverse proxies (which we highly recommend), but another valuable layer of protection is available: the web application firewall.
What is a WAF?
A web application firewall is an application-layer security tool for a web service. It watches requests and blocks any requests matching a ruleset of malicious behaviors (like patterns for SQL injection or XSS). This filtering can potentially protect applications against zero-day attacks, which makes it highly beneficial for high-value targets like RMMs.
As an example, a simple SQL injection (SQLi) payload might look like this:
' or 1 = 1; --'A bad actor would use this payload to manipulate a web service into sending back all data in a poorly coded application (since 1 = 1 is always true, it would match all records, not just the one requested). This payload would be entered into a web form, a URL bar, or a spoofed application request and executed by the application without proper input sanitizing protections.
A WAF would inspect the inbound request, detect the embedded SQL, and block the request, preventing it from ever reaching the application. Even if the application were vulnerable to injection, it would be protected.
Where does a WAF fit into the security stack?
From an attack perspective, a WAF protects at the delivery and exploitation phases of an attack, as it can block based on characteristics of the request (like a User-Agent of a known exploit tool) or based on the content (like a payload containing SQLi).
From a framework perspective, this is a mitigation measure (Mitre ATT&CK M1050) against exploit techniques (Mitre ATT&CK T1190). In NIST, a WAF would be part of control SA-15 for reducing attack surface, and when combined with proxy layers, can also be used for CM-7 to ensure minimum functionality.
“Attack surface reduction is closely aligned with threat and vulnerability analyses and system architecture and design. Attack surface reduction is a means of reducing risk to organizations by giving attackers less opportunity to exploit weaknesses or deficiencies (i.e., potential vulnerabilities) within systems, system components, and system services….”
SA-15, NIST SP800-53 r. 5
Why should Automate have a WAF?
Besides the details mentioned above about being valuable attack targets, there are other pressing reasons why Automate servers should have WAFs protecting them.
The first reason is the large surface area of an Automate server. It has REST and SOAP APIs, multiple user interfaces, and agent communication traffic. These use different technologies behind the scenes, and such diversity is likely to have more surface area for vulnerabilities than a less complex application. These components are of various vintages and use different technologies — and that complexity can result in security flaws. Security issues have been found and corrected in all application components within the last two years — and scanning for malicious payloads with a WAF provides security above and beyond access controls, which would have left security gaps by themselves.
The second reason for WAF protection is Automate’s unique SQL features. Certain parts of Automate enable direct SQL access, and this (along with other architecture items) results in a lot of SQL surface area for Automate (but that is what gives the application so much automation power — so we’re not going to call it a design flaw). Published vulnerabilities, like CVE-2020-14159 and CVE-2020-15008, show that SQLi is a historic attack method for Automate. We dusted off the research for these vulnerabilities and confirmed that a properly configured WAF did catch our simulated payloads:
Since a SQL injection could allow for a complete takeover of all agents, being able to protect against them is crucial — and a WAF is the most cost-effective way to do this.
Finally, Automate should have a WAF because IIS has no native protections against web application attacks. It wouldn’t be practical for IIS to fill the role of a WAF — but assuming that keeping the Automate server patched (which protects from exploits of IIS) will keep Automate protected is dangerous. Most of the prescribed security guidance for RMMs revolves around the fundamentals of patching, strong credentials/authentication, and reviewing integrations. While these are all important, they neglect that the Kaseya attacks leveraged application flaws, rendering all the other security best practices a moot point. With thousands of Automate servers enumerable on the internet, we believe it’s only a matter of time before similar attacks happen against the Automate platform.
What should MSPs do?
First, we believe education is a crucial step — security begins with an understanding of risk and how to apply mitigating controls. To this end, below is a webinar recording that covers the basics of what a WAF is and how they can be used with Automate:
Beyond that, implementation comes next once a security control decision is reached. Here at Automation Theory, we’ve designed a WAF for Automate. It supports a drop-in deployment model and allows for testing in parallel with production with no interruption. You can learn more and request a trial here.
