Triggering API things from fixlets

Usage and Config
1

Hi all,

I’m looking for feedback and suggestions here…

Because Reasons™, we have a need for API-driven actions in one tool, triggered as part of a BigFix baseline/action/workflow. But… how would one safely store and manipulate the second tool’s API key within a fixlet context?

  • Make the fixlet a secure fixlet, requiring the operator to paste a key every time. (ugh, gross)
  • Store the key as a fixed parameter? (radically insecure)
  • Store the key as a fixed parameter, and the fixlet in a very limited site? (Better, but impacts the entire installation’s architecture.)
  • Store the key in a file to be retrieved via prefetch and unwrapped in a TBD manner? (tighten controls on that file!)
  • Store the key in some other TBD obfuscated manner?
  • … something else?

Thanks for thoughts and suggestions.

-Andrew

2

So I understand this correctly…this is not triggering BigFix things via API, but an action that runs on the endpoint to trigger some other vendor’s API to do a thing?

Is the API a REST API? What language are you using to send the API commands, and what kind of credential storage is allowed based on that client & server?

If the thing is Kerberized, you may be able to use the machine’s kerberos identity to authenticate & send the API command. I’m guessing it’s not that clean though and you need to store & pass a password for this API?

For my Python scripts, I’m becoming a fan of the ‘keyring’ module. It stores credentials with varying levels of security though so if you use it, be sure to check which backend it’s using. On Windows it uses Windows Credential Manager; on Linux and Mac it varies based on whether it can find a dbus back-end (i.e. a graphical logon session), and in worst-case it may be in trivially encoded files.

Security-wise, there is very little difference between ‘store the key as a fixed parameter’, ‘store the key as a fixed parameter, and the fixlet in a very limited site’, or ‘store the key in a prefetch’. Those may limit who can find the fixlet in the Console, but a client (or a browser pretending to be a client) could still download & read all of the fixlet content, including the prefetch commands and trigger prefetch download commands to obtain the file. The attack surface on that can be reduced somewhat by Relay Authentication but it’s still a pretty serious risk.

What’s the exposure/impact if this password/api key are leaked? Can you limit the exposure, maybe by creating an application to proxy requests to the API, limit the credentials storage to this proxy application, and limit which things the application will ask the tool to do on a client’s behalf?

Otherwise, I’d probably look at pre-sharing the API key to the client (either outside of BigFix entirely, or with a one-time Secure Parameter action to the clients involved), and then reference that stored password when you trigger the API commands. Python Keyring may be an option for storing the password on endpoints, or you might look into Vault. I think Gary Louw has talked some about using Vault in the context of MDM or the Plugin Portal, I’ll ping him on this.

1 Like
3

The basic idea is that we have a baseline of pedestrian fixlets (install this software, uninstall that one, copy in a new version of this other file). In the overall workflow, we also need something else done in an unrelated tool. So I’m thinking of another fixlet/task within that baseline which itself pokes an API endpoint that triggers the unrelated tool.

It’s been suggested that what I need is, in fact, an intermediary endpoint. Something that has access to trusted keys, and functions that call the other APIs in other tools. Then the BigFix agent runs a local script with some relevance-provided parameters; that script pokes the intermediary endpoint, which then does whatever it needs to [a] validate the request and [b] ask the other APIs to do additional things.

4

A bit late to the party with this one. What would the fixlet be doing to use the API key?

I was wondering if perhaps on the Windows OS if you can leverage the Credential vault. Assuming if the API key is a name and key, maybe storing that as a username & password in the Windows Credential manager would allow it to be secured on a trusted endpoint but accessible via methods such as PowerShell that could be invoked via a fixlet.

I have no real experience of API keys or possible formats but assuming I have an API with the name MyAWSAPIKey and the key as awwapi1234567890abcdef0987654321, treating those as a username and password type credential, that could be added to the credential manager. I guess this follows the intermediary endpoint concept as it would be a known and trusted endpoint storing the key

[Windows.Security.Credentials.PasswordVault,Windows.Security.Credentials,ContentType=WindowsRuntime]
$ResourceName = "MyStoredAPIKey"
$Vault = New-Object Windows.Security.Credentials.PasswordVault


# Add the credential
$ResourceCredential = New-Object Windows.Security.Credentials.PasswordCredential -ArgumentList ($ResourceName, $Credential.UserName, $Credential.GetNetworkCredential().Password)
$Vault.Add($ResourceCredential)
Remove-Variable Credential
Remove-Variable ResourceCredential

# Retreive the credential
$Resource = $Vault.FindAllByResource($ResourceName)
$Resource.RetrievePassword()
$Credential = New-Object PSCredential $Resource.UserName, (ConvertTo-SecureString -string $Resource.Password -AsPlainText -Force)
Write-Output $Credential 

UserName : MyAWSAPIKey
Password : System.Security.SecureString

image
image834×466 21.7 KB

1 Like