AWS - Federation Abuse

Μάθετε το hacking του AWS από το μηδέν μέχρι τον ήρωα με το htARTE (HackTricks AWS Red Team Expert)!

Άλλοι τρόποι υποστήριξης του HackTricks:

SAML

Για πληροφορίες σχετικά με το SAML, παρακαλούμε ελέγξτε:

Για να διαμορφώσετε μια Ένωση Ταυτότητας μέσω SAML, απλά χρειάζεται να παρέχετε ένα όνομα και το XML μεταδεδομένων που περιέχει όλη τη διαμόρφωση SAML (σημεία έναρξης, πιστοποιητικό με δημόσιο κλειδί)

OIDC - Κατάχρηση Github Actions

Για να προσθέσετε μια ενέργεια github ως πάροχο ταυτότητας:

  1. Για τον Τύπο παρόχου, επιλέξτε OpenID Connect.

  2. Για το URL παρόχου, εισαγάγετε https://token.actions.githubusercontent.com

  3. Κάντε κλικ στο Λήψη αποτυπώματος για να λάβετε το αποτύπωμα του παρόχου

  4. Για το Κοινό, εισαγάγετε sts.amazonaws.com

  5. Δημιουργήστε έναν νέο ρόλο με τα δικαιώματα που χρειάζεται η ενέργεια github και μια πολιτική εμπιστοσύνης που εμπιστεύεται τον πάροχο όπως:

{ "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. Σημειώστε στην προηγούμενη πολιτική πώς εξουσιοδοτήθηκε μόνο ένας **κλαδίς** από το **αποθετήριο** μιας **οργάνωσης** με ένα συγκεκριμένο **σήμα**.
7. Το **ARN** του **ρόλου** που η ενέργεια github θα μπορεί να **προσωποποιήσει** θα είναι το "μυστικό" που η ενέργεια github πρέπει να γνωρίζει, οπότε **αποθηκεύστε** το μέσα σε ένα **μυστικό** μέσα σε ένα **περιβάλλον**.
8. Τέλος, χρησιμοποιήστε μια ενέργεια github για να διαμορφώσετε τα διαπιστευτήρια AWS που θα χρησιμοποιηθούν από τη ροή εργασίας:
```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

Η κατάχρηση του OIDC (OpenID Connect) στο EKS (Elastic Kubernetes Service) είναι μια τεχνική που επιτρέπει σε έναν επιτιθέμενο να αποκτήσει πρόσβαση σε πόρους του EKS χωρίς την απαιτούμενη έγκριση. Αυτό επιτυγχάνεται μέσω της κατασκευής ενός κακόβουλου OIDC παρόχου και της εκμετάλλευσης των αδυναμιών στην υλοποίηση του EKS.

Οι επιτιθέμενοι μπορούν να εκμεταλλευτούν αυτήν την ευπάθεια για να αποκτήσουν πρόσβαση σε ευαίσθητες πληροφορίες, να εκτελέσουν κακόβουλες ενέργειες ή να προκαλέσουν ζημιά στο σύστημα. Για να προστατευτείτε από αυτήν την επίθεση, πρέπει να ελέγξετε τις ρυθμίσεις ασφαλείας του EKS και να εφαρμόσετε τις συστάσεις ασφαλείας που παρέχονται από τον πάροχο υπηρεσιών σας.

Παρακάτω παρέχονται ορισμένα βήματα που μπορείτε να ακολουθήσετε για να προστατευτείτε από την κατάχρηση του OIDC στο EKS:

  1. Ελέγξτε τις ρυθμίσεις ασφαλείας του EKS και βεβαιωθείτε ότι έχετε εφαρμόσει τις συστάσεις ασφαλείας που παρέχονται από τον πάροχο υπηρεσιών σας.

  2. Επιβεβαιώστε ότι ο OIDC πάροχος που χρησιμοποιείτε είναι έγκυρος και ασφαλής. Ελέγξτε τις πιστοποιητικές αρχές που χρησιμοποιούνται και βεβαιωθείτε ότι δεν υπάρχουν γνωστά προβλήματα ασφαλείας.

  3. Εφαρμόστε περιορισμούς πρόσβασης στους πόρους του EKS με βάση τις ανάγκες των χρηστών και των ρόλων τους. Αποφύγετε τη χορήγηση πρόσβασης μεγαλύτερης από αυτήν που απαιτείται για την εκτέλεση των καθηκόντων τους.

  4. Παρακολουθείτε τα αρχεία καταγραφής και τις αναφορές ασφαλείας για τυχόν ανωμαλίες ή αποτυχημένες προσπάθειες πρόσβασης.

  5. Εκπαιδεύστε τους χρήστες και το προσωπικό σας σχετικά με τις βασικές αρχές ασφαλείας και τις προφυλάξεις που πρέπει να λαμβάνονται για την προστασία του EKS.

Ακολουθώντας αυτά τα βήματα, μπορείτε να μειώσετε τον κίνδυνο κατάχρησης του OIDC στο EKS και να προστατεύσετε το σύστημά σας από ανεπιθύμητη πρόσβαση και επιθέσεις.

# 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

Είναι δυνατόν να δημιουργηθούν παροχείς OIDC σε ένα cluster EKS απλά ορίζοντας το URL OIDC του cluster ως έναν νέο πάροχο Open ID Identity. Αυτό είναι ένα κοινό προεπιλεγμένο πολιτική:

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

Αυτή η πολιτική υποδεικνύει σωστά ότι μόνο το EKS cluster με το id 20C159CDF6F2349B68846BEC03BE031B μπορεί να υποθέσει τον ρόλο. Ωστόσο, δεν υποδεικνύει ποιος λογαριασμός υπηρεσίας μπορεί να τον υποθέσει, πράγμα που σημαίνει ότι ΟΠΟΙΟΣΔΗΠΟΤΕ λογαριασμός υπηρεσίας με ένα web identity token θα μπορεί να υποθέσει τον ρόλο.

Για να καθοριστεί ποιος λογαριασμός υπηρεσίας πρέπει να μπορεί να υποθέσει τον ρόλο, είναι απαραίτητο να καθοριστεί μια συνθήκη όπου καθορίζεται το όνομα του λογαριασμού υπηρεσίας, όπως:

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

Αναφορές

Μάθετε το hacking στο AWS από το μηδέν μέχρι τον ήρωα με το htARTE (HackTricks AWS Red Team Expert)!

Άλλοι τρόποι για να υποστηρίξετε το HackTricks:

Last updated