AWS - Federation Abuse

Aprende hacking de AWS de cero a héroe con htARTE (HackTricks AWS Red Team Expert)!

Otras formas de apoyar 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 contiene toda la configuración de SAML (puntos finales, certificado con clave pública)

OIDC - Abuso de Github Actions

Para añadir una acción de github como proveedor de identidad:

  1. Para Tipo de proveedor, selecciona OpenID Connect.

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

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

  4. Para Audiencia, introduce sts.amazonaws.com

  5. Crea un nuevo rol con los permisos que la acción de github necesita 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. Observa en la política anterior cómo solo una **rama** de un **repositorio** de una **organización** fue autorizada con un **disparador** específico.
7. El **ARN** del **rol** que la acción de github podrá **impersonar** será el "secreto" que la acción de github necesita saber, 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 clúster EKS simplemente configurando la OIDC URL del clúster como un nuevo Open ID Identity provider. 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 EKS cluster 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 va a ser capaz de asumir el rol.

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

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

Aprende hacking en AWS de cero a héroe con htARTE (HackTricks AWS Red Team Expert)!

Otras formas de apoyar a HackTricks:

Última actualización