AWSAccount variables - Secretkey easily exposed

rohin_mcdermott · 16 April 2018 04:03

Hi Guys. We have been using the AWS Accounts feature for a few weeks and I found something that I didn’t think should be possible.

I have a script step for exposing project variables before production deploys so we can confirm all is well (I hope to retire it when the variable preview can handle nested variable set vars). When this step displays a sensitive variable value it shows “*******” but when it shows AWSCredential.Secretkey the value is not masked.

I have an account variable on the project called ‘AWSCredential’ and a sensitive variable called ‘testSensitiveVar’ this is what is output:

And this is the content of myscript step:

$releaseEnv     = $OctopusParameters['Octopus.Environment.Name']
$releaseNumber  = $OctopusParameters['Octopus.Release.Number']
$machineName    = $OctopusParameters['Octopus.Machine.Name']
$projectName    = $OctopusParameters['Octopus.Project.Name']
$tempFile       = [System.IO.Path]::GetTempFileName()
$artifactName   = $releaseEnv + '-' + $projectName + '-' + $releaseNumber + '-' + $machineName + '.csv'

$OctoVarArray = $OctopusParameters.Keys | ForEach-Object {
    $varName = $PSItem
    [PSCustomObject]@{
        'VariableName'  = $varName
        'VariableValue' = $OctopusParameters[$varName]
        'VariableType'  = Switch -Wildcard ($varName) {
        	"Octopus.*" {'System'}
            "env:*"     {'Environment'}
            default     {'Application'}
		}
    }
} | Sort-Object VariableType,VariableName
$OctoVarArray | Export-Csv -Path $tempFile -NoTypeInformation
New-OctopusArtifact -Path $tempFile -Name $artifactname
$vardata = $OctoVarArray.Where({$PSItem.VariableType -eq 'Application'}) | Select-Object VariableName,VariableValue
#Set-OctopusVariable -Name "DeploymentVariables" -value "$($vardata | ConvertTo-JSON)"
Write-Output $vardata

Michael_Noonan · 17 April 2018 07:00

Hi Rohin,

Thanks for getting in touch! I’m sorry about the delay responding. We’ve been trying to reproduce the behaviour, but haven’t been able to yet. I’ll try again tomorrow.

If you have the time/capacity, could you find the raw Account data in the SQL Database (in the Accounts table) and send a copy of that to support@octopus.com along with a link to this thread?

Please check before you send it that there are no sensitive values in clear text. If the sensitive data is encrypted as expected, and you send it to us that’s OK, even we won’t be able to decrypt it without your master key.

In the meantime, as a replacement for your script, there are potentially two built-in features you could use:

In the Project > Variables tab there is now a Preview feature: https://octopus.com/blog/octopus-release-2018.3#deployment-variable-preview
Octopus can write the run-time values as each step begins: https://octopus.com/docs/support/debug-problems-with-octopus-variables

Hope that helps!
Mike

rohin_mcdermott · 26 April 2018 21:48

Thanks Michael. I have emailed support with more details.

Michael_Noonan · 27 April 2018 03:38

Hi Rohin,

Thanks for keeping in touch! The screenshot helped, along with the raw script code and your analysis of the problem. I really appreciate you going to the effort!

I have a theory: the reason those values aren’t being masked is because they’ve been truncated by the script! We can only mask the values if they are left completely intact. If we tried to mask partial values it would be a very expensive and potentially error-prone operation. Arguably the sensitive values are less-sensitive without the entire value.

At this point I don’t think there is anything to do from our end.

My recommendation would be to use the variable preview, or the built-in variable debugging as I mentioned in my last post, rather than a custom script.

Hope that helps!
Mike

Michael_Noonan · 27 April 2018 03:39

Oh, I forgot to mention: If you do have any concerns, please don’t hesitate to reach out again!

rohin_mcdermott · 27 April 2018 06:37

Hi Michael. The AWS Secret key is short enough that it is not truncated in the Task screen. I see it in plain text, complete. Have you tried to replicate with the step I supplied?

rohin_mcdermott · 27 April 2018 06:42

Built in variable debugging was quite messy, this script step sorts and filters the variable values to make them easily readable.
The Variable Preview feature only shows environments in the currently set default lifecycle, which is always for us the development lifecycle. To use the Variable Preview for Production requires a change of the default lifecycle which we don’t want to make. Once this issue is overcome, Variable Preview would be our preference

Michael_Noonan · 30 April 2018 01:44

Hi Rohin,

Thanks for keeping in touch! I did try to reproduce the issue with a few different account types, sensitive variables, and certificates. The masking is working as I expect as long as the values remain intact…

However, I also admit I didn’t go digging much deeper once my confirmation bias kicked in.

Since then I’ve re-tested getting the same happy results. I’ve also gone looking through the history of the source code in that area, and it doesn’t look like the code has changed in any way. There must be a mystery lurking around here - perhaps it’s related to the actual value itself?

If possible it would be really handy to get the raw value of a secret key from you which exhibits the same behaviour. It would be especially nice if the secret key resulted in my having no access to anything of yours.

Variable ordering

On a slight tangent: I’ve updated the variable debugging to sort the variables by name, just like your script. It doesn’t do the filtering your script does, but I think it’s a step in the right direction. Thanks for pointing it out!

Hope that helps!
Mike