Improve Encryption Security

[DigitalFlow]

Hey there,

This gist shows how to decrypt all encrypted passwords without XrmToolBox. I think we could improve security by using the Windows Credential Manager with a master password which the user has to enter on each XrmToolBox start. This issue will be used as a reference for a PullRequest that I'm trying to create for integrating the Credential Manager.

Kind Regards, Florian

[DigitalFlow]

@MscrmTools I did not find time for fixing this, maybe you can? As it is right now, a malicious plugin can find the connections file on startup, decrypt it and send all passwords to its creator via email, I think this should be fixed asap.

[MscrmTools]

@DigitalFlow I do understand the concern but even if I used a master password, developers will be able to use reflection to extract the password. Or, the master password should be asked each and everytime the password is needed, which can lead to usage issue. That shouldn't be too difficult to add a master password to decrypt passwords in connections file when opening the connection file BUT as said before, that won't prevent malicious code to get the passwords using reflection once the file is decrypted. Any thoughts on my comment?

[DigitalFlow]

As far as my understanding goes, if there is no way of getting a reference to the component which holds the master password, the plugin would not be able to use reflections for accessing its values.

Do plugins get access to the whole main component of the toolbox?

[MscrmTools]

Yes they do. Because it is not possible to have plugins with UI and isolation in different app domain, all code (XrmToolBox and its plugins) are executed in the same appdomain. Therefore, with reflection, they can access anything they want

[lar-mar]

How can we ensure there is no plugin reading the stored connection details and passing them to whatever?

[MscrmTools]

Actually, we can’t. Except reading source code to ensure there is no malicious code included

[lar-mar]

Is every new plugin or plugin update reviewed this way before it is available via pluginstore?

[MscrmTools]

no, it's not. I cannot handle reviewing source code of each and every plugin

[MscrmTools]

I just found this: https://www.azurefromthetrenches.com/capturing-and-tracing-all-http-requests-in-c-and-net/

Maybe I could add a http listener that will warn and block outgoing requests that don't match the current connection for the plugin?

[MscrmTools]

Crap! two problems:

• I cannot know what is the plugin that sends http requests
• I don't find how to get the body of the request (for example, a request to Azure Application Insights could be fine, but if I don't know what is in the body, I can't assure this is not some data stealing)

So that would be only a logger Or I can establish a whitelist of url

But there is still the problem not being able to check what's in the body

[rappen]

If you are afraid of malicious tools exploiting XTB and "sending passwords" - don't store passwords in the file. XTB tools can do anything, if you are afraid what they might do - check the source code. Perhaps there should be another registry setting to only allow tools that are indeed open source?

Trojan tools is definitely a possibility, any tool can read anything that the authenticated user can read, and do whatever they want with it within the security roles assigned. Anything from reading your opportunities to disabling users and registering new plugins and uninstalling solutions. It comes down to trust and the spirit of the community that develops these tools. With power comes responsibility.

[DigitalFlow]

@rappen: I don't store passwords, but others might. I know that they are not sandboxed, but stealing credentials is the most obvious and not noticable thing to do. In addition to that, Open Source does not help this either. Nothing prevents me from having non-malicious OpenSource Code in my repository while publishing malicious versions locally from my PC directly to Nuget. We can trust 99% of the people, but only one black sheep can steal thousands of admin credentials like that.

[DigitalFlow]

Crap! two problems:

• I cannot know what is the plugin that sends http requests
• I don't find how to get the body of the request (for example, a request to Azure Application Insights could be fine, but if I don't know what is in the body, I can't assure this is not some data stealing)

So that would be only a logger Or I can establish a whitelist of url

But there is still the problem not being able to check what's in the body

Thanks for doing research. I found out about MAF (Managed Addin Framework), which would allow us to load plugins in a sandbox and prevent IO and plain network access. Seems ideal for our use case and it is an official framework by MS. Downside is that it does not seem to be worked on actively and it might be a breaking change for all plugins.