Español - Ht Cloud
HackTricks TrainingTwitterLinkedinSponsor

AWS - Federation Abuse

Apoya a HackTricks

SAML

Para información sobre SAML, por favor revisa:

Para configurar una Federación de Identidad a través de SAML, solo necesitas proporcionar un nombre y el XML de metadatos que contenga toda la configuración de SAML (puntos finales, certificado con clave pública)

OIDC - Abuso de Github Actions

Para agregar una acción de github como proveedor de identidad:

  1. Para Tipo de proveedor, selecciona OpenID Connect.

  2. Para URL del proveedor, ingresa https://token.actions.githubusercontent.com

  3. Haz clic en Obtener huella digital para obtener la huella digital del proveedor

  4. Para Audiencia, ingresa sts.amazonaws.com

  5. Crea un nuevo rol con los permisos que necesita la acción de github y una política de confianza que confíe en el proveedor como:

{ "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 en la política anterior cómo solo se autorizó una **rama** de un **repositorio** de una **organización** con un **disparador** específico.
7. El **ARN** del **rol** que la acción de github podrá **suplantar** será el "secreto" que la acción de github necesita conocer, así que **almacénalo** dentro de un **secreto** dentro de un **entorno**.
8. Finalmente, usa una acción de github para configurar las credenciales de AWS que serán utilizadas por el flujo de trabajo:
```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 - Abuso de 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

Es posible generar OIDC providers en un EKS cluster simplemente configurando la OIDC URL del cluster como un nuevo proveedor de identidad Open ID. Esta es una política predeterminada común:

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

Esta política indica correctamente que solo el clúster EKS con id 20C159CDF6F2349B68846BEC03BE031B puede asumir el rol. Sin embargo, no indica qué cuenta de servicio puede asumirlo, lo que significa que CUALQUIER cuenta de servicio con un token de identidad web podrá asumir el rol.

Para especificar qué cuenta de servicio debería poder asumir el rol, es necesario especificar una condición donde se especifica el nombre de la cuenta de servicio, como:

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

Referencias

Apoya a HackTricks
PreviousAWS - Basic InformationNextAWS - Permissions for a Pentest

Last updated