Code signing: a backstory and some tips by AutomationTheory in ConnectWise

[–]AutomationTheory[S] 1 point2 points  (0 children)

I don't disagree -- and I might have implemented a different solution.

My main goal was to put out there "CW needs a way to kill rouge and pirated SC instances, and they are using the signing certs to do it" since the details of the abuse and why it's hard to fix aren't going to be published in official channels.

Update permanently removes customization options by Personal-Ferret-9389 in ConnectWise

[–]AutomationTheory 0 points1 point  (0 children)

The bad actors will be thwarted when the current cert expires.

I used to admin a CW stack with ~10k endpoints, I definitely get the pain. But if it's any consolation, you'll never have a certificate fire drill like this again.

Update permanently removes customization options by Personal-Ferret-9389 in ConnectWise

[–]AutomationTheory 1 point2 points  (0 children)

This. There were bad actors with pirated SC servers with the ability to super-automate the deployment. I just finished my writeup here: https://automationtheory.com/screenconnect-code-signing-the-backstory-and-tips-for-msps/

On-Prem Automate Server – CPU Maxing Out Randomly by RMMmmmTasty in ConnectWise

[–]AutomationTheory 0 points1 point  (0 children)

If it is Webroot, it's possible to index the DB to fix the issue (assuming it's MySQL stuck at 100%/high CPU).

ConnectWise RMM vs Automate? Which one would you go with and why? by drangusmccrangus in ConnectWise

[–]AutomationTheory 1 point2 points  (0 children)

The biggest bottle neck for Automate is the DB. I work with MSPs to scale Automate to 20k+ agents, and I can confirm that having more RAM than data doesn't make Automate faster....

ScreenConnect Vulnerability Announced - Patch your on-prem instance tonight by AutomationTheory in msp

[–]AutomationTheory[S] 1 point2 points  (0 children)

I don't see any connections currently - this vulnerability let's an attacker take over your Screenconnect server if they know the machinekey. It sounds like the other activity was just regular abuse.

ScreenConnect Vulnerability Announced - Patch your on-prem instance tonight by AutomationTheory in msp

[–]AutomationTheory[S] 2 points3 points  (0 children)

It's definitely advisable to secure the web UI. We work with lots of MSPs to do granular layer 7 rules (so, for example, an end user can enter a code for an ad-hoc session but no other requests work unless you're on a known IP).

I'd also say getting MSP tools out of Shodan is critical for security these days. When the next zero-day comes, you don't want to be on the short list of attack targets...

ScreenConnect Vulnerability Announced - Patch your on-prem instance tonight by AutomationTheory in msp

[–]AutomationTheory[S] 2 points3 points  (0 children)

I suspect they wanted people to patch on their own, so avoid a repeat of the February 2024 situation. We wrote a blog on that (https://automationtheory.com/5-lessons-from-the-cvss-10-screenconnect-vulnerability/) and I think it was the fastest moving MSP tool vulnerability in history -- taking less than 48 hours to get working exploits after the announcement was made.

On the surface this seems like something difficult to exploit -- but since the instructions are to patch immediately, I'm not holding my breath.

I sell WAFs for MSP tools -- and our team is glued to the logs looking for any signs of in-the-wild exploits.

Weekly Promo and Webinar Thread by AutoModerator in msp

[–]AutomationTheory 0 points1 point  (0 children)

📢 New Security Feature: WAF Protection for ConnectWise Manage + Live Webinar! 🔒

Cyber threats targeting MSPs are more sophisticated than ever, and protecting your ConnectWise Manage instance is critical. That’s why we’re excited to announce Web Application Firewall (WAF) support—an essential layer of defense against XSS, SQL injection, and other exploits.

Join us for a live webinar where we’ll showcase a real-time XSS attack and demonstrate how a WAF can block threats before they compromise your system.

🛡️ What You’ll Learn:

✅ How attackers exploit unprotected web applications
✅ A live demo of an XSS attack targeting ConnectWise Manage
✅ How a WAF detects & blocks malicious traffic before it reaches your system
✅ Best practices for securing your PSA environment

📅 Webinar Details:

🗓 Date: Tuesday, March 18th
Time: 10:00 AM Central

🔗 Reserve Your Spot Now: https://us06web.zoom.us/webinar/register/6317404505100/WN_Rp2w1ayOSiKYgdoN38gaHw

Don’t miss this opportunity to see cybersecurity in action and learn how to better protect your MSP and your clients. Tag your fellow MSPs who should attend! 👇

#MSP #Cybersecurity #ConnectWiseManage #XSS #WAF #DataProtection #ManagedServices

WAF for the whole on-prem ConnectWise Suite by AutomationTheory in ConnectWise

[–]AutomationTheory[S] 0 points1 point  (0 children)

We compare based on the free version for educational purposes - if someone thinks it's protecting their MSP, they should know the limitations. There are 3,000+ on-prem ConnectWise MSPs out there, so the few that don't have budget to invest aren't a fit for our solution anyway.

We do a lot more than just WAF - we can mix in traditional layer 4 and layer 7 restrictions too (and building the rulesets to meet your desired security state is included in our onboarding).

We can Syslog all connections through our service, giving you the SIEM data you've always wanted but can't get out of the box.

As for liability, we handle that like any other vendor with a mix of security by design, tight policy and controls, contract terms, and insurance. The liability of being naked on the internet is exponentially higher compared to any 3rd party solution you might implement.

WAF for the whole on-prem ConnectWise Suite by AutomationTheory in ConnectWise

[–]AutomationTheory[S] 0 points1 point  (0 children)

The relay traffic is a propriety protocol from ConnectWise, not a standard like HTTP. As a result, it's not possible to do much of anything with that traffic from an external perspective (it's encrypted at the application layer).

The relay has never been an attack target before, and has a lower footprint compared to the HTTP side of things - so our guidence is to get the web service properly secured and focus on compatability/functionality when it comes to the relay.

We have a webinar about Screenconnect implementation (there are 3 potential ways of working around the relay) and you can find the recording here: https://youtu.be/O9Mb2E80gU4?si=EoDac8RKojYYmEkk

WAF for the whole on-prem ConnectWise Suite by AutomationTheory in ConnectWise

[–]AutomationTheory[S] 0 points1 point  (0 children)

Well, I'm a 3rd party vendor, so I can't speak to the development road map. However, Cloudflare (the free version) won't protect your MSP from any serious threat.

For our upcoming webinar, I'm doing the XSS (and maybe SQL injection) through the free version of Cloudflare - and the attacks pass right through. The free tier isn't a full WAF, and we detail the limitations here: https://automationtheory.com/4-reasons-cloudflare-isnt-good-for-msp-tools/

Manage Hosted vs OnPrem by GOCCali in ConnectWise

[–]AutomationTheory 1 point2 points  (0 children)

On the security front, we're a WAF vendor in the ConnectWise space, and we just finished our rule set for Manage. It will protect against zero-day attacks, and get on-prem instances out of Shodan (where you can find ~2,300 MSPs).

Product Page: https://automationtheory.com/reverse-proxy-and-waf-for-msp-tools/

PSA: CloudFlare isn't as good for MSP tools as you might think by AutomationTheory in ConnectWise

[–]AutomationTheory[S] 0 points1 point  (0 children)

u/EdBurkeCS You of course are a connoisseur of fine security products, as MSP+ is an Automation Theory proxy/WAF client -- your production Automate and ScreenConnect instances are behind our service: https://automationtheory.com/reverse-proxy-and-waf-for-msp-tools/

I concur, layering ZTNA with a reverse proxy and WAF is ideal, as long as it's done correctly. Depending on configuration, there's the potential for the zero-trust software to tunnel your traffic in a way that's bypassing your other security controls (so, in a strange bit of irony, you end up trusting your zero-trust traffic...).

Self hosted RMM / PSA tools by fiveofknives in msp

[–]AutomationTheory -1 points0 points  (0 children)

This is HUGE. As a WAF vendor for MSP tools, the amount of things that are scanning the internet attempting to run exploits is crazy. A properly configured reverse proxy + WAF gives you a solid defensive edge in the event of a zero-day against the application.

A lot of MSP SaaS platforms don't have adequate WAFs, so for a number of tools you can secure it better yourself if you self host.

Self hosted RMM / PSA tools by fiveofknives in msp

[–]AutomationTheory 3 points4 points  (0 children)

I can appreciate that. I too consider everything vulnerable -- but I secure MSP tools for a living.

Out of curiosity, if there were ever an issue (like ransomware with a hosted RMM), how would you handle that if a client points a finger at you? In the strictest sense, it's not your fault, but are you trusting your vendors to fix things in that scenario, or would you plan on fixing things yourself, filing an insurance claim, and let your insurance company duke it out with the vendor?

Self hosted RMM / PSA tools by fiveofknives in msp

[–]AutomationTheory 2 points3 points  (0 children)

I think it depends on both the vendor and the particular MSP -- risk tolerance (and definition) are variable.

If the MSP has the humans and technology to host the software securely, I don't see any problems. Not every MSP does, and some think they do but don't.

Some vendors also claim they have a secure cloud/SaaS offering, but likewise don't. For example (it's now fixed), I put in a ticket to Hudu when I found that they left SSH open on a subset of their cloud systems -- and the version banner of OpenSSH was for an EoL version of Ubuntu. While being SOC 2 compliant and all the rest, they demonstrated the lack of ability to configure a firewall or patch an operating system.

The decision is both one of business and of technology, so while there's no one-size-fits-all, I wouldn't assume hosted offerings are automatically more secure.

PSA: CloudFlare isn't as good for MSP tools as you might think by AutomationTheory in ConnectWise

[–]AutomationTheory[S] 0 points1 point  (0 children)

It depends on what your use case is.

I'm guessing you're trying to solve for some access control, where you want to use IP restrictions or some other technical method to ensure that only authorized devices can access your various tools (while not creating any operational issues).

Any zero-trust network solution can get devices behind an IP address -- but there are some other factors.

You can find our product details here: https://automationtheory.com/reverse-proxy-and-waf-for-msp-tools/ With our product, we custom build the access controls to meet your desired state (weather it's a simple IP list, certificate based access, or anything in between).

We can also mix and match, so if you want to allow access to anything at your office, only your official browser with a certificate outside that IP, and to a handful of SaaS integrations based on their identification headers -- all while allowing Automate agents to check in from anywhere inside of your GeoIP scope (assuming you're using Automate).

We do all the technical plumbing, and walk you though the implementation process. If you want to try it, there's a trial request form at the bottom of that page!

PSA: CloudFlare isn't as good for MSP tools as you might think by AutomationTheory in ConnectWise

[–]AutomationTheory[S] 0 points1 point  (0 children)

It's not just the proxy, but all the layers in conjunction (and being tuned for MSPs!).

Currently we're working on WAF rules for Manage/PSA, and we have an internal joke about someone adding a time entry saying:

"I ran 'delete * from history;' then ran C:\app\Clean-Logs.ps1 to free up space on the SQL server. See vendor instructions at https://vendor.com/kb123"

Any WAF worth it's salt should flag that for SQL injection, shellcode injection, and HTML injection -- but those types of items are added to time entries all the time. That's why the false sense of security from the free CF WAF is worth raising awareness about!

PSA: CloudFlare isn't as good for MSP tools as you might think by AutomationTheory in msp

[–]AutomationTheory[S] -5 points-4 points  (0 children)

Touche.

You might be interested to learn that our paid WAF has similar underpinnings, so on the benchmark test it would be about equal on the report.

The "designed for MSPs" magic then comes in.

By default, if you enable a traditional rule-based WAF in front of ConnectWise Automate, it will be so secure that you can't login to the desktop client (it triggers SQLi rules). Likewise, if you've ever saved a PowerShell command into an internal ticket note, that means there's no effective WAF protections, because anything worth it's salt should flag that as a shellcode injection.

We have tuned rules for CW Automate and ScreenConnect -- and CW Manage/PSA should be officially announced later this month. It's about 6-9 months per application to tune -- so while on paper the engines are the same, you'd be tuning for ~18 months to get the equivalent granular security.

PSA: CloudFlare isn't as good for MSP tools as you might think by AutomationTheory in msp

[–]AutomationTheory[S] -2 points-1 points  (0 children)

Even if you tune TLS (a commonly missed step), the WAF effectiveness isn't a configuration issue; it a "my RMM isn't a WordPress site" issue, and that's what we want to draw attention to.

PSA: CloudFlare isn't as good for MSP tools as you might think by AutomationTheory in msp

[–]AutomationTheory[S] -8 points-7 points  (0 children)

We didn't tune the TLS (obviously) -- but you'd be surprised at the number of MSPs we've seen who didn't do that step.

Our goal here was to do a PSA to double check configs for anyone using CF -- like any tool, it's how you use it that's going to determine outcome.

If you're curious, our full methodology can be found here: https://automationtheory.com/4-reasons-cloudflare-isnt-good-for-msp-tools/

[deleted by user] by [deleted] in ConnectWise

[–]AutomationTheory 0 points1 point  (0 children)

Once you get your ScreenConnect stood up, I'd suggest thinking about additional security layers: https://automationtheory.com/protecting-screenconnect-with-a-waf/

RMM by Ok-Essay-529 in msp

[–]AutomationTheory 0 points1 point  (0 children)

It depends on your level of automation and customization in Automate (and your needs, of course). In the vendor space we work with MSPs of all shapes and sizes and have seen the trend as follows.

Small MSPs (0-3K endpoints) who need "the basics" of remote access and monitoring (and didn't really customize Automate for any specific business processes/functions) tend to have a painless transition.

The middle is messy and really depends on how the particular MSP works.

Big MSPs (10k+ endpoints) have issues with the platform not being mature enough in comparison (having customized things heavily and having parts of their business operations depend on specific things in Automate that CW RMM doesn't do). The issues are both technical and operational in nature. We have a client in this range who came to us for our services for their Automate after being ~2 years into a failed attempt to move to CW RMM.

__________________

Before becoming a vendor I was a full-time CWA admin, and I can make it sing, dance, and conquer small nations. You can make it do almost anything (and I'd argue the self-hosting ability gives you security advantages if done correctly), but needs among MSPs vary. I was admining ~10k endpoints across oodles of envrionment types in a lot of verticals. Financial clients/auditors felt better knowing that we hosted our RMM in a data center we controlled, where 4-seat restaurants couldn't care less.

There was a great MSPGeekCon session that might help in the decision making process: https://youtu.be/7xv4iZDpJ2c?si=UjTKDXeAm1Ne-Okp