AWS - Federation Abuse

Supporta HackTricks

SAML

Per informazioni su SAML, controlla:

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

OIDC - Abuso di Github Actions

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

  1. Per Tipo di Provider, seleziona OpenID Connect.

  2. Per URL del Provider, inserisci https://token.actions.githubusercontent.com

  3. Clicca su Ottieni thumbprint per ottenere il thumbprint del provider

  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 il provider 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:
```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 - EKS Abuso

# 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 è specificato il nome dell'account di servizio, come:

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

Riferimenti

Supporta HackTricks

Last updated