AWS - Federation Abuse

Support HackTricks

SAML

Für Informationen über SAML siehe bitte:

Um eine Identitätsföderation über SAML zu konfigurieren, musst du nur einen Namen und die Metadata-XML bereitstellen, die alle SAML-Konfigurationen enthält (Endpunkte, Zertifikat mit öffentlichem Schlüssel)

OIDC - Github Actions Abuse

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

  1. Wähle für Anbietertyp OpenID Connect.

  2. Gib für Anbieter-URL https://token.actions.githubusercontent.com ein.

  3. Klicke auf Daumenabdruck abrufen, um den Daumenabdruck des Anbieters zu erhalten.

  4. Gib für Zielgruppe sts.amazonaws.com ein.

  5. Erstelle 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. Beachte in der vorherigen Richtlinie, wie nur ein **Branch** aus dem **Repository** einer **Organisation** mit einem spezifischen **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 **speichere** es in einem **Geheimnis** innerhalb einer **Umgebung**.
8. Verwende schließlich eine Github-Aktion, um die AWS-Credentials zu konfigurieren, die im Workflow verwendet werden sollen:
```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 - 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 können sollte, ist es notwendig, eine Bedingung anzugeben, in der der Dienstkontoname angegeben ist, wie zum Beispiel:

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

Referenzen

Unterstütze HackTricks

Last updated