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.

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.

A patched ScreenConnect with other misconfigurations.
This ScreenConnect is patched, so this MSP probably feels safe. However, it’s listening on vulnerable ciphers, discloses lots of information about the server/MSP, and is still enumerable for the next big attack.

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.

This is a real-world Automation Theory reverse proxy. All Shodan sees is an IP, an error message, and a wildcard certificate. Attackers would need to brute-force guess domain names to try and access applications behind the proxy (and get around all the other access controls plus the WAF).

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:

Reverse Proxy and WAF for ScreenConnect.
A network diagram implementing a reverse proxy and WAF for ScreenConnect.

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.

Want to get the latest from our blog delivered to your inbox?

Post Author: Jeremy Oaks

Jeremy is the founder of Automation Theory. He is passionate about all things technology, specifically in developing creative solutions. He received his bachelor's degree in Computer Science from the University of Wisconsin-Superior, and is also a certified MySQL DBA and penetration tester.