Docker Breakout / Privilege Escalation
Last updated
Last updated
Μάθε & εξάσκησε το Hacking στο AWS:Εκπαίδευση HackTricks AWS Red Team Expert (ARTE) Μάθε & εξάσκησε το Hacking στο GCP: Εκπαίδευση HackTricks GCP Red Team Expert (GRTE)
Χρησιμοποιήστε το Trickest για να δημιουργήσετε εύκολα και να αυτοματοποιήσετε ροές εργασίας με τα πιο προηγμένα εργαλεία της κοινότητας. Αποκτήστε πρόσβαση σήμερα:
linpeas: Μπορεί επίσης να απαριθμήσει containers
CDK: Αυτό το εργαλείο είναι αρκετά χρήσιμο για την απαρίθμηση του container στο οποίο βρίσκεστε και ακόμα να προσπαθήσετε να αποδράσετε αυτόματα
amicontained: Χρήσιμο εργαλείο για να πάρετε τα προνόμια που έχει το container προκειμένου να βρείτε τρόπους απόδρασης από αυτό
deepce: Εργαλείο για απαρίθμηση και απόδραση από containers
grype: Πάρτε τα CVEs που περιέχονται στο λογισμικό που είναι εγκατεστημένο στην εικόνα
Αν κάπως βρείτε ότι το docker socket είναι συνδεδεμένο μέσα στο docker container, θα μπορείτε να αποδράσετε από αυτό. Αυτό συμβαίνει συνήθως σε docker containers που για κάποιο λόγο χρειάζεται να συνδεθεί στον docker daemon για να εκτελέσει ενέργειες.
Σε αυτήν την περίπτωση μπορείτε να χρησιμοποιήσετε τα κανονικά εντολές docker για να επικοινωνήσετε με τον docker daemon:
Σε περίπτωση που το docker socket βρίσκεται σε μη αναμενόμενη θέση μπορείτε ακόμα να επικοινωνήσετε μαζί του χρησιμοποιώντας την εντολή docker
με την παράμετρο -H unix:///path/to/docker.sock
Το Docker daemon ενδέχεται επίσης να ακούει σε ένα θύρα (προεπιλεγμένα 2375, 2376) ή σε συστήματα βασισμένα σε Systemd, η επικοινωνία με το Docker daemon μπορεί να γίνει μέσω του Systemd socket fd://
.
Επιπλέον, προσέξτε τα sockets εκτέλεσης άλλων υψηλού επιπέδου εκτελέσεων:
dockershim: unix:///var/run/dockershim.sock
containerd: unix:///run/containerd/containerd.sock
cri-o: unix:///var/run/crio/crio.sock
frakti: unix:///var/run/frakti.sock
rktlet: unix:///var/run/rktlet.sock
...
Θα πρέπει να ελέγξετε τις δυνατότητες του container, αν έχει οποιαδήποτε από τις παρακάτω, ενδέχεται να μπορείτε να δραπετεύσετε από αυτό: CAP_SYS_ADMIN
, CAP_SYS_PTRACE
, CAP_SYS_MODULE
, DAC_READ_SEARCH
, DAC_OVERRIDE, CAP_SYS_RAWIO
, CAP_SYSLOG
, CAP_NET_RAW
, CAP_NET_ADMIN
Μπορείτε να ελέγξετε τις τρέχουσες δυνατότητες του container χρησιμοποιώντας τα προαναφερθέντα αυτόματα εργαλεία ή:
Στην ακόλουθη σελίδα μπορείτε να μάθετε περισσότερα σχετικά με τις δυνατότητες του Linux και πώς να τις καταχραστείτε για να δραπετεύσετε/αναβαθμίσετε προνομιακά δικαιώματα:
Linux CapabilitiesΈνα προνομιούχος ελεγκτής μπορεί να δημιουργηθεί με τη σημαία --privileged
ή απενεργοποιώντας συγκεκριμένες αμυντικές μέτρησεις:
--cap-add=ALL
--security-opt apparmor=unconfined
--security-opt seccomp=unconfined
--security-opt label:disable
--pid=host
--userns=host
--uts=host
--cgroupns=host
Mount /dev
Η σημαία --privileged
μειώνει σημαντικά την ασφάλεια του container, προσφέροντας απεριόριστη πρόσβαση σε συσκευές και παρακάμπτοντας πολλές προστασίες. Για λεπτομερή ανάλυση, ανατρέξτε στην τεκμηρίωση για τις πλήρεις επιπτώσεις της --privileged
.
Με αυτές τις άδειες μπορείτε απλά να μεταβείτε στο namespace ενός διεργασίας που εκτελείται στον κεντρικό υπολογιστή ως ριζοχρήστης όπως το init (pid:1) απλά εκτελώντας: nsenter --target 1 --mount --uts --ipc --net --pid -- bash
Δοκιμάστε το σε ένα container εκτελώντας:
Απλά με τη σημαία προνομίων μπορείτε να δοκιμάσετε να έχετε πρόσβαση στο δίσκο του υπολογιστή ή να δραπετεύσετε καταχρώμενοι το release_agent ή άλλες διαφυγές.
Δοκιμάστε τις παρακάτω παρακάμψεις σε ένα container εκτελώντας:
Οι ρυθμισμένες σωστά docker containers δεν θα επιτρέψουν εντολές όπως fdisk -l. Ωστόσο, σε docker εντολές που έχουν ρυθμιστεί λανθασμένα όπου ορίζεται η σημαία --privileged
ή --device=/dev/sda1
με κεφαλαία γράμματα, είναι δυνατόν να αποκτηθούν δικαιώματα για να δείτε τον δίσκο του κεντρικού υπολογιστή.
Έτσι, για να πάρετε τον έλεγχο του κεντρικού υπολογιστή, είναι ασήμαντο:
Και ορίστε! Τώρα μπορείτε να έχετε πρόσβαση στο σύστημα αρχείων του κεντρικού υπολογιστή επειδή είναι προσαρτημένο στον φάκελο /mnt/hola
.
Μέσα στο container, ένας επιτιθέμενος μπορεί να προσπαθήσει να κερδίσει περαιτέρω πρόσβαση στο υποκείμενο λειτουργικό σύστημα του κεντρικού υπολογιστή μέσω ενός εγγράψιμου όγκου hostPath που δημιουργήθηκε από το cluster. Παρακάτω είναι μερικά κοινά πράγματα που μπορείτε να ελέγξετε μέσα στο container για να δείτε αν μπορείτε να εκμεταλλευτείτε αυτό το διάνυσμα του επιτιθέμενου:
Βρείτε μια εξήγηση της τεχνικής στο:
Docker release_agent cgroups escapeΣτις προηγούμενες εκμεταλλεύσεις, η απόλυτη διαδρομή του container μέσα στο σύστημα αρχείων των hosts αποκαλύπτεται. Ωστόσο, αυτό δεν συμβαίνει πάντα. Σε περιπτώσεις όπου δεν γνωρίζετε την απόλυτη διαδρομή του container μέσα στον host μπορείτε να χρησιμοποιήσετε αυτήν την τεχνική:
release_agent exploit - Relative Paths to PIDsΗ εκτέλεση του PoC εντός ενός προνομιούχου container θα πρέπει να παρέχει έξοδο παρόμοια με:
Υπάρχουν αρκετά αρχεία που μπορεί να τοποθετηθούν και δίνουν πληροφορίες σχετικά με τον υποκείμενο κεντρικό υπολογιστή. Κάποια από αυτά μπορεί ακόμα να υποδεικνύουν κάτι που πρέπει να εκτελεστεί από τον κεντρικό υπολογιστή όταν συμβεί κάτι (το οποίο θα επιτρέψει σε έναν επιτιθέμενο να δραπετεύσει από τον εμπλεκόμενο δοχείο). Η κατάχρηση αυτών των αρχείων μπορεί να επιτρέψει:
release_agent (ήδη καλυμμένο προηγουμένως)
Ωστόσο, μπορείτε να βρείτε άλλα ευαίσθητα αρχεία για έλεγχο σε αυτήν τη σελίδα:
Sensitive MountsΣε πολλές περιπτώσεις θα διαπιστώσετε ότι το δοχείο έχει κάποιον όγκο τοποθετημένο από τον κεντρικό υπολογιστή. Εάν αυτός ο όγκος δεν έχει ρυθμιστεί σωστά, ενδέχεται να μπορείτε να έχετε πρόσβαση/τροποποιήσετε ευαίσθητα δεδομένα: Διαβάστε μυστικά, αλλάξτε τα authorized_keys του ssh...
Εάν έχετε πρόσβαση ως root μέσα σε ένα container που έχει κάποιο φάκελο από τον host που έχει προσαρτηθεί και έχετε δραπετεύσει ως μη προνομιούχος χρήστης στον host και έχετε πρόσβαση ανάγνωσης στον προσαρτημένο φάκελο. Μπορείτε να δημιουργήσετε ένα αρχείο bash suid στον προσαρτημένο φάκελο μέσα στο container και να το εκτελέσετε από τον host για προνομιούχο ανέλιξη.
Εάν έχετε πρόσβαση ως root μέσα σε ένα container και έχετε δραπετεύσει ως μη προνομιούχος χρήστης στον host, μπορείτε να καταχραστείτε και τα δύο κελύφη για εξέλιξη προνομίων μέσα στον host αν έχετε τη δυνατότητα MKNOD μέσα στο container (είναι εξ' ορισμού) όπως εξηγείται σε αυτή την ανάρτηση. Με αυτή τη δυνατότητα, ο χρήστης root μέσα στο container επιτρέπεται να δημιουργεί αρχεία block device. Τα αρχεία συσκευών είναι ειδικά αρχεία που χρησιμοποιούνται για πρόσβαση στο υποκείμενο hardware & στα modules του πυρήνα. Για παράδειγμα, το αρχείο block device /dev/sda δίνει πρόσβαση για ανάγνωση των raw δεδομένων στο δίσκο του συστήματος.
Το Docker προστατεύει ενάντια στην κατάχρηση αρχείων block device μέσα σε containers επιβάλλοντας μια πολιτική cgroup που αποκλείει τις λειτουργίες ανάγνωσης/εγγραφής block device. Ωστόσο, εάν ένα αρχείο block device δημιουργηθεί μέσα στο container, γίνεται προσβάσιμο από έξω από το container μέσω του φακέλου /proc/PID/root/. Αυτή η πρόσβαση απαιτεί τον ίδιο ιδιοκτήτη διεργασίας τόσο μέσα όσο και έξω από το container.
Παράδειγμα εκμετάλλευσης από αυτό το άρθρο:
Εάν μπορείτε να έχετε πρόσβαση στις διεργασίες του κεντρικού υπολογιστή, τότε θα μπορείτε να έχετε πρόσβαση σε πολλές ευαίσθητες πληροφορίες που αποθηκεύονται σε αυτές τις διεργασίες. Εκτελέστε το εργαστήριο δοκιμών:
Για παράδειγμα, θα μπορείτε να εμφανίσετε τις διεργασίες χρησιμοποιώντας κάτι σαν ps auxn
και να αναζητήσετε ευαίσθητες λεπτομέρειες στις εντολές.
Στη συνέχεια, καθώς μπορείτε να έχετε πρόσβαση σε κάθε διεργασία του κεντρικού υπολογιστή στο /proc/, μπορείτε απλά να κλέψετε τα μυστικά περιβάλλοντός τους εκτελώντας:
Μπορείτε επίσης να έχετε πρόσβαση στους αριθμούς αρχείων άλλων διεργασιών και να διαβάσετε τα ανοικτά αρχεία τους:
Μπορείτε επίσης να τερματίσετε διεργασίες και να προκαλέσετε DoS.
Αν έχετε κάποια προνομιακή πρόσβαση σε μια διεργασία έξω από το container, μπορείτε να εκτελέσετε κάτι σαν nsenter --target <pid> --all
ή nsenter --target <pid> --mount --net --pid --cgroup
για να εκτελέσετε ένα κέλυφος με τους ίδιους περιορισμούς ns (ελπίζουμε κανέναν) όπως αυτή η διεργασία.
Εάν ένας container έχει διαμορφωθεί με τον host networking driver (--network=host
), το δίκτυο αυτού του container δεν είναι απομονωμένο από τον Docker host (το container μοιράζεται το namespace δικτύωσης του host) και το container δεν λαμβάνει ανατεθειμένη δική του διεύθυνση IP. Με άλλα λόγια, το container δένει όλες τις υπηρεσίες απευθείας στη διεύθυνση IP του host. Επιπλέον, το container μπορεί να παρακολουθήσει ΟΛΗ την κίνηση δικτύου που ο host στέλνει και λαμβάνει στην κοινόχρηστη διεπαφή tcpdump -i eth0
.
Για παράδειγμα, μπορείτε να χρησιμοποιήσετε αυτό για να καταγράψετε και ακόμα να παραποιήσετε την κίνηση μεταξύ του host και της μεταδεδομένης περίπτωσης.
Όπως στα παρακάτω παραδείγματα:
Θα έχετε επίσης πρόσβαση σε υπηρεσίες δικτύου που είναι δεμένες στο localhost μέσα στον host ή ακόμα και πρόσβαση στα δικαιώματα μεταδεδομένων του κόμβου (τα οποία ενδέχεται να είναι διαφορετικά από αυτά που μπορεί να έχει πρόσβαση ένα container).
Με το hostIPC=true
, κερδίζετε πρόσβαση στους πόρους μεταξύ διεργασιών (IPC) του κεντρικού υπολογιστή, όπως τη κοινόχρηστη μνήμη στο /dev/shm
. Αυτό επιτρέπει την ανάγνωση/εγγραφή όπου οι ίδιοι πόροι IPC χρησιμοποιούνται από άλλες διεργασίες του κεντρικού υπολογιστή ή των pods. Χρησιμοποιήστε την εντολή ipcs
για να εξετάσετε αυτούς τους μηχανισμούς IPC περαιτέρω.
Επιθεώρηση του /dev/shm - Αναζητήστε αρχεία σε αυτήν την τοποθεσία της κοινόχρηστης μνήμης: ls -la /dev/shm
Επιθεώρηση υπαρχόντων εγκαταστάσεων IPC - Μπορείτε να ελέγξετε αν χρησιμοποιούνται κάποιες εγκαταστάσεις IPC με το /usr/bin/ipcs
. Ελέγξτε το με: ipcs -a
Αν η κλήση συστήματος unshare
δεν έχει απαγορευτεί, μπορείτε να ανακτήσετε όλες τις δυνατότητες εκτελώντας:
Η δεύτερη τεχνική που εξηγείται στη δημοσίευση https://labs.withsecure.com/blog/abusing-the-access-to-mount-namespaces-through-procpidroot/ δείχνει πώς μπορείτε να καταχραστείτε τα bind mounts με χώρους ονομάτων χρηστών, για να επηρεάσετε αρχεία μέσα στον κεντρικό υπολογιστή (σε εκείνη τη συγκεκριμένη περίπτωση, διαγράψτε αρχεία).
Χρησιμοποιήστε το Trickest για να δημιουργήσετε εύκολα και να αυτοματοποιήσετε ροές εργασίας με τη χρήση των πιο προηγμένων εργαλείων της κοινότητας. Αποκτήστε πρόσβαση σήμερα:
Σε περίπτωση που μπορείτε να εκτελέσετε την εντολή docker exec
ως ριζοχρήστης (πιθανόν με sudo), μπορείτε να προσπαθήσετε να αναβαθμίσετε τα δικαιώματά σας δραπετεύοντας από ένα container καταχρηστικά το CVE-2019-5736 (εκμετάλλευση εδώ). Αυτή η τεχνική θα αντικαταστήσει ουσιαστικά το /bin/sh δυαδικό αρχείο του κεντρικού υπολογιστή από ένα container, έτσι ώστε οποιοσδήποτε εκτελεί την εντολή docker exec μπορεί να ενεργοποιήσει το φορτίο.
Αλλάξτε το φορτίο αναλόγως και δημιουργήστε το main.go με την εντολή go build main.go
. Το δυαδικό αρχείο που προκύπτει θα πρέπει να τοποθετηθεί στο container Docker για εκτέλεση.
Κατά την εκτέλεση, μόλις εμφανιστεί το μήνυμα [+] Overwritten /bin/sh successfully
πρέπει να εκτελέσετε το ακόλουθο από τον κεντρικό υπολογιστή:
docker exec -it <container-name> /bin/sh
Αυτό θα ενεργοποιήσει το φορτίο που υπάρχει στο αρχείο main.go.
Για περισσότερες πληροφορίες: https://blog.dragonsector.pl/2019/02/cve-2019-5736-escape-from-docker-and.html
Υπάρχουν και άλλα CVEs στα οποία το container μπορεί να είναι ευάλωτο, μπορείτε να βρείτε μια λίστα στο https://0xn3va.gitbook.io/cheat-sheets/container/escaping/cve-list
Χώροι ονομάτων: Η διαδικασία πρέπει να είναι εντελώς χωρισμένη από άλλες διαδικασίες μέσω χώρων ονομάτων, έτσι ώστε να μην μπορούμε να δραπετεύσουμε αλληλεπιδρώντας με άλλες διεργασίες λόγω χώρων ονομάτων (από προεπιλογή δεν μπορούν να επικοινωνήσουν μέσω IPCs, unix sockets, network svcs, D-Bus, /proc
άλλων διεργασιών).
Χρήστης ρίζας: Από προεπιλογή, ο χρήστης που εκτελεί τη διαδικασία είναι ο χρήστης ρίζας (όμως οι προνομιούχες του είναι περιορισμένες).
Δυνατότητες: Το Docker αφήνει τις ακόλουθες δυνατότητες: cap_chown,cap_dac_override,cap_fowner,cap_fsetid,cap_kill,cap_setgid,cap_setuid,cap_setpcap,cap_net_bind_service,cap_net_raw,cap_sys_chroot,cap_mknod,cap_audit_write,cap_setfcap=ep
Syscalls: Αυτές είναι οι syscalls που ο χρήστης ρίζα δεν θα μπορεί να καλέσει (λόγω έλλειψης δυνατοτήτων + Seccomp). Οι άλλες syscalls θα μπορούσαν να χρησιμοποιηθούν για να προσπαθήσετε να δραπετεύσετε.
Κατά την εκτέλεση σε συστήματα arm64, ορισμένες κλήσεις συστήματος μπορεί να διαφέρουν από τις κλήσεις συστήματος x86. Αυτό πρέπει να ληφθεί υπόψη κατά την ανάπτυξη εργαλείων ιδιοποίησης προνομίων για συστήματα arm64. %}
This exploit demonstrates a privilege escalation attack that allows an attacker to break out of a Docker container and gain root access on the Docker host.
Compile the syscall_bf.c
code on the Docker host using the provided Makefile. Run the compiled binary inside the Docker container to escalate privileges and gain root access on the host system.
This exploit is for educational purposes only. Misuse of this exploit on unauthorized systems is illegal.
If you are in userspace (no kernel exploit involved) the way to find new escapes mainly involve the following actions (these templates usually require a container in privileged mode):
Find the path of the containers filesystem inside the host
You can do this via mount, or via brute-force PIDs as explained in the second release_agent exploit
Find some functionality where you can indicate the path of a script to be executed by a host process (helper) if something happens
You should be able to execute the trigger from inside the host
You need to know where the containers files are located inside the host to indicate a script you write inside the host
Have enough capabilities and disabled protections to be able to abuse that functionality
You might need to mount things o perform special privileged actions you cannot do in a default docker container
Use Trickest to easily build and automate workflows powered by the world's most advanced community tools. Get Access Today:
Learn & practice AWS Hacking:HackTricks Training AWS Red Team Expert (ARTE) Learn & practice GCP Hacking: HackTricks Training GCP Red Team Expert (GRTE)