ACM.34 Limiting the Confused Deputy Assault in Useful resource Insurance policies
This can be a continuation of my collection on Automating Cybersecurity Metrics.
In a previous publish I wrote concerning the confused deputy drawback on AWS the place an attacker may be capable of leverage a job to acquire entry to one thing they shouldn’t be capable of entry in an AWS account.
In subsequent posts we checked out methods to repair the issue for belief insurance policies and IAM insurance policies. Now we want to try the one remaining problem: useful resource insurance policies.
The publish above explains what we will do to guard sources in a useful resource coverage fro this assault. Useful resource insurance policies would apply to issues like S3 buckets, Encryption Keys, Secrets and techniques, and different sources on AWS that can help you apply a useful resource coverage to them.
AWS says of their documentation so as to add the aws:SourceArn and aws:SourceAccount international situation context keys to restrict entry to the sources the coverage protects. What are international situation context keys? I wrote concerning the several types of circumstances you may add to an AWS Coverage right here:
Let’s check out the sources we now have created up to now which have useful resource insurance policies: Our KMS key and Secrets and techniques Supervisor secret that holds our AWS credentials.
KMS Key Coverage
Right here’s our KMS key coverage (probably with just a few thinks I haven’t written about but to be mentioned in future posts). We’re trying to provide every ARN that may assume this function solely the permissions that it wants.
Notice: In an upcoming publish I'll clarify why the function that I wish to encrypt the info and retailer it in Secrets and techniques Supervisor oddly wants “decrypt” permissions. This looks like a bug to me nevertheless it’s the one approach it really works for now.
As you may see above we have already got circumstances to solely permit utilizing this key with Secrets and techniques Supervisor for encryption and decryption, which I wrote about right here:
Let’s take into consideration what including these two new international situation keys will do for our coverage.
aws:SourceArn
The supply ARN works with service-to-service requests. What does that imply precisely? The AWS documentation might be extra clear on this level. We are able to get a a bit higher clarification from the KMS documentation:
The ARN and account values are included within the authorization context solely when a request involves AWS KMS from one other AWS service.
Does this apply in our case? I might suppose that Secrets and techniques Supervisor can be making a request to KMS once we add the KMS Key Id to a Secret in Secrets and techniques Supervisor. Secrets and techniques Supervisor makes use of the important thing to encrypt or decrypt the worth it shops. I defined how situation keys look within the logs and evaluate the worth within the situation to a worth in a request in my prior publish explaining situation keys.
Once more, I’m leaping forward a bit however I’ve already examined encrypting a worth and storing it in secrets and techniques supervisor. It’s all dealt with by CloudFormation. I checked my CloudTrail logs and couldn’t discover any entries for Secrets and techniques Supervisor accessing KMS. However so as to know what to place within the aws:SourceArn situation I would want to know what ARN to produce for secrets and techniques supervisor. I might presumably be capable of discover that within the logs.
I want the documentation was a bit extra express with pattern requests exhibiting precisely which key within the request every situation is utilizing and when it applies (for instance, it solely applies in the event you write a coverage to provide a service entry, however not when AWS makes use of entry behind the scenes because of the approach the entire cloud platform works.)
Maybe AWS considers the truth that a person or function is making the request to secrets and techniques supervisor and due to this fact calling the encrypt or decrypt permission, fairly than AWS Secrets and techniques Supervisor. In that case, I might count on to see an entry in CloudTrail logs for the function I’m utilizing to run the CloudFormation template exhibiting that it encrypted the worth. Oddly sufficient, I don’t see that within the logs both. I see an “decrypt” entry. I’ll present you that in an upcoming publish.
It has one thing to do with this, however I query the implementation and logging on this situation as a result of the best way it’s carried out, you can’t segregate duties between those that can encrypt and who can decrypt, however I digress.
Secrets and techniques Supervisor integrates with AWS Key Administration Service (AWS KMS) to encrypt each model of each secret worth with a novel knowledge key that’s protected by an AWS KMS key. This integration protects your secrets and techniques below encryption keys that by no means go away AWS KMS unencrypted. It additionally lets you set customized permissions on the KMS key and audit the operations that generate, encrypt, and decrypt the info keys that shield your secrets and techniques.
The underside line is that I don’t suppose we now have any service to service calls utilizing this key so far as I can inform so I don’t suppose this specific situation key applies. I’ll proceed to analysis and take a look at this because the documentation will not be explicitly clear however that’s my present conclusion. My understanding of the documentation is that, to ensure that the situation key to use, there would have to be a corresponding entry within the logs. I don’t see one.
Notice that this situation doesn’t apply to principals, and our coverage already locks down the actions to particular principals.
aws:SourceAccount
The aws:SourceAccount situation additionally appears to primarily apply to service to service calls. We’ve already decided that this doesn’t apply to our coverage.
As well as, we now have locked down all actions to principals which comprise the account within the ARN, so actions are already restricted to a selected account.
Let’s check out what I at present have on this coverage. I’m referencing the output from one other template. I’m additionally creating an ARN utilizing a pseudo parameter and a identified username.
Why do I’ve two entries right here? First, I used an output. Then I spotted I want so as to add the previous administrator title for some motive after I renamed the administrator from KmsKeyAdministrator to KmsAdministrator. Which is healthier?
What may go unsuitable with the output worth? Because it’s handed in from an output in a associated template, anybody who can change that output may grant entry to change the important thing. They may add any ARN to the output and it might get added to this key coverage the following time it’s deployed. Which will or is probably not OK relying on how nicely you’ve secured your IAM CloudFormation templates.
What concerning the concatenation of the present account ID? Let’s say your administrator exists in a special account. That’s not going to work. Moreover the hard-coded worth will fail if the administrator title modifications. For my present functions, I’m planning to place the KMS administrator and keys in a separate account. I like the concept of locking personal the ARN within the second possibility higher so I’m going to make use of that. In fact, after I make that change, I’m going to retest all my code as a result of that might break issues.
So now I’ve this:
Our encrypt and decrypt ARNs are nonetheless handed in, however they’ve restricted permissions and as soon as our batch job roles are deployed we should always be capable of lock them down and forestall modifications. Maybe we may have a multi-factor course of to vary them. We’ll hold occupied with that as we go alongside on this collection.
As defined earlier, we’re utilizing the AWS::AccountId pseudo parameter to retrieve the present account ID. If I needed to make this code work in anyone’s account I may have used wildcards within the ARN:
aws:iam::*:function/KmsAdministrator
That may permit anybody to create a KMSAdministrator in their very own account and entry the important thing probably so we positively don’t wish to try this both.
Heaps to ponder on this publish and we’re not accomplished occupied with and tweaking this KMS key coverage and the associated IAM Insurance policies. Keep tuned for extra on creating zero belief insurance policies on AWS.
Comply with for updates.
Teri Radichel
Should you appreciated this story please clap and comply with:
Medium: Teri Radichel or E mail Record: Teri Radichel
Twitter: @teriradichel or @2ndSightLab
Requests companies by way of LinkedIn: Teri Radichel or IANS Analysis
© 2nd Sight Lab 2022
All of the posts on this collection:
____________________________________________
Creator:
Cybersecurity for Executives within the Age of Cloud on Amazon
Want Cloud Safety Coaching? 2nd Sight Lab Cloud Safety Coaching
Is your cloud safe? Rent 2nd Sight Lab for a penetration take a look at or safety evaluation.
Have a Cybersecurity or Cloud Safety Query? Ask Teri Radichel by scheduling a name with IANS Analysis.
Cybersecurity & Cloud Safety Sources by Teri Radichel: Cybersecurity and Cloud safety lessons, articles, white papers, displays, and podcasts
