We noticed that when we connect with RemotePowershell using the Remote Desktop Manager and the "My Personal Credentials" that the password can be read unencrypted.
1. Connect with the RDM RemotePowershell on a Device
2. "Exit-PSSession"
3. "$Password"
4. and the password gets displayed in clear text!!
With the following script an Administrator can read out all logoninformations of the open Powershell-sessions on a Server!:$encode=Get-WmiObjectWin32_Process-Filter"name = 'powershell.exe'"-computername$computername|?{$_.Commandline -match"-EncodedCommand"} |%{$_.Commandline.Trim("""C:\Windows\syswow64\WindowsPowerShell\v1.0\powershell.exe"" -NoExit -EncodedCommand")}
foreach($valuein$encode) {
$decode=[System.Text.Encoding]::Unicode.GetString([System.Convert]::FromBase64String($value))$decode.Split([Environment]::NewLine) -match"username ="-replace"\$"
$decode.Split([Environment]::NewLine) -match"password ="-replace"\$"
Write-Host""
}
Is this a Problem of our configuration? Can you reproduce the problem?
Regards, Dominik
Hello,
Are you able to reproduce this behavior outside of RDM?
About the $Password variable, what method do you use to initialize it?
Do you experience the same issue if the Credentials setting of the session is set to another value than 'My Personal Credential"?
Best regards,
Érica Poirier
Hi Erica,
#Are you able to reproduce this behavior outside of RDM?
No, not with "Enter-PSSession" in a normal Powershell-session outside of the RDM we cannot reproduce this behaviour.
#About the $Password variable, what method do you use to initialize it?
We do not initialize the $Password variable. i think this variable gets initializet by the RDM
Do you experience the same issue if the Credentials setting of the session is set to another value than 'My Personal Credential"?
Yes, the Problem exists with all values.
We think, the Problem is that RDM passes the Password unencrypted as a Parameter in the $Password-variable.
Perhaps the Windows Passthrough Authentication would be the best solution to that Problem.
Best regards and a enjoyful Weekend
Dominik
Hello,
Thank you for your answers.
Could you please send us a sample of that script and a screen shot of the properties of the PowerShell entry?
If you prefer, you can send it in a private message or at support@devolutions.net.
Best regards,
Érica Poirier
Do you have an example on how we could encrypt the password and make sure that PowerShell is able to get the information?
Regards
David Hervieux
Hi,
@Erica: We don't use a Script. The Problem appears, when we open a "PowerShell Remote Connection to a device out of the RDM:
(With the script in the Post 1 it is possible for an Administrator to read out the unencrypted Passwords and Users of all outgoing Powershell Connections.)
Screenshots of the Properties of the Powershell entry:
@David: We think with the Windows Passthrough Authentication the Problem can be solved.
Perhaps there is a Problem with our Data Source Settings?
Hi,
What do you mean by data source settings? To use the Windows authentication passtrough we need an application that support it. Do you know if PowerShell can use it. It also means that you will not be able to specify the user you want.
Regards
David Hervieux
Hi David,
#1, What do you mean by data source settings?:
In the Data source Settings we have "Disable the Password variable for all sessions" enabled. But the Password Variable is aviable in the Powershell.
#2, To use the Windows authentication passtrough we need an application that support it. Do you know if PowerShell can use it.:
Yes, powershell can use the Windows passthrough authentication. (If you open a RemotePowershell conection to a device in the same Domain, you don't have to retype in your credentials.)
We don't exactly know how the authentications with the diffrent Connections to the devices work. But we think it isn't save if the password is passed unencrypted to the respective applications...
There are multiple ways to encrypt the password while the connection. Windows Passthrough authentication and single sign on is one of it. Powershell would also supports secure-string.
#3, It also means that you will not be able to specify the user you want.:
In our environnment normally we don't need to specify the user. we work with the Domain Users.
The only method I know of getting around this is to have the password stored on disk as encrypted. I use a function in the gallery called StoredPSCrendential which will encrypt the password in the registry. It's still able to be unencrypted by that user on that machine...
Perhaps a function like this could be implemented in RDM? Even use the ConvertTo-SecureString -SecurityKey using the RDM application encryption.
Hi David.
Do you understand the Problem? can you reproduce it?
Kind regards,
Dominik
Just to be sure I understand. We will need to add a mode where not username and password are sent and it will automatically use the Passthrough Authentication? This means that RDM will not use the My Personal Credentials.
Regards
David Hervieux
Hi David,
When RDM sends the password to Powershell or any other application, it does not encrypt it and therefore creates a security issu for us. When use Powershell, it is possible to query the $Password variable and recive the password as clear text. (mentioned previously including printscreens.)
Windows Passthrough Authentication as a new Login Type would definitely be an asset but does not solve the problem of the other login options e.q. my personal credentials where the password is still unencrypted...
Ok, but If I encrypt the password, how the application will decrypt it?
David Hervieux
Dominik,
My previous reply focused more on the technical aspects of passing credentials to a powershell script (which is what RDM does). To accomplish this would require a separate function and database call, a "Get-RDMCredential" so to speak... which truthfully... would be a very nice feature.
From a purely functional perspective, using the RunAs option would give you the pass-thru authentication you mentioned and alleviate the concern?
David,
I do not know how this issue can be solved. I just wanted to let you know about this security issue and it would be great if you could find a working solution for it.
Regards,
Dominik