Italian - Ht Cloud
HackTricks Training Twitter Linkedin Sponsor

AWS - Federation Abuse

Impara l'hacking di AWS da zero a esperto con htARTE (HackTricks AWS Red Team Expert)!

Altri modi per supportare HackTricks:

SAML

Per informazioni su SAML, consulta:

Per configurare una Federazione di Identità tramite SAML, è sufficiente fornire un nome e il metadata XML contenente tutte le configurazioni SAML (endpoints, certificato con chiave pubblica)

OIDC - Abuso di Github Actions

Per aggiungere una github action come provider di identità:

  1. Per il Tipo di provider, selezionare OpenID Connect.

  2. Per l'URL del provider, inserire https://token.actions.githubusercontent.com

  3. Fare clic su Ottieni thumbprint per ottenere l'hash del provider

  4. Per l'Audience, inserire sts.amazonaws.com

  5. Creare un nuovo ruolo con i permessi necessari per la github action e una politica di trust che si fida del provider come segue:

{ "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** sia stato autorizzato con un **trigger** specifico.
7. L'**ARN** del **ruolo** che la github action sarà in grado di **impersonare** sarà il "segreto" che la github action deve conoscere, quindi **memorizzarlo** all'interno di un **segreto** all'interno di un **ambiente**.
8. Infine, utilizzare una github action 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

Abuso di OIDC - EKS

L'OpenID Connect (OIDC) è un protocollo di autenticazione e autorizzazione basato su OAuth 2.0 che viene spesso utilizzato per consentire l'accesso federato alle risorse in ambienti cloud come Amazon Elastic Kubernetes Service (EKS). Tuttavia, è possibile sfruttare l'implementazione di OIDC in EKS per ottenere accesso non autorizzato alle risorse.

Scenari di abuso di OIDC in EKS

1. Utilizzo di token scaduti

Se un token OIDC viene compromesso o scade, potrebbe essere possibile utilizzarlo per ottenere accesso non autorizzato alle risorse di EKS. Questo può essere fatto utilizzando il token scaduto per autenticarsi e ottenere un nuovo token valido.

2. Utilizzo di token rubati

Se un token OIDC viene rubato, un attaccante potrebbe utilizzarlo per ottenere accesso non autorizzato alle risorse di EKS. L'attaccante può impersonare l'utente legittimo e utilizzare il token rubato per autenticarsi e ottenere accesso alle risorse.

3. Utilizzo di token non revocati

Se un token OIDC viene revocato, ma il server di autorizzazione non lo riconosce come revocato, potrebbe essere possibile utilizzarlo per ottenere accesso non autorizzato alle risorse di EKS. Questo può accadere se il server di autorizzazione non è correttamente configurato per gestire la revoca dei token.

Contromisure

Per mitigare il rischio di abuso di OIDC in EKS, è consigliabile adottare le seguenti contromisure:

  • Implementare un meccanismo di gestione dei token robusto che includa la revoca dei token scaduti o compromessi.

  • Monitorare attentamente l'attività degli utenti e rilevare eventuali anomalie o accessi non autorizzati.

  • Configurare correttamente il server di autorizzazione per gestire correttamente la revoca dei token.

  • Utilizzare autenticazione a più fattori per aumentare la sicurezza dell'accesso alle risorse di EKS.

Conclusioni

L'abuso di OIDC in EKS può consentire agli attaccanti di ottenere accesso non autorizzato alle risorse. È importante implementare le contromisure appropriate per mitigare questo rischio e proteggere le risorse di 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

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

{
"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 politica 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 viene specificato il nome dell'account di servizio, ad esempio:

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

Riferimenti

Impara l'hacking di AWS da zero a eroe con htARTE (HackTricks AWS Red Team Expert)!

Altri modi per supportare HackTricks:

PreviousAWS - Basic InformationNextAWS - Permissions for a Pentest

Last updated