AWS - Abuso di Federazione

Reading time: 3 minutes

SAML

Per informazioni su SAML, controlla:

SAML Attacks - HackTricks

Per configurare una Federazione di Identità tramite SAML, è necessario fornire un nome e il metadata XML contenente tutta la configurazione SAML (endpoints, certificato con chiave pubblica)

OIDC - Abuso di Github Actions

Per aggiungere un'azione github come fornitore di identità:

1. Per Tipo di fornitore, seleziona OpenID Connect.
2. Per URL del fornitore, inserisci https://token.actions.githubusercontent.com
3. Clicca su Ottieni thumbprint per ottenere il thumbprint del fornitore
4. Per Audience, inserisci sts.amazonaws.com
5. Crea un nuovo ruolo con le permissive di cui l'azione github ha bisogno e una politica di fiducia che fidi del fornitore come:

{ "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. Nota nella politica precedente come solo un **branch** di un **repository** di un'**organizzazione** è stato autorizzato con un **trigger** specifico.
7. L'**ARN** del **ruolo** che l'azione github potrà **impersonare** sarà il "segreto" che l'azione github deve conoscere, quindi **conservalo** all'interno di un **segreto** in un **ambiente**.
8. Infine, utilizza un'azione github per configurare le credenziali AWS da utilizzare nel 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

È possibile generare **OIDC providers** in un **EKS** cluster semplicemente impostando l'**OIDC URL** del cluster come un **nuovo provider di identità Open ID**. Questa è una politica predefinita comune:

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

Questa policy indica correttamente che **solo** il **cluster EKS** con **id** `20C159CDF6F2349B68846BEC03BE031B` può assumere il ruolo. Tuttavia, non indica quale account di servizio può assumerlo, il che significa che **QUALSIASI account di servizio con un token di identità web** sarà **in grado di assumere** il ruolo.

Per specificare **quale account di servizio dovrebbe essere in grado di assumere il ruolo,** è necessario specificare una **condizione** in cui **il nome dell'account di servizio è specificato**, come:

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