Encrypt data within a fixlet

(imported topic written by MattPeterson)

The RFE below has been open for this request, please vote for it if you would like to see this functionallity.

http://www.ibm.com/developerworks/rfe/execute?use_case=viewRfe&CR_ID=54993

The solution I posted in this thread doesn’t allow the parameter to be called from REST API, or from a baseline. This RFE is requesting the ability to hardcode secure parameters into Fixlet/Tasks and deploy them using REST API without entering it in the web call.

I have a task whichs creates a script to run. The script requires a user name and password for adomain account that will run services. I’m looking for suggestions on ways to encrypt the password.

The script I’m running has lines like listed below (5 total user name and password combinations).

if [%ENVIRONMENT%] EQU [PRD] (
set IUSERNAME=user3
set PASSWORD=pass3

I want to accomplish the following, any suggestions would be appreciated.

  1. do not send the password in clear text

  2. do not store the password in clear text on the clients

  3. do not require operators to know the password in order to take action

  4. do not display the password in the console as clear text

(imported comment written by cstoneba)

i normally don’t do tasks with credentials for this exact reason, but if it were me, i’d have your script complied as an exe and then capture that exe in TEM and execute it. That would seem to solve most, if not all, of your requirements.

(imported comment written by MattPeterson)

Great idea, however we have lots of TEM logical and action parameters built in the script which is why I’m dynamicly creating the cmd file. It also makes troubleshooting issues with the script easier when I can modify it within the console.

(imported comment written by jgstew)

See my posts here:

https://www.ibm.com/developerworks/community/forums/html/topic?id=77777777-0000-0000-0000-000014748508&ps=100

This is possible with v9 or later of the BigFix Server/Client.

http://bigfix.me/fixlet/details/3667

http://bigfix.me/fixlet/details/3666

(imported comment written by MattPeterson)

James,

I’ve looked at this solution and it would work great except for the fact that I would need to enter the password each time I want to take the aciton.

I don’t want my operators to need to know the password to take this action. We also want to be able to initiate this task using the REST API, not sure if that would work with all the java script stuff in that task…

Oh, and there are a few different passwords that I call in this single fixlet.

(imported comment written by jgstew)

I think it would be possible to do this with multiple “secrets”, but it would require some tweaking.

I’m not sure if this could be done using the RestAPI, but there certainly should be. I think that would be the only way to have it be secret, but not require someone to enter it. It would still have to be in plaintext in the RestAPI call.

(imported comment written by MattPeterson)

Do you know how I can modify the bes file so the password is embeded and I don’t need to enter it when taking action?

(imported comment written by jgstew)

If you were to do this, the password would be in plaintext in the .BES file when exported from the console. It would also be in plaintext in all clients that get the FXF file of the site (I think, unless they never get the description). This would not be a good idea, which is why I edited this out of my original post once I thought about it.

(imported comment written by MattPeterson)

I worked with professional services to find a solution for this. It turns out that if you hardcode the “secret” in the task it will NOT appear in the FXF file on the clients, nor will it appear in the log file when the action is taken. It is in plain text in the .BES file if exported from the console. We weren’t concered about console users having access to it, we just didin’t want the endpoints recieving it in plain text. Below is the example of the BES file I am creating to deploy two “secrets” to a client: This can be expanded to include as many “secrets” as needed.

<?xml version="1.0" encoding="UTF-8"?>

Distribute 2 Secrets <![CDATA[ Some plain description ]]>

true

Internal

2012-07-31

x-fixlet-modification-time

Sat, 21 Dec 2013 13:52:46 +0000

BESC

<PreLink>Click </PreLink>


<Link>here</Link>


<PostLink> to deploy this action.</PostLink>

<![CDATA[dos echo {parameter “secret” of action} > c:\secret

dos echo {parameter “secret2” of action} >> c:\secret

// uncomment this line to “clean up” the the secret in normal usage.

// delete c:\secret

]]>

(imported comment written by jgstew)

Thanks for providing that solution. I agree that console users having access to the secret is a much lesser disclosure.

I think this may be similar to this:
http://bigfix.me/fixlet/details/3679

(imported comment written by MattPeterson)

That was the source, however I modified it so both “secrets” were hardcoded and not in the description of the task.

I did discover an undesired consequence. When using this task ALL action lines after the command are removed from the log file.

example,

This action script writes three lines to a file, two of them with a “secret” and one line with plain, unencrypted, text, however the log file seems to ommit everything after the initial command (dos in this example)

dos echo {parameter “secret” of action} > c:\secret

dos echo {parameter “secret2” of action} >> c:\secret

dos echo Some other text that I want to see in my log file! >> c:\secret

Output from the client log:

Command succeeded dos (action:538)

Command started - dos (action:538)

Command succeeded dos (action:538)

Command started - dos (action:538)

Command succeeded dos (action:538)

Command started - dos (action:538)

Command succeeded dos (action:538)

(imported comment written by MattPeterson)

Logging can be toggled on/off using these commands.

action log all

action log command

(imported comment written by jgstew)

Also related discussion here:
https://www.ibm.com/developerworks/community/forums/html/topic?id=77777777-0000-0000-0000-000014748508

A post was split to a new topic: Trouble using secure parameters

We have a number of fixlets where we encrypt sensitive data. We are starting to move operators without custom content onto the WebUI as all they need to do are deployments. However, this has since broken a lot of our content as secure parameters are not longer being picked up. Looks like jscript is not available within the webui.

Has anyone found a way to encrypt passwords within the WebUI? We do not want to see the password as a parameter in the action description…so ‘action parameter query’ is not an option?

@wpcooper92 I don’t think this is exposed in WebUI yet.
Currently only available in the full BigFix Console and in REST API.
If you would like to promote this idea, please consider opening an IDEA on https://bigfix-ideas.hcltechsw.com/