cdk pipelines: Cloudformation injection vulnerability

[hupe1980]

I created a proof of concept to demonstrate an attack on the popular aws cdk pipelines. This exploits the fact that there is some time between the “Synth" step and the use of the cloudformation templates and lambda assets ("SelfMutate") and that no integrity check is performed by default. After receiving an event from s3, the Lambda function injects the malicious code/resources into the generated files. SAST/DAST controls and pull request checks are bypassed, and other accounts can also be attacked if the pipeline supports cross-account deployments.

https://github.com/hupe1980/cfni

AWS Security has determined that this is not a security issue as they recommend customers to use cloudformation hooks as a protection mechanism against non-compliant resources.

https://aws.amazon.com/blogs/mt/proactively-keep-resources-secure-and-compliant-with-aws-cloudformation-hooks/

Is there a way to sign the templates and assets generated in the synth step with a public key so that integrity can be verified in later steps using cloudformation hooks?

There doesn't seem to be such a function yet and the security notes do not currently indicate such a risk

https://docs.aws.amazon.com/cdk/v2/guide/cdk_pipeline.html#cdk_pipeline_security

[rix0rrr]

Let me see if I understand:

You have resources deployed into your own account (such as the artifact bucket and staging bucket), and given enough permissions you are able to replace files in those S3 buckets between when they are written and when they are read, so that the deployment does something else?

It's true that protecting against your own developers is not really in the CDK Pipelines threat model. I'm not even sure it's possible. It's fair to say that this should be mentioned in the documentation so that organizations that cannot trust their developers will be aware they should have something like CFN Hooks or AWS Config in place.

Is there a way to sign the templates and assets generated in the synth step with a public key so that integrity can be verified in later steps using cloudformation hooks?

Since the Synth step must be able to produce signed artifacts, your developers will implicitly have access to this facility as well. Either because we have to include the private key into the CDK binary (so it's trivially extractable), or because they can run arbitrary code in a CodeBuild job that must needs have permissions to use KMS, AWS Signer, or read from Secrets Manager.

If you really wanted to, you could potentially go the way of injecting a CodeBuild job into the pipeline that signs the artifacts before validating them against guard rails and lock down access to that CodeBuild job (though developers will have access to the pipeline definition and will be able to move the guard rails or signing steps around), and then validate the signatures using CloudFormation Hooks or perhaps S3 Object Lambdas... but at that point, wouldn't it be simpler to move the entire suite of guard rails checks into CloudFormation Hooks (for prevention) or AWS Config (for auditing), and bypass the whole process of trying to establish non-forgeable guarantees early on in the pipeline?

[hupe1980]

@rix0rrr Many thanks for the answer.

However, it was not my primary concern to protect myself from my own developers. I would rather implement this with controls like enforcing the use of CICD pipelines, two person reviews, code scans, least-privilege roles etc.

I actually just wanted to point out that you can even carry out a (cross-account) attack with relatively low permissions: s3:GetObject, s3:PutObject, s3:PutBucketNotification and no iam permission.

I base my threat model very much on the slsa framework and build integrity is a big issue there:

https://slsa.dev/spec/v0.1/threats#build-integrity-threats

However, I have now understood that signing the artifacts is not that easy. Up until then I had the following solution in mind:

• Signing in the Synth Step (CodeBuild)
• Checking the signature with CFN hooks
• Key only allows access from Synth Step (CodeBuild) and CFN hooks

But then the only protection at the moment is to restrict access to the artifact bucket as much as possible.

[rix0rrr]

I actually just wanted to point out that you can even carry out a (cross-account) attack with relatively low permissions: s3:GetObject, s3:PutObject, s3:PutBucketNotification and no iam permission.

If you are saying "s3:PutObject on any bucket", then yes, you can do it. Not sure I'd call that relatively low permissions though. That's effectively saying something akin to "you are allowed to overwrite all data in this account".

[github-actions[bot]]

Hello! Reopening this discussion to make it searchable.