Simple Help attacked

Server Administration
9

5.2.12 includes a Technician Console timeout option as part of the Technician Group Permissions. It works as follows:

  • It is set in the Session Limits tab in much the same way as the session timeout.
  • Any activity in a session will prevent the Technician Console from timing out.
  • When the timeout is reached the Technician Console shows a new dialog that gives the user one minute to act prior to logout.
4 Likes
10

I agree and have spoken with SimpleHelp support about this before. There needs to be a confirmation prompt to the technician. We have been burn a few times on running the wrong toolbox task.

1 Like
11

When is 5.2.12 expected to drop? Thanks!

12

George said some time next week, hopefully the start of the week.

13

I would highly recommend that the logoff button be moved to the top row where you see remote support, access etc. I have been using Simple Help for nearly two years and never realised that there was a logoff button because I usually never click on that preferences tab.

Sorry you misunderstood me. I don’t recommend removing the ability to deploy scripts etc to say 700 computers. However I think that there needs to be more security steps/confirmation to ensure that you really did intend to run that toolbox to prevent a malware script from accessing the toolbox and running things automatically. Another feature I could suggest would be before a file is deployed to machines it is checked against virustotal.com to make sure it’s not a virus. There are lots of things that can be done to protect against malware scripts, although it sounds to me in this particular case that a human agent manually did the damage.

Thank you for confirming about remote access Service Machines as this was something I wanted to look into. My next step will be to decide whether to have all clients using tcp or udp as the connection.

14

I would like to see the ability to send the logs to syslog (in linux) or event viewer (in windows) or other logging service.
Or even a way to specify they be automatically sent to a rsync or sftp service.

15

Concerning this being on inside job; there are only 5 of us technicians all of which would not have done this. We believe we were likely hit by the same hacking group that hit Argentina a couple days later on 7/18: https://www.zdnet.com/article/ransomware-gang-demands-7-5-million-from-argentinian-isp/

Can someone point me to the specific setting that restricts a tech from running scripts outright? I understand why some of you guys want to run scripts against all Access PCs at once, but this is not a feature that we need.

The tech PC that was hacked was not logged in as SimpleHelpAdmin. I don’t understand how the hacker was able to remove the logs without being a Simple Help Admin. The hacked PC was also outside the SimpleHelp server LAN, so it only had access to Simple Help server via the Simple Help technician client.

We do have nightly backups of the SimpleHelp server. I’ll see if a backup from the night of 7/13 would happen to contain any trace of their activity. If the rogue connection and the deletion of the log file both happened ‘after’ that backup, then they have successfully covered their tracks.

16

You should log in as administrator, click on ‘Groups’ in the administration tab, and then click on the group your techs are in. Then click on the ‘Permissions’ tab on the right, then scroll down to the ‘Toolbox’ section where you can allow tools to run in the access tab, and also whether tools can be run during sessions. 2020-07-28_11-17-30

17

I was wondering if they RDP into the machine running SimpleHelp?

Also do you use 2FA with SimpleHelp and have you limited IP access?

18

Hello Everyone.

We just moved over to SimpleHelp also, We also replaced our firewall with a Sophos XG firewall and going to use GEOLocation Lockdown.

Just thinking it might also be worth updating your Hardware Firewall.

Az

19

I noticed you and @Darrell_Swafford mentioning this months ago, but since the topic has been bumped I really, really third this.

Off-topic: The toolbox is frankly quite dangerous the way it stands, especially as it doesn’t carry over the notes via a tool tip or something. I often go to run something on a machine, hesitate about whether this is the correct tool, and have to go to the toolbox tab to look at the tool/notes and then go back to the endpoint, and I wrote the damn things. My prefered UI would be click the tool > this drops down/reveals a Run button along with the note for the tool if present > confirm that this will be run on $MachineName

If it could have an option to schedule a later time and a “skip offline machine” checkbox that would really make my year.

To be fair to SimpleHelp, Automate/Labtech don’t show the descriptions for the script either and SimpleHelp is definitely far better than anything from CW in terms of UI, but this would be a really important addition.

1 Like
20

Great suggestion for the toolbox. Open a Feature Request ticket about it. I’ve found the developer to be extremely responsive to new ideas/changes/bug reports, with many of my requests ending up in the next released update.

2 Likes
21

The SolarWinds incident alone should highlight the risks with any automated tools.

22

There are risks with all automation. I feel like SimpleHelp has evolved it’s security to mitigate most issues. Provided the end user enforces good policy to back it up.

Never leave the tech console logged in and unattended. ESPECIALLY where the technician app is installed on a mobile device.
Enable MFA.
Never use the primary admin account for day to day.
Enable session timeouts
Make sure the device that is running the technician app is properly protected and secured.

The above is not a comprehensive list of security items but a good starting point.

3 Likes
23

My main client recently underwent a two-day in-depth security review. 52 action points ranging from an hour to months…

25

Rob: Anything of general applicability that might be good for all to think about? :slightly_smiling_face:

26

Yay! I actually do all those things. The session timeouts are a pain, but I set them like that for a reason.

Another thing we practise: If you are on site, never be tempted to use a customer PC for remote support, just because you happen to be in front of it. Use your own laptop or tablet, or nothing at all.

27

Yes - MFA must be available and used on all systems where there is reputational, operational and security risks. A right pain as my main client has identified 150 web based systems already where there may be even a little bit of their clients data.

Many of them don’t offer MFA/2FA so are at risk of being banned. Worryingly, there are several major systems that don’t offer 2FA.

28

Oh, MFA for sure. Was wondering if anything in those 52 action points were suggestions useful for others in general

29
  1. Review all systems from operational, reputational and security POV
  2. Have a business continuity plan for each and actually test it
  3. Train and re-train staff - security is a mindset
  4. Only allow approved software to be installed
  5. Remove access to systems when no longer needed
  6. Implement a password manager to allow you to revoke system access for leavers
  7. Ban USB drives
1 Like