Links

AWS - Federation Abuse

Learn AWS hacking from zero to hero with htARTE (HackTricks AWS Red Team Expert)!
Other ways to support HackTricks:

SAML

For info about SAML please check:
In order to configure an Identity Federation through SAML you just need to provide a name and the metadata XML containing all the SAML configuration (endpoints, certificate with public key)

OIDC - Github Actions Abuse

In order to add a github action as Identity provider:
  1. 1.
    For Provider type, select OpenID Connect.
  2. 2.
    For Provider URL, enter https://token.actions.githubusercontent.com
  3. 3.
    Click on Get thumbprint to get the thumbprint of the provider
  4. 4.
    For Audience, enter sts.amazonaws.com
  5. 5.
    Create a new role with the permissions the github action need and a trust policy that trust the provider like:
    • {
      "Version": "2012-10-17",
      "Statement": [
      {
      "Effect": "Allow",
      "Principal": {
      "Federated": "arn:aws:iam::0123456789:oidc-provider/token.actions.githubusercontent.com"
      },
      "Action": "sts:AssumeRoleWithWebIdentity",
      "Condition": {
      "StringEquals": {
      "token.actions.githubusercontent.com:sub": [
      "repo:ORG_OR_USER_NAME/REPOSITORY:pull_request",
      "repo:ORG_OR_USER_NAME/REPOSITORY:ref:refs/heads/main"
      ],
      "token.actions.githubusercontent.com:aud": "sts.amazonaws.com"
      }
      }
      }
      ]
      }
  6. 6.
    Note in the previous policy how only a branch from repository of an organization was authorized with a specific trigger.
  7. 7.
    The ARN of the role the github action is going to be able to impersonate is going to be the "secret" the github action needs to know, so store it inside a secret inside an environment.
  8. 8.
    Finally use a github action to configure the AWS creds to be used by the workflow:
name: 'test AWS Access'
# The workflow should only trigger on pull requests to the main branch
on:
pull_request:
branches:
- main
# Required to get the ID Token that will be used for OIDC
permissions:
id-token: write
contents: read # needed for private repos to checkout
jobs:
aws:
runs-on: ubuntu-latest
steps:
- name: Checkout
uses: actions/checkout@v3
- name: Configure AWS Credentials
uses: aws-actions/configure-aws-credentials@v1
with:
aws-region: eu-west-1
role-to-assume: ${{ secrets.READ_ROLE }}
role-session-name: OIDCSession
- run: aws sts get-caller-identity
shell: bash

OIDC - EKS Abuse

# Crate an EKS cluster (~10min)
eksctl create cluster --name demo --fargate
# Create an Identity Provider for an EKS cluster
eksctl utils associate-iam-oidc-provider --cluster Testing --approve
It's possible to generate OIDC providers in an EKS cluster simply by setting the OIDC URL of the cluster as a new Open ID Identity provider. This is a common default policy:
{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Principal": {
"Federated": "arn:aws:iam::123456789098:oidc-provider/oidc.eks.us-east-1.amazonaws.com/id/20C159CDF6F2349B68846BEC03BE031B"
},
"Action": "sts:AssumeRoleWithWebIdentity",
"Condition": {
"StringEquals": {
"oidc.eks.us-east-1.amazonaws.com/id/20C159CDF6F2349B68846BEC03BE031B:aud": "sts.amazonaws.com"
}
}
}
]
}
This policy is correctly indicating than only the EKS cluster with id 20C159CDF6F2349B68846BEC03BE031B can assume the role. However, it's not indicting which service account can assume it, which means that ANY service account with a web identity token is going to be able to assume the role.
In order to specify which service account should be able to assume the role, it's needed to specify a condition where the service account name is specified, such as:
"oidc.eks.region-code.amazonaws.com/id/20C159CDF6F2349B68846BEC03BE031B:sub": "system:serviceaccount:default:my-service-account",

References

Learn AWS hacking from zero to hero with htARTE (HackTricks AWS Red Team Expert)!
Other ways to support HackTricks: