AWS - Federation Abuse

Apprenez le piratage AWS de zéro à héros avec htARTE (HackTricks AWS Red Team Expert)!

Autres moyens de 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 pour obtenir l'empreinte 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** d'un **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 **usurper** sera le "secret" que l'action github devra connaître, donc **stockez**-le dans un **secret** à l'intérieur d'un **environnement**.
8. Enfin, utilisez une action github pour configurer les identifiants AWS qui seront utilisés 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

Abus OIDC - 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 cluster EKS simplement en définissant l'OIDC URL du cluster comme un nouveau fournisseur d'identité Open ID. Voici 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 l'identifiant 20C159CDF6F2349B68846BEC03BE031B peut endosser le rôle. Cependant, elle ne précise pas quel compte de service peut l'endosser, ce qui signifie que n'importe quel compte de service avec un jeton d'identité web sera capable d'endosser le rôle.

Afin de spécifier quel compte de service devrait être capable d'endosser le rôle, il est nécessaire de spécifier une conditionle nom du compte de service est indiqué, tel que :

```bash "oidc.eks.region-code.amazonaws.com/id/20C159CDF6F2349B68846BEC03BE031B:sub": "system:serviceaccount:default:my-service-account", ``` ## Références

Apprenez le hacking AWS de zéro à héros avec htARTE (HackTricks AWS Red Team Expert)!

Autres moyens de soutenir HackTricks :

Dernière mise à jour