AWS - Federation Abuse

Learn & practice AWS Hacking:HackTricks Training AWS Red Team Expert (ARTE) Learn & practice GCP Hacking: HackTricks Training GCP Red Team Expert (GRTE)

Support HackTricks

Check the subscription plans!
Join the 💬 Discord group or the telegram group or follow us on Twitter 🐦 @hacktricks_live.
Share hacking tricks by submitting PRs to the HackTricks and HackTricks Cloud github repos.

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:

For Provider type, select OpenID Connect.
For Provider URL, enter https://token.actions.githubusercontent.com
Click on Get thumbprint to get the thumbprint of the provider
For Audience, enter sts.amazonaws.com

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"
        }
      }
    }
  ]
}

Note in the previous policy how only a branch from repository of an organization was authorized with a specific trigger.
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.
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

https://www.eliasbrange.dev/posts/secure-aws-deploys-from-github-actions-with-oidc/

Support HackTricks

Check the subscription plans!
Join the 💬 Discord group or the telegram group or follow us on Twitter 🐦 @hacktricks_live.
Share hacking tricks by submitting PRs to the HackTricks and HackTricks Cloud github repos.

PreviousAWS - Basic Information NextAWS - Permissions for a Pentest

Last updated 4 months ago

OIDC - Github Actions Abuse

In order to add a github action as Identity provider:

For Provider type, select OpenID Connect.

For Provider URL, enter https://token.actions.githubusercontent.com

Click on Get thumbprint to get the thumbprint of the provider

For Audience, enter sts.amazonaws.com

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"
        }
      }
    }
  ]
}

Note in the previous policy how only a branch from repository of an organization was authorized with a specific trigger.

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.

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"
                }
            }
        }
    ]
}

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",