To NotResource or To Not NotResource In an AWS IAM Coverage | by Teri Radichel | Cloud Safety | Jan, 2023

ACM.131 Forestall our IAM Customers from altering their very own function, insurance policies, and group deployed by the ROOT CloudFormation stacks

It is a continuation of my sequence on Automating Cybersecurity Metrics.

In our final put up we began exploring forestall IAM directors from altering their very own insurance policies and the way they could escalate privileges.

One of many IAM Coverage parts we could possibly use to restrict permissions in an IAM coverage is NotResource:

With NotResource, we create a coverage assertion and point out that it applies provided that the useful resource the IAM principal is performing on just isn’t the required useful resource (like our IAM Administrator coverage, function or group).

White Lists vs. Black Lists

We might have used the NotResource to disallow our IAM person to create or modify CloudFormation stacks with ROOT within the identify. The stack we don’t need the person to switch can be the useful resource within the NotResource portion of the assertion.

Disallowing one thing by blocking entry to a particular useful resource is named a black checklist. You specify what a person can not do or entry.

Alternatively we are able to present a particular checklist of solely the sources the person is allowed to entry or modify. That kind of safety rule is named a white checklist.

I lined these subjects a bit extra in my ebook on the backside of this put up.

If we solely block entry to the stacks with ROOT within the identify (a black checklist), somebody might merely create a brand new stack with a distinct identify to get round that block. Moreover, the IAM Admins can be blocked from updating the ROOT stacks however there are different stacks we additionally don’t need them to replace, like KMS, AppSec, and so on.

A greater method is to make use of a white checklist to specify precisely which stacks a our IAM directors are allowed to vary. In our case, we don’t want a NotResource to restrict entry to the cloud formation stacks used to create the IAM person, coverage, and group, as a result of we added an Enable assertion and particularly enable our IAM person to solely change stacks with the IAM-* identify. For the reason that stacks used to create the IAM coverage, person, and group don’t begin with that identify, our IAM directors can not modify them.

This method additionally disallows the person from altering different stacks corresponding to our KMS stacks, EC2 stacks, and so forth, not simply the ROOT stacks.

Keep away from Double Negatives

The place else might we use a NotResource? We might Deny adjustments to person passwords if the useful resource is NotResource: the person that’s altering the password. Nonetheless, in that case we’ve got a double unfavorable and overly difficult logic.

We will cut back that logic to enable a person to solely change the password for the present person.

The NotResource could also be helpful however it additionally could include loopholes if you happen to don’t assume it by rigorously. It additionally could create overly difficult logic. In lots of circumstances, it’s not the best choice.

When Black Lists are Helpful

There may be one factor I can use this NotResource for in my quest to stop IAM customers from altering their very own insurance policies. I would like IAM customers to have entry to create any function, coverage, person, or group. I simply don’t need them to have the ability to change their very own. There’s a very brief checklist of sources the IAM customers shouldn’t entry and I can use the NotResource together with that checklist.

I can forestall IAM adjustments to the IAM admin person, group or coverage created by the Root CloudFormation stacks by utilizing a black checklist to stop them from modifying the IAM administrator coverage or group created by the foundation stack. (I’ll tackle customers and function assumption individually.)

I can change this within the IAM Admins coverage:

 Assertion:
- Impact: Enable
Motion: 'iam:*'
Useful resource: '*'

To this (pseudocode):

 Assertion:
- Impact: Enable
Motion: 'iam:*'
NotResource: '*IamAdmin*'

Contemplate future coverage adjustments

One caveat right here is that we’ve got to ensure the identify of the IAM insurance policies don’t change if we use this method. Let’s say for some cause our ROOT admin determined to vary the identify of the IAM Insurance policies someplace down the road to one thing aside from IamAdmin like IdentityAdminRole and IdentityAdminPolicy. At that time the above coverage would now not forestall IAM directors from modifying their very own function and coverage.

It is very important perceive doc nuances like this for all concerned when future updates come into the image. Maybe we might add some feedback to every coverage that the identify has to incorporate IamAdmin for the insurance policies to work accurately.

Another choice: Referencing coverage exports

Another choice can be to make use of the outputs of the ROOT stacks to formulate our assertion leveraging NotResource.

The very first thing I have to do is add the useful resource ARNs to my CloudFormation scripts the place they’re lacking. Let’s see what we are able to get again from a coverage:

Let’s add that to the coverage outputs for GroupPolicy:

Now check out the CloudFormation output:

What you get again just isn’t the coverage identify however moderately some logical ID Root-Grou-XXXXXXXXX.

Now, there could also be some approach to flip that again right into a coverage identify, however I’m simply going to go forward and arduous code the coverage identify at this level.

Additionally word that if I attempted to translate that logical ID again to a coverage identify, there appears to be a bug associated to CloudFormation and stacks and logical IDs for Insurance policies.

I hope these logical IDs usually are not used within the precise coverage analysis logic in such a method that the flawed coverage ID will get utilized underneath some circumstance in AWS. However that’s as much as AWS to check as finish customers don’t typically work immediately with the logical IDs. I’m undecided how AWS code makes use of these logical IDs behind the scenes or if they’re meant to be distinctive.

To get across the logical ID Drawback I might arduous code the coverage identify into the output as an alternative. For my group coverage I can use the NameParam:

For my different stacks I’ve to hardcode the coverage identify or cross in an pointless parameter. These hardcoded values cloud result in a typo or mismatch so they aren’t perfect.

Then I would want to edit the IAM coverage creation template and reference every particular output that’s required and formulate an ARN from these values within the NotResource useful resource checklist.

Reflecting on Our Choices ~ Contemplating Complexity and Potential Gaps

If we check out our Root CloudFormation stacks, I’m solely involved with limiting entry to vary the Group, Function, and Coverage proper now. As talked about I’ll cope with customers later.

If I wished to explicitly get the outputs of every stack and add them to our coverage I might do this. I’d must manually add the coverage names as outputs as proven, which might result in a typo someplace. If new stacks are added, I must take the next steps every time we add a brand new IAM admin useful resource created by our ROOT stacks:

1. Add the suitable output to the stack.
2. Be certain the output useful resource identify matches the coverage identify for insurance policies.
3. Add the output to the CloudFormation template that creates the IAM Admin Function coverage and redeploy it.

Sorry for taking you down that rabbit gap, however that every one appears a bit convoluted in the long run and possibly error inclined. I’m going to go forward and keep on with the less complicated resolution that doesn’t require re-deploying the IAM admin function coverage if a brand new IAM administrator useful resource is added (presuming it has the right naming format matching the IAM coverage.)

Sustaining the Integrity of Your Safety Structure and Design

Whomever maintains the IAM administrator insurance policies and root stacks wants to grasp the design and keep the integrity of the answer if and after they make adjustments.

Therein lies the issue in lots of organizations with regards to safety. You might need some stellar workforce develop the preliminary, strong safety design. Then that workforce arms it over to a different workforce to keep up who “tweaks” the code in varied ways in which breaks down the integrity and introduces safety gaps. Because of this I want to have some consistency in who maintains code and oversight by safety professionals for important adjustments.

The trick is to grasp what’s important and hopefully by naming our stacks “ROOT” and if our group enforces a coverage of solely deploying adjustments from supply management by a safe automated course of, an understanding that that is important code ought to exist. For important code, implement any and all adjustments by an automatic deployment course of with code solely coming out of your supply code repository after a safety evaluation by the suitable folks. Doc the design and structure and any caveats when making adjustments (as I’m doing on this weblog, however I also can do within the code if this can be a important piece of the structure.)

Make sure that no guide adjustments can impression your important code or weaken your safety design. If somebody in your group can go in and make guide adjustments so as to add new IAM permissions exterior of your automated, secured deployment course of with out oversight, evaluation, and full understanding of what they’re doing and why, you then don’t actually have a safe cloud setting.

Testing Our Change

The one place the place IAM permissions exist on the time of this writing in my GitHub repository exterior of the ROOT admin profile is the IAMAdminsGroupRolePolicy at this level. We will add the NotResource right here.

Nonetheless we are able to’t formulate it as I’ve it above or we’ll get this error:

We do must formulate the sources within the type of an ARN however we are able to nonetheless use a *. So our coverage finally ends up wanting like this:

Deploy the coverage adjustments utilizing CloudFormation as defined in prior posts. Confirm the adjustments present up within the AWS console or by a CLI question if you happen to want.

Testing Our Coverage with the AWS IAM Coverage Simulator

Now we have to check our coverage — each that our coverage nonetheless permits our IAM directors to do their jobs — and that they can not carry out the actions we don’t want them to carry out.

One approach to check your insurance policies is although the AWS console IAM Coverage Simulator software:

Effectively, sadly we can not check our IAM coverage right here because it now not exists. Did it exist earlier than? I can’t bear in mind. I often check IAM by different means. When you select from the checklist of obtainable companies, solely the brand new IAM Identification Middle exists:

Looking by the checklist of actions, I can’t discover something to simulate altering a coverage or altering the function for coverage and so forth.

Insurance policies are nonetheless utilized by AWS IAM Identification heart, and so are roles, so I hope they permit for testing by this software sooner or later so we are able to check insurance policies just like the one I’m making an attempt to check right here. #awswishlist

Handbook Testing

We will merely use our AWS CLI profile named IAM that we configured in prior posts to check our coverage. That function profile assumes our IAM function and is ruled by the IAM coverage we wish to check.

First, attempt to run these instructions along with your ROOT profile to confirm they succeed:

aws iam list-policies | grep IAMAdmin
aws iam list-roles | grep IAMAdmin
aws iam list-groups | grep IAMAdmin

You’re going to get a listing of sources as anticipated and the grep portion of the command limits the checklist to the names of sources that comprise IAMAdmin.

Now check those self same instructions along with your IAM profile:

aws iam list-policies --profile IAM | grep IAMAdmin
aws iam list-roles --profile IAM | grep IAMAdmin
aws iam list-groups --profile IAM | grep IAMAdmin

What do you assume will occur?

You get again the identical checklist of roles. Why?

Let’s check out the AWS IAM priority chart.

Hmm. There may be an express Deny within the AWS coverage that ought to apply to this person disallowing actions on the sources we’re querying. Based on the above chart, if an express Deny exists the motion ought to be denied, however we’re nonetheless in a position to question the sources. Why is that?

Effectively, because it seems, the checklist performance just isn’t particular to a useful resource. If a person has permission to aws iam list-groups, that person will get again all teams. Any useful resource particular circumstances or exclusions don’t apply. This exposes some data it’s possible you’ll or could not wish to expose, however that’s now it really works.

Take a look at a resource-specific motion deny

Now let’s check a resource-specific motion with our NotResource command and a few asterisks. I returned to my unique coverage and tried to delete the IAMAdmins group:

Now the restrictions appear to be working.

Take a look at that the allowed actions nonetheless work as anticipated

The one factor left to do is to check that our deployment scripts nonetheless work. That’s straightforward to do. We will delete stacks the IAM admin deploys and redeploy them.

I’ve this Safety Metrics Operators function, group, and coverage I created and I’m not likely utilizing but. I’m going to go forward and delete all these stacks.

Carried out.

Now I can re-run my check.sh script within the IAM/check folder and confirm these stacks get recreated. My script is working, and sure the sources are getting recreated.

Subsequent Steps

We’ve prevented IAM admins from modifying their very own group, function, and coverage on this case. Now we have to contemplate different escalation paths corresponding to:

• Creating a brand new function, making a compute useful resource, assigning a job, and working instructions from that compute useful resource that the IAM person shouldn’t be in a position to do.
• Creating a brand new person, assigning a coverage, and altering the password to function as that person.

Comply with for updates.

Teri Radichel

When you appreciated this story ~ clap, observe, tip, purchase me a espresso, or rent me 🙂

Medium: Teri Radichel
E-mail Listing: Teri Radichel
Twitter: @teriradichel
Twitter (firm): @2ndSightLab
Mastodon: @teriradichel@infosec.trade
Submit: @teriradichel
Fb: 2nd Sight Lab
Slideshare: Displays by Teri Radichel 
Speakerdeck: Displays by Teri Radichel
Books: Teri Radichel on Amazon
Recognition: SANS Distinction Makers Award, AWS Hero, IANS College
Certifications: SANS
Schooling: 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 by way of LinkedIn: Teri Radichel or IANS Analysis

© 2nd Sight Lab 2023

All of the posts on this sequence:

____________________________________________

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, shows, and podcasts