I have a requirement to get a password into an exe via a FixletSourced Action without exposing said password to logging.
We log all commands executed including those in PowerShell, so running something like: some.exe -password {parameter “password”} would result in the password being exposed, even if it is only in memory for a moment.
We do not have PS based action scripts available yet (we are moving forward with the upgrades to allow this). This may be the real answer, depending on how they are implemented (it is a command then it would be exposed as well).
I would love to accomplish this all in memory without writing the password to disk but cannot think of anyway of doing so.
The only option I see is to write the secret to disk (again without exposing in logs), then do something like: powershell.exe {some.exe -password (get-content somefile.secret)}. So I would need to find a way to push the secret to disk, this would not work (as seen in another post): dos echo {parameter “secret” of action} > c:\secret
Any suggestions on a clean way to do this would be greatly appreciated.
Fundamentally the executable requires a plain text password be provided to it. As a result, there is always a system that is going to capture the password. The question is, are the systems that would capture the password in place at your company?
Using Powershell will result in Powershell logging.
Directly invoking the executable will result in the password being logged as a process creation log, but only if you have process creation logging enabled and only if you have command line argument logging (Only available in Windows 10) also enabled.
waithidden myExecutable.exe -password {parameter "password" of action}
If you do not have process creation logging enabled or you do but not command line argument logging enabled you can simply invoke the executable and pass the password directly. The BigFix client will log that you ran waithidden but I believe it should not log the rest of the line as it knows you’re referencing a secret parameter.
To have this happen explicitly you can use: action log all - toggle logging on action log command - toggle logging off.
To temporarily disable BigFix client logging while you run the command.
Yes, the PowerShell logging would capture the executed commands in our case… which is why I was thinking using something like the below… which would show exactly that in the log, keeping the actual password out of the logs:
powershell.exe {some.exe -password (get-content somefile.secret)}
I will do some testing with waithidden as well, thank you for the pointer.
I am hopeful that I can use ‘createfile until’ with a secure parameter to push the file to the disk without exposing it in the logs, and then launch with PowerShell, using get-content in the execution.
I was hoping that there might be a cleaner way of doing this without writing to the disk. Before going through the above I figured asking here may yield some secret sauce recipe.
Thanks for your time.
So to confirm, you have process creation audit logging with command line argument auditing enabled and that’s why you’re going through all this trouble?
Secret Parameters are not logged in the BigFix client log.
If you dont have Windows advanced auditing process creation logging with command line argument auditing enabled, waithidden is a far more secure option than all of the options you’ve described.
That is correct, we log all commands executed (and their params) including those in PowerShell.
Yes, I understand the method I am describing is less than ideal, this is exactly why I am hesitant to implement it, and asking for advice :-).
It may be worth while for us to wait until we can use PS as a native Action Script and see what can be done there, but that is also dependent on how it is implemented.
If this is true then none of the methods you’ve described will work.
powershell.exe {some.exe -password (get-content somefile.secret)} will still get logged as a Process Creation in Windows with the password in plain text. Only the Powershell script logging will be obscured.
powershell.exe {some.exe -password (get-content somefile.secret)} would be logged as two process creations
1st:
Process Information:
New Process ID: 0x894c
New Process Name: C:\Windows\System32\powershell.exe
Token Elevation Type: %%1937
Mandatory Label: Mandatory Label\High Mandatory Level
Creator Process ID: 0x1180
Creator Process Name: C:\Program Files (x86)\BigFix\BES Client\besclient.exe
Process Command Line: "C:\Windows\System32\powershell.exe" "& some.exe -password (get-content somefile.secret)"
2nd
Process Information:
New Process ID: 0x894c
New Process Name: some.exe
Token Elevation Type: %%1937
Mandatory Label: Mandatory Label\High Mandatory Level
Creator Process ID: 0x1180
Creator Process Name: C:\Windows\System32\powershell.exe
Process Command Line: "some.exe -password plaintextpassword"
If you are creating the PowerShell script yourself, you could embed the password directly into the script using a relevance substitution.
If the PowerShell script prompts for the password when it isn’t supplies on the command line, you could try input redirection… I’m not sure the exact PowerShell syntax but for something like a command shell one would use the < symbol to redirect input rather than the usual > for redirecting output.
It is not a PS script that is being called it is a third party exe, the PS portion came into play because I thought I would be able to bypass the logging using (get-content somefile.secret) in the call to the exe. As @strawgate (thankfully) pointed out, this would still be logged.
Yeah I will look into the input redirection bit as well, but I am thinking this may need a whole new approach.
Yeah, they are fairly tightly controlled, but for this purpose it is not worth the risk. I think it is going to have to be handled with a real solution in the exe somehow. Thank you all for your help!