AWS - Federation Abuse

Soutenir HackTricks

SAML

Pour des informations sur SAML, veuillez consulter :

Pour configurer une Fédération d'identité via SAML, vous devez simplement fournir un nom et le XML de métadonnées contenant toute la configuration SAML (points de terminaison, certificat avec clé publique)

OIDC - Abus des actions Github

Pour ajouter une action github en tant que fournisseur d'identité :

  1. Pour Type de fournisseur, sélectionnez OpenID Connect.

  2. Pour URL du fournisseur, entrez https://token.actions.githubusercontent.com

  3. Cliquez sur Obtenir l'empreinte digitale pour obtenir l'empreinte digitale du fournisseur

  4. Pour Audience, entrez sts.amazonaws.com

  5. Créez un nouveau rôle avec les permissions dont l'action github a besoin et une politique de confiance qui fait confiance au fournisseur comme :

{ "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. Notez dans la politique précédente comment seule une **branche** du **dépôt** d'une **organisation** a été autorisée avec un **déclencheur** spécifique.
7. L'**ARN** du **rôle** que l'action github pourra **imiter** sera le "secret" que l'action github doit connaître, donc **stockez-le** à l'intérieur d'un **secret** dans un **environnement**.
8. Enfin, utilisez une action github pour configurer les identifiants AWS à utiliser par le workflow :
```yaml
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 - Abus EKS

# 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

Il est possible de générer des OIDC providers dans un EKS cluster simplement en définissant l'OIDC URL du cluster comme un nouveau fournisseur d'identité Open ID. C'est une politique par défaut courante :

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

Cette politique indique correctement que seulement le cluster EKS avec id 20C159CDF6F2349B68846BEC03BE031B peut assumer le rôle. Cependant, elle n'indique pas quel compte de service peut l'assumer, ce qui signifie qu**'AUCUN compte de service avec un jeton d'identité web** va pouvoir assumer le rôle.

Pour spécifier quel compte de service devrait pouvoir assumer le rôle, il est nécessaire de spécifier une condition où le nom du compte de service est spécifié, comme :

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

Références

Soutenir HackTricks

Last updated