+1
Under Review

Better Security Around ToolBox

Sean Keown 1 year ago ā€¢ updated by swhite (Product Manager) 1 year ago ā€¢ 2

Notice: For anyone reading this I'm recommending that you remove the TransferFilesInSessionĀ permissions and possibly theĀ RunSharedToolInSession unless the user is an IT Admin and is allowed System Rights on a computer.Ā 

IĀ know, this is hard for me too...Ā 

When we first looked at theĀ RunSharedToolInSession permissions we assumed you had to be connected to the session and logged into the server / workstation which made it more acceptable. The good news is that we at least control the SharedToolBox and can remove harmful scripts.Ā 

What I found, is that by giving a userĀ TransferFilesInSession orĀ RunSharedToolInSession you are essentially giving users rights to run scripts on behalf of other users that maybe logged into the system, even whenĀ the screen is lockedĀ or run scripts asĀ the SYSTEMĀ account when no-one is logged into the computer. šŸ˜¬

Ā Meaning users can possibly -

  • Change Local Passwords and or domain passwords depending on who is logged in.
    • It makes you wonder, what's the purpose of locking the machine if someone can just change the password via a batch. šŸ¤·ā€ā™‚ļø
  • Install Software
  • Run Custom Scripts outside the SharedToolBox
  • etc.

The whole purpose of us removing the RunCommandOutsideSessions and SwitchLogonSession was to prevent things from running without someone being logged into the server / workstation. Also hoping this added an extra layer of security incase someone got into someone else's control account meaning users would first have to connect to the server then login again prior to any scripts being executed.Ā Ā 

Ā 


During my testingĀ I tried disablingĀ RunSharedToolInSession and i found out that youĀ can still add scripts to the personal toolbox and execute them even though theĀ shared toolbox grayed out.


Image 1101


To fully disable the toolbox you need toĀ turn off bothĀ RunSharedToolInSession and TransferFilesInSession.Ā 

This is extra depressing because i need my support staff to have the power to transfer files but i don't want them running scripts as SYSTEM... šŸ˜ž

Thinking about hiding the briefcase to prevent the user from using this function? Well that can easily be bypassed too just by editing an xml file, it's all optional on the users end.Ā 


This means ALL USERS that haveĀ TransferFilesInSessionĀ have SYSTEM rights and anyone that gets a hold of their account can abuse control.

Just to clarify this part. (personal opinion)

Essentially giving users rights to run scripts on behalf of other users that maybe logged into the system. --> This part is expected since the computer is unlocked but having the ability to run scripts with the screen locked is not preferred. 

Meaning everyone with TransferFilesInSession permission essentially has backstage access. 

Under Review

Thanks for your report.  I have discussed this with our architecture and information security teams and we agree we should find a way to make the toolbox behavior more predictable and clear especially when it comes to the required permissions. We do require the RunCommandOutsideSession permission to be able to run a tool from the host page, but not from the host client. we also have documented that the shared toolbox requires the TransferFilesinSession permission, and will make sure that we update this for the personal toolbox as well.

note: edited for a typo and clarity