AWS - Federation Abuse

Leer AWS-hacking vanaf nul tot held met htARTE (HackTricks AWS Red Team Expert)!

Ander maniere om HackTricks te ondersteun:

SAML

Vir inligting oor SAML, kyk asseblief:

Om 'n Identiteitsfederasie deur SAML te konfigureer, hoef jy net 'n naam en die metadata XML te voorsien wat al die SAML-konfigurasie bevat (eindpunte, sertifikaat met openbare sleutel)

OIDC - Github Aksie Misbruik

Om 'n github-aksie as Identiteitsverskaffer by te voeg:

  1. Vir Verskafferstipe, kies OpenID Connect.

  2. Vir Verskaffer-URL, voer https://token.actions.githubusercontent.com in.

  3. Klik op Kry duimafdruk om die duimafdruk van die verskaffer te kry.

  4. Vir Gehoor, voer sts.amazonaws.com in.

  5. Skep 'n nuwe rol met die regte wat die github-aksie nodig het en 'n vertrouensbeleid wat die verskaffer vertrou, soos:

{ "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. Let in die vorige beleid daarop dat slegs 'n **tak** van 'n **repository** van 'n **organisasie** geoutoriseer is met 'n spesifieke **trigger**.
7. Die **ARN** van die **rol** wat die github-aksie in staat gaan wees om **voor te gee**, gaan die "geheim" wees wat die github-aksie moet weet, so **stoor** dit binne 'n **geheim** binne 'n **omgewing**.
8. Gebruik uiteindelik 'n github-aksie om die AWS-credentials te konfigureer wat deur die werkstroom gebruik moet word:
```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 Misbruik

Inleiding

OpenID Connect (OIDC) is een identiteitslaag bovenop het OAuth 2.0-protocol. Het wordt vaak gebruikt voor authenticatie en autorisatie in cloudomgevingen, waaronder Amazon Elastic Kubernetes Service (EKS). EKS maakt gebruik van OIDC om externe identiteitsproviders te integreren voor het beheren van toegang tot Kubernetes-clusters.

Misbruikscenario's

1. Onjuiste configuratie van OIDC

Een veelvoorkomende fout is het verkeerd configureren van OIDC in EKS. Dit kan leiden tot onbedoelde toegang tot het Kubernetes-cluster. Een aanvaller kan profiteren van deze fout door zich voor te doen als een externe identiteitsprovider en toegang te krijgen tot het cluster.

2. Onjuiste toewijzing van IAM-rollen

EKS maakt gebruik van IAM-rollen (Identity and Access Management) om toegang te beheren. Als de IAM-rollen onjuist zijn toegewezen, kan een aanvaller mogelijk toegang krijgen tot gevoelige bronnen in het cluster. Dit kan leiden tot gegevensdiefstal, gegevenswijziging of zelfs het overnemen van het cluster.

3. Onjuiste toegangscontrolebeleid

Het toegangscontrolebeleid in EKS bepaalt welke acties een gebruiker kan uitvoeren in het cluster. Als het beleid onjuist is geconfigureerd, kan een aanvaller mogelijk ongeautoriseerde acties uitvoeren, zoals het maken van nieuwe pods, het wijzigen van configuraties of het verwijderen van bronnen.

Aanbevelingen

Om misbruik van OIDC in EKS te voorkomen, worden de volgende aanbevelingen gedaan:

  1. Zorg ervoor dat OIDC correct is geconfigureerd volgens de documentatie van EKS.

  2. Controleer regelmatig de toewijzing van IAM-rollen en zorg ervoor dat alleen de juiste rollen zijn toegewezen aan gebruikers en services.

  3. Beperk de rechten van IAM-rollen tot wat strikt noodzakelijk is voor de uitvoering van taken.

  4. Implementeer een strikt toegangscontrolebeleid en controleer regelmatig op ongeautoriseerde acties.

  5. Houd de EKS-documentatie en beveiligingsupdates bij om op de hoogte te blijven van eventuele nieuwe beveiligingsrisico's en aanbevolen maatregelen.

Door deze aanbevelingen op te volgen, kunt u de beveiliging van uw EKS-cluster verbeteren en het risico op misbruik van OIDC verminderen.

# 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

Dit is moontlik om OIDC-verskaffers in 'n EKS-kluster te genereer deur eenvoudigweg die OIDC-URL van die kluster as 'n nuwe Open ID Identity-verskaffer in te stel. Dit is 'n algemene verstekbeleid:

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

Hierdie beleid dui korrek aan dat slegs die EKS-kluster met die id 20C159CDF6F2349B68846BEC03BE031B die rol kan aanneem. Dit dui egter nie aan watter diensrekening dit kan aanneem nie, wat beteken dat ENIGE diensrekening met 'n web-identiteits-token die rol kan aanneem.

Om spesifiek aan te dui watter diensrekening die rol kan aanneem, moet 'n voorwaarde gespesifiseer word waar die diensrekeningnaam gespesifiseer word, soos:

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

Verwysings

Leer AWS-hacking van nul tot held met htARTE (HackTricks AWS Red Team Expert)!

Ander maniere om HackTricks te ondersteun:

Last updated