This release contains some critical security vulnerability fixes affecting v5.5.7 and earlier. We recommend upgrading as soon as possible. We’ve also issued a patch for v5.4.10.
We have a Knowledge Base Article with additional information, including details about the vulnerabilities and ways to secure your server.
To date we’re not aware of any exploits of these vulnerabilities, but we expect bad actors will analyse the new release in order to determine what vulnerabilities were addressed.
If you have any queries please post them here, or email support. We’ll be monitoring this post and will get back to you as soon as we can.
I’m guessing here, but was the downloads not protected from reverse directory traversal? Like they could download things further up the chain from the executables? If so you should be suggesting rotating server OS passwords and SH admin passwords as well I’d think. Curious on your thoughts.
Did the exploit involving the custom URLs require us to have sent out custom URLs? From what I can understand, it seems the biggest risk with that exploit would have been if they pulled the server keys correct? Are server keys something that can be changed or would that basically require a full reset with deployed clients? I run the Linux Server if that makes any difference.
@realmx2 It is possible that the server’s configuration file could be retrieved. Passwords are hashed so difficult (but not impossible) to reverse, but there are reversible secrets in there. We’ll add guidance to the KB guide as you suggested, but also emphasise the importance of second factor on your accounts just in case.
@Nathan_Kull The exploit did not require the sending out of custom URLs. The server keys being exposed could be an issue if the domain of the server were compromised, but alone are not particularly useful. We’re currently looking into the best way to support changing server keys.
One other thing that could be easily added to the server is a blacklist/whitelist for IP addresses…we know who our clients are, for example, I personally install my clients and they tend to be from office branches with few ip addresses, I have a few individual users with IPs that could change, adding a blacklist/whitelist would probably help weed out rogue connections? It’s easier to do it on the server that dealing with the firewall, in my opinion.
@Marco_Ferrante Thanks for the suggestion. We can add a firewall-like service to the server to disregard queries from unapproved IPs. Our thinking has always been that this is better handled at the firewall level as SimpleHelp needs to accept connections in order to determine if they can be ignored (increasing the attack surface).
Regardless, your comment about it being easier to manage in application is true and an extra level of security is always welcome.
Remote Support
Remote Access
Monitoring and Management
Presentation
Remote Work
Standard
Business
Enterprise
that is nice to know that the software is audited by a 3rd party.