AuthZ& AuthN - Docker Access Authorization Plugin
Last updated
Last updated
Learn & practice AWS Hacking:HackTricks Training AWS Red Team Expert (ARTE) Learn & practice GCP Hacking: HackTricks Training GCP Red Team Expert (GRTE)
Το μοντέλο εξουσιοδότησης του Docker είναι όλα ή τίποτα. Οποιοσδήποτε χρήστης έχει άδεια πρόσβασης στον Docker daemon μπορεί να εκτελέσει οποιαδήποτε εντολή Docker client. Το ίδιο ισχύει και για τους καλούντες που χρησιμοποιούν το Engine API του Docker για να επικοινωνήσουν με τον daemon. Εάν απαιτείτε μεγαλύτερο έλεγχο πρόσβασης, μπορείτε να δημιουργήσετε plugins εξουσιοδότησης και να τα προσθέσετε στη διαμόρφωση του Docker daemon σας. Χρησιμοποιώντας ένα plugin εξουσιοδότησης, ένας διαχειριστής Docker μπορεί να διαμορφώσει λεπτομερείς πολιτικές πρόσβασης για τη διαχείριση της πρόσβασης στον Docker daemon.
Τα Docker Auth plugins είναι εξωτερικά plugins που μπορείτε να χρησιμοποιήσετε για να επιτρέψετε/αρνηθείτε ενέργειες που ζητούνται από τον Docker Daemon ανάλογα με τον χρήστη που το ζήτησε και την ενέργεια που ζητήθηκε.
Οι παρακάτω πληροφορίες προέρχονται από τα docs
Όταν γίνεται ένα HTTP αίτημα στον Docker daemon μέσω του CLI ή μέσω του Engine API, το υποσύστημα authentication περνά το αίτημα στα εγκατεστημένα plugins authentication. Το αίτημα περιέχει τον χρήστη (καλούντα) και το πλαίσιο εντολής. Το plugin είναι υπεύθυνο για την απόφαση αν θα επιτρέψει ή θα αρνηθεί το αίτημα.
Τα διαγράμματα ακολουθίας παρακάτω απεικονίζουν μια ροή εξουσιοδότησης επιτρεπόμενης και αρνητικής:
Κάθε αίτημα που αποστέλλεται στο plugin περιλαμβάνει τον αυθεντικοποιημένο χρήστη, τις HTTP κεφαλίδες και το σώμα του αιτήματος/απάντησης. Μόνο το όνομα χρήστη και η μέθοδος αυθεντικοποίησης που χρησιμοποιείται περνούν στο plugin. Το πιο σημαντικό, κανένα διαπιστευτήριο χρήστη ή tokens δεν περνούν. Τέλος, όχι όλα τα σώματα αιτήματος/απάντησης αποστέλλονται στο plugin εξουσιοδότησης. Μόνο εκείνα τα σώματα αιτήματος/απάντησης όπου το Content-Type
είναι είτε text/*
είτε application/json
αποστέλλονται.
Για εντολές που μπορεί να καταλάβουν τη σύνδεση HTTP (HTTP Upgrade
), όπως το exec
, το plugin εξουσιοδότησης καλείται μόνο για τα αρχικά HTTP αιτήματα. Μόλις το plugin εγκρίνει την εντολή, η εξουσιοδότηση δεν εφαρμόζεται στην υπόλοιπη ροή. Συγκεκριμένα, τα δεδομένα ροής δεν περνούν στα plugins εξουσιοδότησης. Για εντολές που επιστρέφουν τμηματική HTTP απάντηση, όπως το logs
και το events
, μόνο το HTTP αίτημα αποστέλλεται στα plugins εξουσιοδότησης.
Κατά τη διάρκεια της επεξεργασίας αιτήματος/απάντησης, ορισμένες ροές εξουσιοδότησης μπορεί να χρειαστεί να κάνουν επιπλέον ερωτήματα στον Docker daemon. Για να ολοκληρωθούν αυτές οι ροές, τα plugins μπορούν να καλέσουν το daemon API όπως ένας κανονικός χρήστης. Για να επιτραπούν αυτές οι επιπλέον ερωτήσεις, το plugin πρέπει να παρέχει τα μέσα για έναν διαχειριστή να διαμορφώσει κατάλληλες πολιτικές αυθεντικοποίησης και ασφάλειας.
Είστε υπεύθυνοι για την καταχώριση του plugin σας ως μέρος της εκκίνησης του Docker daemon. Μπορείτε να εγκαταστήσετε πολλαπλά plugins και να τα αλυσσοδέσετε. Αυτή η αλυσίδα μπορεί να είναι διατεταγμένη. Κάθε αίτημα προς τον daemon περνά με σειρά μέσω της αλυσίδας. Μόνο όταν όλα τα plugins παραχωρήσουν πρόσβαση στο πόρο, η πρόσβαση παραχωρείται.
Το plugin authz σας επιτρέπει να δημιουργήσετε ένα απλό JSON αρχείο που το plugin θα διαβάζει για να εξουσιοδοτήσει τα αιτήματα. Έτσι, σας δίνει την ευκαιρία να ελέγξετε πολύ εύκολα ποια API endpoints μπορεί να προσεγγίσει κάθε χρήστης.
Αυτό είναι ένα παράδειγμα που θα επιτρέπει στους Alice και Bob να δημιουργήσουν νέα κοντέινερ: {"name":"policy_3","users":["alice","bob"],"actions":["container_create"]}
Στη σελίδα route_parser.go μπορείτε να βρείτε τη σχέση μεταξύ της ζητούμενης URL και της εντολής. Στη σελίδα types.go μπορείτε να βρείτε τη σχέση μεταξύ του ονόματος της εντολής και της εντολής.
Μπορείτε να βρείτε ένα εύκολο στην κατανόηση plugin με λεπτομερείς πληροφορίες σχετικά με την εγκατάσταση και την αποσφαλμάτωση εδώ: https://github.com/carlospolop-forks/authobot
Διαβάστε το README
και τον κώδικα plugin.go
για να κατανοήσετε πώς λειτουργεί.
Τα κύρια πράγματα που πρέπει να ελέγξετε είναι ποια endpoints επιτρέπονται και ποια τιμές του HostConfig επιτρέπονται.
Για να εκτελέσετε αυτή την καταμέτρηση μπορείτε να χρησιμοποιήσετε το εργαλείο https://github.com/carlospolop/docker_auth_profiler.
run --privileged
In this case the sysadmin απαγόρευσε στους χρήστες να προσαρτούν τόμους και να εκτελούν κοντέινερ με την επιλογή --privileged
ή να δίνουν οποιαδήποτε επιπλέον δυνατότητα στο κοντέινερ:
Ωστόσο, ένας χρήστης μπορεί να δημιουργήσει ένα shell μέσα στο τρέχον κοντέινερ και να του δώσει τα επιπλέον δικαιώματα:
Τώρα, ο χρήστης μπορεί να διαφύγει από το κοντέινερ χρησιμοποιώντας οποιαδήποτε από τις προηγουμένως συζητηθείσες τεχνικές και να κλιμακώσει τα δικαιώματα μέσα στον οικοδεσπότη.
Σε αυτή την περίπτωση, ο διαχειριστής συστήματος απαγόρευσε στους χρήστες να εκτελούν κοντέινερ με την επιλογή --privileged
ή να δίνουν οποιαδήποτε επιπλέον ικανότητα στο κοντέινερ, και επέτρεψε μόνο την τοποθέτηση του φακέλου /tmp
:
Σημειώστε ότι ίσως δεν μπορείτε να προσαρτήσετε τον φάκελο /tmp
, αλλά μπορείτε να προσαρτήσετε έναν διαφορετικό εγγράψιμο φάκελο. Μπορείτε να βρείτε εγγράψιμους καταλόγους χρησιμοποιώντας: find / -writable -type d 2>/dev/null
Σημειώστε ότι δεν υποστηρίζουν όλοι οι κατάλογοι σε μια μηχανή linux το suid bit! Για να ελέγξετε ποιους καταλόγους υποστηρίζει το suid bit, εκτελέστε mount | grep -v "nosuid"
. Για παράδειγμα, συνήθως οι /dev/shm
, /run
, /proc
, /sys/fs/cgroup
και /var/lib/lxcfs
δεν υποστηρίζουν το suid bit.
Σημειώστε επίσης ότι αν μπορείτε να προσαρτήσετε το /etc
ή οποιονδήποτε άλλο φάκελο που περιέχει αρχεία ρυθμίσεων, μπορείτε να τα αλλάξετε από το docker container ως root προκειμένου να τα εκμεταλλευτείτε στον host και να κερδίσετε δικαιώματα (ίσως τροποποιώντας το /etc/shadow
)
Η ευθύνη του sysadmin που ρυθμίζει αυτό το plugin θα ήταν να ελέγχει ποιες ενέργειες και με ποια δικαιώματα μπορεί να εκτελεί κάθε χρήστης. Επομένως, αν ο διαχειριστής ακολουθήσει μια προσέγγιση μαύρης λίστας με τα endpoints και τα χαρακτηριστικά, μπορεί να ξεχάσει μερικά από αυτά που θα μπορούσαν να επιτρέψουν σε έναν επιτιθέμενο να κερδίσει δικαιώματα.
Μπορείτε να ελέγξετε το docker API στο https://docs.docker.com/engine/api/v1.40/#
Είναι πιθανό ότι όταν ο sysadmin ρύθμισε το docker firewall, ξέχασε κάποια σημαντική παράμετρο του API όπως το "Binds". Στο παρακάτω παράδειγμα είναι δυνατόν να εκμεταλλευτείτε αυτή τη λανθασμένη ρύθμιση για να δημιουργήσετε και να εκτελέσετε ένα container που προσαρτά τον φάκελο root (/) του host:
Σημειώστε πώς σε αυτό το παράδειγμα χρησιμοποιούμε το Binds
παραμέτρο ως κλειδί επιπέδου ρίζας στο JSON αλλά στην API εμφανίζεται κάτω από το κλειδί HostConfig
Ακολουθήστε τις ίδιες οδηγίες όπως με Binds in root εκτελώντας αυτή την αίτηση στην Docker API:
Ακολουθήστε τις ίδιες οδηγίες όπως με Binds in root εκτελώντας αυτήν την αίτηση στο Docker API:
Ακολουθήστε τις ίδιες οδηγίες όπως με Binds in root εκτελώντας αυτήν την αίτηση στο Docker API:
Είναι πιθανό ότι όταν ο διαχειριστής συστήματος ρύθμισε το docker firewall ξέχασε κάποιο σημαντικό χαρακτηριστικό μιας παραμέτρου του API όπως το "Capabilities" μέσα στο "HostConfig". Στο παρακάτω παράδειγμα είναι δυνατόν να εκμεταλλευτεί αυτή τη λανθασμένη ρύθμιση για να δημιουργηθεί και να εκτελεστεί ένα κοντέινερ με την ικανότητα SYS_MODULE:
Η HostConfig
είναι το κλειδί που συνήθως περιέχει τα ενδιαφέροντα προνόμια για να ξεφύγετε από το κοντέινερ. Ωστόσο, όπως έχουμε συζητήσει προηγουμένως, σημειώστε πώς η χρήση Binds εκτός αυτού λειτουργεί επίσης και μπορεί να σας επιτρέψει να παρακάμψετε περιορισμούς.
Εάν ο διαχειριστής συστήματος ξέχασε να απαγορεύσει την ικανότητα να απενεργοποιήσετε το πρόσθετο, μπορείτε να εκμεταλλευτείτε αυτό για να το απενεργοποιήσετε εντελώς!
Θυμηθείτε να επανενεργοποιήσετε το plugin μετά την κλιμάκωση, αλλιώς μια επανεκκίνηση της υπηρεσίας docker δεν θα λειτουργήσει!
Μάθετε & εξασκηθείτε στο AWS Hacking:HackTricks Training AWS Red Team Expert (ARTE) Μάθετε & εξασκηθείτε στο GCP Hacking: HackTricks Training GCP Red Team Expert (GRTE)