ACM.133 Limiting Move Position permissions utilizing AWS IAM insurance policies
It is a continuation of my collection on Automating Cybersecurity Metrics.
Within the final publish I wrote about AWS IAM Permission Boundaries.
https://medium.com/cloud-security/aws-iam-permission-boundaries-83180a50c89e
On this publish we’ll take into account permission boundaries with the IAM Move Position permission.
The IAM Move Position permission
How does a principal on AWS assign permissions to a compute useful resource? This may be achieved through the IAM Move Position permissions.
As AWS explains within the above documentation:
To cross a task (and its permissions) to an AWS service, a person should have permissions to cross the function to the service. This helps directors be certain that solely permitted customers can configure a service with a task that grants permissions. To permit a person to cross a task to an AWS service, you will need to grant the PassRole permission to the person’s IAM person, function, or group.
In different phrases, if a person desires to run instructions on an EC2 occasion, they’ll create an EC2 occasion and assign a task to that EC2 occasion with no matter permissions they need to use. Then they’ll run instructions on that EC2 occasion with out offering any credentials. The EC2 occasion obtains the credentials by advantage of the function the one that created it assigned to it.
The individual operating the instructions on the EC2 occasion can leverage the permissions assigned to the EC2 occasion even when their very own coverage disallows these permissions.
Therein lies our privilege escalation drawback. If an AWS person desires to take an motion they don’t have permission to execute however they’ve the Move Position permission on AWS, then they’ll leverage an AWS useful resource and a task assigned to the useful resource to hold out actions they can’t in any other case carry out by way of their very own assigned insurance policies.
In different phrases, be very cautious with Move Position permissions on AWS.
This functionality and potential for privilege escalation has been documented for years. I’m not writing about one thing new. I’ve spoken about it and requested about it since I used to be on the preliminary Capital One group and operating my meetup in Seattle.
How might we restrict a person from escalating privileges by way of a task assigned to a compute useful resource?
Solely present the PassRole privilege with a particular function that has permissions that the person can’t modify
If we solely permit a person to create compute useful resource and assign a particular function then we are able to restrict their potential to escalate privileges.
For instance, let’s say your group permits utility builders to create purposes that retrieve recordsdata from S3 and write logs to CloudWatch. You would create a regular utility function that builders can assign to their purposes. Within the developer coverage you restrict the developer from creating new roles and so they can solely cross this one assigned function.
Right here’s an instance from the AWS documentation above:
That is higher than a free-for-all however it introduces another safety issues:
- This permits an utility to entry *all* S3 buckets and logs as a substitute of the logs particularly assigned to that utility. See why this was an issue by having a look at what occurred within the Capital One Breach. You would possibly be capable of repair that by way of a constant naming conference and a few asterisks within the ARN Within the coverage.
- You’ll most likely want extra permissions for some purposes. There’s usually not a one measurement suits all coverage for all of the purposes a corporation must construct.
- You’ll most likely find yourself granting overly permissive insurance policies as you add increasingly permissions to your “generic” utility coverage. What when you’ve got an utility that wants no entry to S3? Do you create a bucket for that utility anyway? Do you let it have S3 permissions it doesn’t want?
- Let’s say we wished to forestall our IAM customers from accessing Route 53. We might arrange a limitation of their coverage that they’ll solely assign the IAM administration function to a useful resource. Nevertheless, that function has a whole lot of permissions that gained’t be required for a single batch job if we begin creating batch jobs to hold out IAM features. Once more we have now the issue with an excessively permissive function.
- The opposite drawback with this method is that you could’t even use a task that requires MFA on a compute useful resource. I defined that in additional element in earlier posts. So there’s no level to this explicit restriction for our IAM directors.
Solely permit the PassRole privilege with a Permission Boundary situation
Maybe we need to permit a person to create IAM roles and insurance policies, however we need to restrict the permissions that person can assign to a compute useful resource to a subset of AWS permissions. That is the place a Permissions Boundary will assist.
Let’s say we wish a developer to have the ability to hearth up an EC2 occasion that has permission to ship logs to a particular AWS CloudWatch location or modify recordsdata in a particular S3 bucket. Nevertheless, the person is a security-conscious developer who desires to create a task that’s advantageous grained as potential, following safety greatest practices. We need to permit them to do this. Nevertheless, we don’t need them to have the ability to add permissions to register or change domains utilizing Route 53.
We will permit the person to make use of the PassRole privilege however provided that the function has a Permission Boundary assigned to it that limits the permissions within the function assigned to S3 and CloudWatch. The person can create a task with no matter permissions they need. However they are going to by no means be capable of leverage Route 53 permissions even when they add them to their utility function, as a result of these permissions may be denied within the Permissions Boundary.
This methodology may also work for our IAM customers as soon as we get to the purpose of making batch jobs with IAM roles. I’ll clarify that in additional element later, however we’re not there but. So proper now our IAM directors haven’t any motive to cross a task. The PassRole operate doesn’t assist with regards to an EC2 occasion as a result of their function requires MFA.
Deny the PassRole privilege
Now let’s say we wish customers to assign roles to their purposes to carry out actions so that they want to have the ability to carry out a Move Position operate for growth and testing functions. That’s presumably advantageous in a growth surroundings. Nevertheless, after we get to manufacturing, does any person want the PassRole privilege? Perhaps not. Maintain that thought.
In the intervening time, we need to limit our AWS IAM directors from leveraging PassRole to assign a task to a useful resource that may have permission to function within the domains account we created beforehand the place we host all our domains.
To fully stop any issues with PassRole for the second, we are able to take away the Move Position privilege and add it again in when required, with limitations to make use of it solely in particular accounts and with roles which have Permission Boundaries limiting undesirable actions.
We’ll check this out in a future publish.
Comply with for updates.
Teri Radichel
Should you preferred this story ~ clap, comply with, tip, purchase me a espresso, or rent me 🙂
Medium: Teri Radichel
Electronic mail Checklist: Teri Radichel
Twitter: @teriradichel
Twitter (firm): @2ndSightLab
Mastodon: @teriradichel@infosec.change
Publish: @teriradichel
Fb: 2nd Sight Lab
Slideshare: Shows by Teri Radichel
Speakerdeck: Shows by Teri Radichel
Books: Teri Radichel on Amazon
Recognition: SANS Distinction Makers Award, AWS Hero, IANS School
Certifications: SANS
Training: BA Enterprise, Grasp of Sofware Engineering, Grasp of Infosec
How I obtained into safety: Lady in tech
Purchase me a espresso: Teri Radichel
Firm (Penetration Checks, Assessments, Coaching): 2nd Sight Lab
Request companies through LinkedIn: Teri Radichel or IANS Analysis
© 2nd Sight Lab 2023
All of the posts on this collection:
____________________________________________
Writer:
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 check 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 courses, articles, white papers, displays, and podcasts