AWS - Abus de Fédération

Reading time: 3 minutes

SAML

Pour des informations sur SAML, veuillez consulter :

SAML Attacks - HackTricks

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 nécessaires à l'action github 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 va pouvoir **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 :

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 que **N'IMPORTE quel 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",