AWS - Federation Abuse

Reading time: 3 minutes

SAML

Für Informationen über SAML siehe bitte:

SAML Attacks - HackTricks

Um eine Identitätsföderation über SAML zu konfigurieren, müssen Sie lediglich einen Namen und die Metadaten-XML bereitstellen, die alle SAML-Konfigurationen (Endpunkte, Zertifikat mit öffentlichem Schlüssel) enthält.

OIDC - Missbrauch von Github Actions

Um eine Github-Aktion als Identitätsanbieter hinzuzufügen:

1. Wählen Sie für Anbietertyp OpenID Connect aus.
2. Geben Sie für Anbieter-URL https://token.actions.githubusercontent.com ein.
3. Klicken Sie auf Daumenabdruck abrufen, um den Daumenabdruck des Anbieters zu erhalten.
4. Geben Sie für Zielgruppe sts.amazonaws.com ein.
5. Erstellen Sie eine neue Rolle mit den Berechtigungen, die die Github-Aktion benötigt, und einer Vertrauensrichtlinie, die dem Anbieter vertraut, wie:

{ "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. Beachten Sie in der vorherigen Richtlinie, wie nur ein **Branch** aus dem **Repository** einer **Organisation** mit einem bestimmten **Trigger** autorisiert wurde.
7. Der **ARN** der **Rolle**, die die Github-Aktion **nachahmen** kann, wird das "Geheimnis" sein, das die Github-Aktion wissen muss, also **speichern** Sie es in einem **Geheimnis** innerhalb einer **Umgebung**.
8. Verwenden Sie schließlich eine Github-Aktion, um die AWS-Anmeldeinformationen zu konfigurieren, die im Workflow verwendet werden sollen:

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 Missbrauch

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 ist möglich, **OIDC-Anbieter** in einem **EKS**-Cluster zu generieren, indem einfach die **OIDC-URL** des Clusters als **neuer Open ID-Identitätsanbieter** festgelegt wird. Dies ist eine gängige Standardrichtlinie:

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

Diese Richtlinie zeigt korrekt an, dass **nur** der **EKS-Cluster** mit der **ID** `20C159CDF6F2349B68846BEC03BE031B` die Rolle übernehmen kann. Es wird jedoch nicht angegeben, welches Dienstkonto dies übernehmen kann, was bedeutet, dass **JEDES Dienstkonto mit einem Web-Identitätstoken** die Rolle **übernehmen kann**.

Um anzugeben, **welches Dienstkonto die Rolle übernehmen sollte,** ist es erforderlich, eine **Bedingung** anzugeben, in der der **Name des Dienstkontos angegeben ist**, wie zum Beispiel:

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