In light of the critical vulnerabilities (CVE-2024-1709 and CVE-2024-1708) impacting ScreenConnect, we wanted to get information quickly posted about security options for ScreenConnect. In this post, we’ll review the benefits and common issues associated with using a WAF for ScreenConnect.
Note: If your ScreenConnect isn’t patched to 23.9.8.x or above, stop everything and patch immediately.
Background: Protecting MSP tools in a zero-day world
We’re currently watching what is likely the fastest attack on MSP applications ever witnessed. In less than 48 hours, the situation has escalated from a security notification to in-the-wild exploits. We call this phenomenon (and the related chaos) the “zero-day world” here at Automation Theory.
It’s becoming increasingly clear that leaving MSP tools behind a regular firewall connected to the Internet is a bad practice. That allows IoT scanners like Shodan to enumerate the application’s details – and reconnaissance is the first step in an attack. A good defense requires more than preventing enumeration – but as the old quote goes:
The wise warrior avoids the battle.
― Sun Tzu, The Art of War
The other thing to note is that attacks are against the applications themselves. It doesn’t matter how good your authentication is or how stringent your conditional access policies are if you’re trying to defend against an authentication bypass. Your other security layers need to be able to compensate for a failure in one layer – and for years, the guidance for MSPs has just been to harden authentication. You need more in the zero-day world.
WAFs for the win: a reverse proxy and WAF strategy for ScreenConnect
A reverse proxy sits between clients and web servers, facilitating many functions, from logging to load balancing. However, they can provide several security functions, including custom access controls, GeoIP restrictions, communication hardening, and deep inspection with a WAF.
At the reverse proxy layer, we can implement access controls that:
- Block scanning by IP
- Create GeoIP restrictions
- Granularly restrict access to the entire application by IP
- Require additional authentication methods (like URL parameters or certificates)
- Enforce company security policies, such as requiring specific browsers or clients
- Allow granular access to APIs based on identification headers
Those controls will prevent enumeration, reduce the attack surface, and counter many common attack tactics, techniques, and procedures (TTPs). This security strategy pulls from the MITRE ATT&CK® framework and is much more robust than the current industry “MFA, patch, and pray” attitude.
A WAF adds to these controls deep inspection of the payload. It looks for things like code injection, XSS, file inclusion attacks, and malformed and known bad requests. This includes:
- Inspecting requests for embedded code
- Validating protocols and request types
- Blocking known bots, scanners, and attack frameworks
While the feature list doesn’t seem flashy, there are only so many valid syntaxes for various attacks and only so many ways to try and obfuscate it. A WAF scanning for the common known-bad TTPs makes using the mass-produced hacking tools hard, and it’s unlikely that you would be faced with an attacker that would custom-develop an attack module for the small number of instances that don’t work with the existing ones.
Putting the layers together
This means that (for a typical MSP) if a targeted attacker were targeting your MSP, they would need to:
- Create infrastructure to launch an attack from inside the country
- Determine the FQDN of your application (since IP-based access is blocked)
- Maneuver around your custom access controls
- Which might include IP lists, browser requirements, or client certificates
- Launch an attack via tools that the WAF is unaware of
- Encode a malicious payload in a way the WAF can’t detect
While not impossible, that is a very tall order.
Some assembly required: implementing a WAF for ScreenConnect
What isn’t apparent about ScreenConnect is that there are two network services that share the same FQDN – the web interface for the UI and integrations and the relay traffic that the remote devices use to communicate with the server. Typically, the web traffic is on 8040/TCP or 443/TCP, and the relay traffic is on 8041/TCP (but the ports are customizable, and we’ve seen all sorts of variations).
The relay traffic shouldn’t be proxied – it’s a proprietary protocol that can’t be scanned, it’s encrypted at the application layer, and the connections are always open (which is why ScreenConnect is so fast). You can try to proxy this traffic, but it is typically a painful experience.
The network architecture should look something like this:
We hope this has been helpful to you – if you have any questions, please don’t hesitate to contact us. You can find more details about our proxy service here.
