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)
Dockerov model autorizacije je sve ili ništa. Svaki korisnik sa dozvolom za pristup Docker demon može izvršiti bilo koju Docker klijentsku komandu. Isto važi i za pozivaoce koji koriste Dockerov Engine API za kontaktiranje demona. Ako vam je potrebna veća kontrola pristupa, možete kreirati autorizacione dodatke i dodati ih u konfiguraciju vašeg Docker demona. Korišćenjem autorizacionog dodatka, Docker administrator može konfigurisati granularne politike pristupa za upravljanje pristupom Docker demonu.
Docker Auth dodaci su spoljni dodaci koje možete koristiti da dozvolite/odbacite akcije koje se traže od Docker demona u zavisnosti od korisnika koji je to zatražio i akcije koja se traži.
Sledeće informacije su iz dokumentacije
Kada se napravi HTTP zahtev ka Docker demonu putem CLI ili putem Engine API, sistem autentifikacije prosledi zahtev instaliranom autentifikacionom dodatku(cima). Zahtev sadrži korisnika (pozivaoca) i kontekst komande. Dodatak je odgovoran za odlučivanje da li da dozvoli ili odbaci zahtev.
Dijagrami sekvenci ispod prikazuju tok autorizacije dozvola i odbijanja:
Svaki zahtev poslat dodatku uključuje autentifikovanog korisnika, HTTP zaglavlja i telo zahteva/odgovora. Samo se ime korisnika i metoda autentifikacije koriste prosleđuju dodatku. Najvažnije, nema korisničkih akreditiva ili tokena koji se prosleđuju. Na kraju, ne šalju se svi zahtevi/tela odgovora autorizacionom dodatku. Samo ona tela zahteva/odgovora gde je Content-Type
ili text/*
ili application/json
se šalju.
Za komande koje potencijalno mogu preuzeti HTTP vezu (HTTP Upgrade
), kao što je exec
, autorizacioni dodatak se poziva samo za inicijalne HTTP zahteve. Kada dodatak odobri komandu, autorizacija se ne primenjuje na ostatak toka. Konkretno, streaming podaci se ne prosleđuju autorizacionim dodacima. Za komande koje vraćaju delimične HTTP odgovore, kao što su logs
i events
, samo se HTTP zahtev šalje autorizacionim dodacima.
Tokom obrade zahteva/odgovora, neki tokovi autorizacije mogu zahtevati dodatne upite ka Docker demonu. Da bi se završili takvi tokovi, dodaci mogu pozvati API demona slično kao običan korisnik. Da bi omogućili ove dodatne upite, dodatak mora obezbediti sredstva za administratora da konfiguriše odgovarajuće politike autentifikacije i bezbednosti.
Vi ste odgovorni za registraciju vašeg dodatka kao deo pokretanja Docker demona. Možete instalirati više dodataka i povezati ih. Ova veza može biti uređena. Svaki zahtev ka demonu prolazi redom kroz lanac. Samo kada svi dodaci odobre pristup resursu, pristup se odobrava.
Dodatak authz vam omogućava da kreirate jednostavnu JSON datoteku koju će dodatak čitati da bi autorizovao zahteve. Stoga, pruža vam priliku da vrlo lako kontrolišete koji API krajnji tačke mogu da dostignu svaki korisnik.
Ovo je primer koji će omogućiti Alisi i Bobu da kreiraju nove kontejnere: {"name":"policy_3","users":["alice","bob"],"actions":["container_create"]}
Na stranici route_parser.go možete pronaći odnos između traženog URL-a i akcije. Na stranici types.go možete pronaći odnos između imena akcije i akcije.
Možete pronaći lako razumljiv dodatak sa detaljnim informacijama o instalaciji i debagovanju ovde: https://github.com/carlospolop-forks/authobot
Pročitajte README
i plugin.go
kod da biste razumeli kako funkcioniše.
Glavne stvari koje treba proveriti su koje krajnje tačke su dozvoljene i koje vrednosti HostConfig su dozvoljene.
Da biste izvršili ovu enumeraciju, možete koristiti alat https://github.com/carlospolop/docker_auth_profiler.
run --privileged
U ovom slučaju, sysadmin nije dozvolio korisnicima da montiraju volumene i pokreću kontejnere sa --privileged
oznakom ili daju bilo koju dodatnu sposobnost kontejneru:
Međutim, korisnik može napraviti shell unutar pokrenutog kontejnera i dati mu dodatne privilegije:
Sada, korisnik može da pobegne iz kontejnera koristeći neku od prethodno diskutovanih tehnika i poveća privilegije unutar hosta.
U ovom slučaju, sysadmin je zabranio korisnicima da pokreću kontejnere sa --privileged
flag-om ili daju bilo kakvu dodatnu sposobnost kontejneru, i dozvolio je samo montiranje /tmp
foldera:
Napomena da možda ne možete montirati folder /tmp
, ali možete montirati drugi zapisiv folder. Možete pronaći zapisive direktorijume koristeći: find / -writable -type d 2>/dev/null
Napomena da ne podržavaju svi direktorijumi na linux mašini suid bit! Da biste proverili koji direktorijumi podržavaju suid bit, pokrenite mount | grep -v "nosuid"
. Na primer, obično /dev/shm
, /run
, /proc
, /sys/fs/cgroup
i /var/lib/lxcfs
ne podržavaju suid bit.
Takođe, napomena da ako možete montirati /etc
ili bilo koji drugi folder koji sadrži konfiguracione fajlove, možete ih menjati iz docker kontejnera kao root kako biste zloupotrebili na hostu i eskalirali privilegije (možda menjajući /etc/shadow
)
Odgovornost sysadmin-a koji konfiguriše ovaj plugin bi bila da kontroliše koje akcije i sa kojim privilegijama svaki korisnik može da izvrši. Stoga, ako admin uzme pristup crnoj listi sa endpoint-ima i atributima, može zaboraviti neke od njih koji bi mogli omogućiti napadaču da eskalira privilegije.
Možete proveriti docker API na https://docs.docker.com/engine/api/v1.40/#
Moguće je da kada je sysadmin konfigurisao docker firewall, zaboravio na neki važan parametar API kao što je "Binds". U sledećem primeru moguće je zloupotrebiti ovu pogrešnu konfiguraciju da se kreira i pokrene kontejner koji montira root (/) folder hosta:
Obratite pažnju kako u ovom primeru koristimo Binds
parametar kao ključ na vrhu u JSON-u, ali u API-ju se pojavljuje pod ključem HostConfig
Pratite iste upute kao sa Binds u root izvršavajući ovaj request ka Docker API-ju:
Pratite iste upute kao i za Binds in root izvršavajući ovu request ka Docker API:
Pratite iste upute kao sa Binds in root izvršavajući ovaj request na Docker API:
Moguće je da je kada je sistem administrator konfigurisao docker vatrozid zaboravio na neki važan atribut parametra API kao što je "Capabilities" unutar "HostConfig". U sledećem primeru moguće je iskoristiti ovu pogrešnu konfiguraciju da se kreira i pokrene kontejner sa SYS_MODULE sposobnošću:
HostConfig
је кључ који обично садржи занимљиве привилегије за бекство из контејнера. Међутим, као што смо раније расправљали, приметите како коришћење Binds ван њега такође функционише и може вам омогућити да заобиђете ограничења.
Ако је систем администратор заборавио да забрани могућност онемогућавања плугинa, можете искористити ово да га потпуно онемогућите!
Zapamtite da ponovo omogućite dodatak nakon eskalacije, ili ponovno pokretanje docker usluge neće raditi!
Učite i vežbajte AWS Hacking:HackTricks Training AWS Red Team Expert (ARTE) Učite i vežbajte GCP Hacking: HackTricks Training GCP Red Team Expert (GRTE)