Polish - Ht Cloud
HackTricks Training Twitter Linkedin Sponsor

AWS - Federation Abuse

Dowiedz się, jak hakować AWS od zera do bohatera z htARTE (HackTricks AWS Red Team Expert)!

Inne sposoby wsparcia HackTricks:

SAML

Aby uzyskać informacje na temat SAML, sprawdź:

Aby skonfigurować federację tożsamości za pomocą SAML, wystarczy podać nazwę i metadane XML zawierające konfigurację SAML (punkty końcowe, certyfikat z kluczem publicznym).

OIDC - Nadużycie Github Actions

Aby dodać akcję Github jako dostawcę tożsamości:

  1. Dla Typu dostawcy wybierz OpenID Connect.

  2. Dla Adresu URL dostawcy wprowadź https://token.actions.githubusercontent.com.

  3. Kliknij Pobierz odcisk palca, aby uzyskać odcisk palca dostawcy.

  4. Dla Odbiorcy wprowadź sts.amazonaws.com.

  5. Utwórz nową rolę z uprawnieniami, których potrzebuje akcja Github, oraz polityką zaufania, która ufa dostawcy, na przykład:

{ "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. Zauważ w poprzedniej polityce, że autoryzowano tylko **gałąź** z **repozytorium** organizacji za pomocą określonego **wyzwalacza**.
7. **ARN** roli, którą akcja Github będzie mogła **udawać**, będzie "tajemnicą", którą akcja Github musi znać, więc **przechowaj** ją wewnątrz **sekretnego** środowiska.
8. Na koniec użyj akcji Github do skonfigurowania poświadczeń AWS, które mają być używane przez workflow:
```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

Nadużycie OIDC - EKS

W przypadku usługi Amazon Elastic Kubernetes Service (EKS), OIDC (OpenID Connect) jest mechanizmem uwierzytelniania, który umożliwia federację tożsamości między klastrami EKS a innymi usługami AWS. Jednakże, jeśli nie jest odpowiednio skonfigurowany, może prowadzić do potencjalnych nadużyć.

Zagrożenia

  1. Podstawowe nadużycie: Jeśli atakujący uzyska dostęp do tokena OIDC, może użyć go do uwierzytelnienia się w innych usługach AWS, które zaufają temu tokenowi. To może prowadzić do nieautoryzowanego dostępu do zasobów w chmurze.

  2. Przechwytywanie tokena: Atakujący może przechwycić token OIDC, który jest przesyłany między klastrami EKS a usługami AWS. To umożliwia mu uzyskanie dostępu do tych usług, które zaufają temu tokenowi.

Zabezpieczenia

Aby zabezpieczyć się przed nadużyciem OIDC w EKS, należy podjąć następujące kroki:

  1. Ograniczenie uprawnień: Upewnij się, że role IAM przypisane do klastra EKS mają odpowiednio ograniczone uprawnienia. Unikaj nadawania zbyt szerokich uprawnień, które mogą umożliwić nieautoryzowany dostęp.

  2. Monitorowanie: Regularnie monitoruj logi zdarzeń w celu wykrywania podejrzanej aktywności. W przypadku wykrycia nieautoryzowanego dostępu lub prób przechwycenia tokena OIDC, podjęcie odpowiednich działań naprawczych.

  3. Aktualizacje: Upewnij się, że oprogramowanie EKS jest regularnie aktualizowane, aby korzystać z najnowszych poprawek zabezpieczeń.

  4. Bezpieczne praktyki uwierzytelniania: Wdrażaj silne hasła, wielopoziomowe uwierzytelnianie i inne bezpieczne praktyki uwierzytelniania, aby utrudnić atakującym uzyskanie dostępu do tokena OIDC.

  5. Audyt konfiguracji: Regularnie przeglądaj i audytuj konfigurację OIDC w celu upewnienia się, że jest ona poprawnie skonfigurowana i nie ma żadnych luk w zabezpieczeniach.

Podsumowanie

OIDC w EKS jest potężnym narzędziem do federacji tożsamości, ale wymaga odpowiedniej konfiguracji i zabezpieczeń. Przestrzeganie najlepszych praktyk bezpieczeństwa i regularne monitorowanie są kluczowe dla zapewnienia bezpieczeństwa klastra EKS i uniknięcia nadużyć OIDC.

# 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

Możliwe jest wygenerowanie dostawców OIDC w klastrze EKS, po prostu ustawiając URL OIDC klastra jako nowego dostawcy tożsamości Open ID. Jest to powszechna domyślna polityka:

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

Ta polityka poprawnie wskazuje, że tylko klastr EKS o identyfikatorze 20C159CDF6F2349B68846BEC03BE031B może przejąć rolę. Jednak nie wskazuje, który konta usługi mogą ją przejąć, co oznacza, że DOWOLNE konto usługi z tokenem tożsamości sieciowej będzie mogło przejąć tę rolę.

Aby określić, które konto usługi powinno móc przejąć rolę, należy określić warunek, w którym nazwa konta usługi jest określona, na przykład:

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

Odwołania

Naucz się hakować AWS od zera do bohatera z htARTE (HackTricks AWS Red Team Expert)!

Inne sposoby wsparcia HackTricks:

PreviousAWS - Basic InformationNextAWS - Permissions for a Pentest

Last updated