AWS - Abuso de Federação

Reading time: 3 minutes

SAML

Para informações sobre SAML, consulte:

SAML Attacks - HackTricks

Para configurar uma Federação de Identidade através do SAML, você só precisa fornecer um nome e o XML de metadados contendo toda a configuração SAML (endpoints, certificado com chave pública)

OIDC - Abuso de Github Actions

Para adicionar uma ação do github como provedor de identidade:

1. Para Tipo de provedor, selecione OpenID Connect.
2. Para URL do provedor, insira https://token.actions.githubusercontent.com
3. Clique em Obter impressão digital para obter a impressão digital do provedor
4. Para Público, insira sts.amazonaws.com
5. Crie um novo papel com as permissões que a ação do github precisa e uma política de confiança que confie no provedor 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. Observe na política anterior como apenas uma **branch** do **repositório** de uma **organização** foi autorizada com um **gatilho** específico.
7. O **ARN** do **papel** que a ação do github poderá **impersonar** será o "segredo" que a ação do github precisa saber, então **armazene**-o dentro de um **segredo** em um **ambiente**.
8. Por fim, use uma ação do github para configurar as credenciais da AWS a serem usadas pelo fluxo de trabalho:

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

É possível gerar **OIDC providers** em um **EKS** cluster simplesmente definindo a **OIDC URL** do cluster como um **novo provedor de identidade Open ID**. Esta é uma política padrão comum:

{ "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 está corretamente indicando que **apenas** o **cluster EKS** com **id** `20C159CDF6F2349B68846BEC03BE031B` pode assumir a função. No entanto, não está indicando qual conta de serviço pode assumí-la, o que significa que **QUALQUER conta de serviço com um token de identidade da web** poderá **assumir** a função.

Para especificar **qual conta de serviço deve ser capaz de assumir a função,** é necessário especificar uma **condição** onde o **nome da conta de serviço é especificado**, como:

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