Thread by @Frichette_n

It's a beautiful Sunday, so let's chat about hacking AWS environments! In this thread, I want to talk about an interesting quirk with Amazon Cognito, demo why least privilege is the most important thing in the cloud, and emphasize that mitigations aren't always enough. A 🧵

For the demo we have an Identity pool which supports guest access and has a user pool attached for authenticated access. The Identity pool does NOT have the classic flow enabled, and the user pool does NOT allow registration (this is important later).

This Identity pool has a glaring misconfiguration! The role used for guest access mistakenly has the AdministratorAccess policy attached! Oh no! Anyone can interact with our pool, assume this role, and have admin access to our AWS account!

With a couple unauthenticated API calls we can get credentials for this misconfigured "cognito-guest-role". We now have admin access to this AWS account because of a simple mistake. It's over right? Ransomware city? Build a crypto-mining kingdom?

Well......no. Actually not. If we try to do something like iam:ListUsers....it fails? How can this be? The "cognito-guest-role" has the AdministratorAccess policy attached?

The reason is that when you call cognito-identity:GetCredentialsForIdentity, Cognito will silently apply a session policy in the background. A session policy is a special type of policy you can apply when a role is assumed that limits its permissions for that session.

This session policy, "is used as a guardrail against overly permissive policies attached for roles in an identity pool". It is defense in depth in case you accidentally provide crazy permissions to guest users. It is ONLY applied to guest users (not auth)
docs.aws.amazon.com/aws-managed-po…

Now, to be clear, it's still pretty broad. Don't go thinking you can give all your Cognito guests AdministratorAccess and everything will be secure. If we look at this policy there is a ton of access including: lambda:*, sns:*, sqs:*, dynamodb:*, logs:*, s3:*, etc.

However, there is a really interesting entry in that session policy. An entry that theoretically would undo this protection entirely. Can you guess what it is?

If you notice, cognito-identity is included. That's.....weird. Couldn't you abuse this to disable this protection?

See, there are 2 ways to get credentials for Cognito Identity Pools: The "enhanced" flow and the "basic" flow. The enhanced flow is what we did previously, and utilizes GetCredentialsForIdentity. It is that flow which adds the session policy.
docs.aws.amazon.com/cognito/latest…

The "basic" flow, to contrast, does NOT attach a session policy. If you have the basic flow enabled (which is not the default), and you overprivilege your guest policy, an adversary has free reign to your account (and hence ransomware city can be founded on your dime)

Going back to the session policy, if we have privileges for that, couldn't we just enable the basic flow (which does not attach the session policy), get new credentials and suddenly have access to everything in the account? Well.....no. Turns out there is something extra.

If you try, you get a "These credentials are not valid for accessing this resource" error. It seems that AWS expected an adversary would try this (or someone reported this to them) and added an extra protection.

Even if you, on paper, have the permissions to modify an identity pool, you can't actually do it. This goes for just about every cognito-identity API call excluding GetId, GetCredentialsForIdentity, and GetOpenIDToken.

Now, to further stress, this session policy is NOT enough. An adversary can still cause all sorts of harm. For example, here are the steps to go from unauthenticated to authenticated with the identity pool.

First, we are going to list the user pools in the account and create a user. We'll then confirm that user.

We have now created a Cognito user pool user using the guest access credentials! Now let's authenticate to the Identity pool using these created credentials.

And boom! We managed to go from guest access to the identity pool to authenticated access in just a few minutes all because of a misconfiguration. There are other privilege escalation opportunities that could be explored, such as the aforementioned Lambda access.

So what have we learned:
- LEASE PRIVILEGE is king in the cloud. Regularly audit your Cognito identity pools for guest access and what level of privilege they have. They are basically wildcard principals in a trust policy with an extra step.

- Cognito will try to protect you from yourself! It adds a session policy as a sort of guardrail to protect you from over privileged identities. However, we learned that it ONLY does that for the "enhanced" flow. Double check to see if you have the "basic" flow enabled...

and if you do, you should probably disable it for extra protection. If you have a particularly old identity pool this becomes doubly important.

- Don't rely on mitigations or guardrails to protect you, there are still opportunities for an adversary to do harm. Scoping your IAM policies to the bare minimum is the best choice to defend yourself.

If you enjoyed this thread checkout @HackingthCloud. An open-source encyclopedia of offensive security techniques to use in cloud environments.

hackingthe.cloud