Skip to content

Latest commit

 

History

History
155 lines (122 loc) · 6.78 KB

aws-federation-abuse.md

File metadata and controls

155 lines (122 loc) · 6.78 KB
Raw

AWS - Federation Abuse

{% hint style="success" %} Learn & practice AWS Hacking:HackTricks Training AWS Red Team Expert (ARTE)
Learn & practice GCP Hacking: HackTricks Training GCP Red Team Expert (GRTE)

Support HackTricks
{% endhint %}

SAML

For info about SAML please check:

{% embed url="https://book.hacktricks.xyz/pentesting-web/saml-attacks" %}

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. For Provider type, select OpenID Connect.
  2. For Provider URL, enter https://token.actions.githubusercontent.com
  3. Click on Get thumbprint to get the thumbprint of the provider
  4. For Audience, enter sts.amazonaws.com
  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. Note in the previous policy how only a branch from repository of an organization was authorized with a specific trigger.
  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. 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:

{% code overflow="wrap" %}

"oidc.eks.region-code.amazonaws.com/id/20C159CDF6F2349B68846BEC03BE031B:sub": "system:serviceaccount:default:my-service-account",

{% endcode %}

References

{% hint style="success" %} Learn & practice AWS Hacking:HackTricks Training AWS Red Team Expert (ARTE)
Learn & practice GCP Hacking: HackTricks Training GCP Red Team Expert (GRTE)

Support HackTricks
{% endhint %}