SH Recent Vulnerability Concerns?

Remote Support and Access
1

Hello Everyone…We have a SH server that we always keep up to date with Linux and SH updates. When 5.5.8 was released we updated immediately. We have had an Ubuntu Linux VPS running on Digital Ocean for many years and we have a lot of unattended endpoints that we also updated to 5.5.8. We also have the technician/admin console login limited by a specific IP address and it has been this way for years. MFA is enabled for all tech/admin logins as well. When this was disclosed we immediately changed passwords and refreshed our MFA codes.

Obviously, the discussion of this vulnerability is all over the Internet but the conversation here has been relatively limited. Has anyone noticed any instances where servers were compromised? Is anyone concerned about their own server being compromised? I would like to know if it was possible that our server could have been compromised if we had the IP restrictions above. Indicators of compromise to look for, etc. Obviously, a compromise would be catastrophic.

The SH folks have been great at addressing this issue and the full disclosure but we are concerned and are wondering where other SH users stand.

Thanks
Bob

2

We’ve a list of observations from our ongoing analysis that will be going up on our article (here: https://simple-help.com/kb—security-vulnerabilities-01-2025) soon. These include:

  • Characteristics and potential impact of compromise
  • To to help estimate vulnerability and potential impact;
    • Server configurations that would not have been vulnerable
    • How to determine if remote machines could have been affected
  • Actions to take in case of compromise

We’ve some security enhancements coming shortly as well (password strength requirements for example). Log into your account on our site to opt into the mailing list to be notified of new releases, or keep an eye on: Release News - Remote Support Software by SimpleHelp

3

I’m hoping that soon we will also have the ability to change the security keys? To me, it seems that’s the biggest thing that could have been lifted from our servers with this vulnerability. My key has been around for over 10 years and is still based on the license since I don’t think it was even an option to not do it this way when I first started using it, I’d feel better if there was a way to cycle it.

From what I have seen and understand from various sources about this vuln, it does appear that my practice of always having machine passwords setup on the remote agents (get prompted anytime you try to initiate a remote session, which I believe is prompted by the machine agent itself) would provide some protection even if my key was compromised and traffic was directed to a compromised server.