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 se standaard autorisatiemodel is alles of niks. Enige gebruiker met toestemming om toegang tot die Docker daemon te verkry, kan enige Docker kliënt opdrag uitvoer. Dieselfde geld vir oproepers wat Docker se Engine API gebruik om met die daemon te kommunikeer. As jy groter toegangbeheer benodig, kan jy autorisasie plugins skep en dit by jou Docker daemon konfigurasie voeg. Met 'n autorisasie plugin kan 'n Docker administrateur fyn toegang beleid konfigureer om toegang tot die Docker daemon te bestuur.
Docker Auth plugins is eksterne plugins wat jy kan gebruik om toestemming te gee/te weier vir aksies wat aan die Docker Daemon gevra word, afhangende van die gebruiker wat dit gevra het en die aksie gevra.
Die volgende inligting is uit die dokumentasie
Wanneer 'n HTTP versoek aan die Docker daemon gemaak word deur die CLI of via die Engine API, stuur die authentikasie substelsel die versoek na die geïnstalleerde authentikasie plugin(s). Die versoek bevat die gebruiker (oproeper) en opdrag konteks. Die plugin is verantwoordelik om te besluit of die versoek toegelaat of weggestoot moet word.
Die volgorde diagramme hieronder toon 'n toelaat en weier autorisasie vloei:
Elke versoek wat na die plugin gestuur word, sluit die geverifieerde gebruiker, die HTTP koptekste, en die versoek/antwoord liggaam in. Slegs die gebruikersnaam en die authentikasie metode wat gebruik is, word na die plugin gestuur. Die belangrikste is dat geen gebruikers akkrediteer of tokens gestuur word nie. Laastens, nie alle versoek/antwoord liggame word gestuur na die autorisasie plugin nie. Slegs daardie versoek/antwoord liggame waar die Content-Type of text/* of application/json is, word gestuur.
Vir opdragte wat moontlik die HTTP verbinding kan oorneem (HTTP Upgrade), soos exec, word die autorisasie plugin slegs vir die aanvanklike HTTP versoeke aangeroep. Sodra die plugin die opdrag goedkeur, word autorisasie nie op die res van die vloei toegepas nie. Spesifiek, die stroomdata word nie na die autorisasie plugins gestuur nie. Vir opdragte wat gekapte HTTP antwoorde teruggee, soos logs en events, word slegs die HTTP versoek na die autorisasie plugins gestuur.
Tydens versoek/antwoord verwerking, mag sommige autorisasie vloei addisionele navrae aan die Docker daemon benodig. Om sulke vloei te voltooi, kan plugins die daemon API aanroep soos 'n gewone gebruiker. Om hierdie addisionele navrae moontlik te maak, moet die plugin die middele verskaf vir 'n administrateur om behoorlike authentikasie en sekuriteitsbeleide te konfigureer.
Jy is verantwoordelik vir registrasie van jou plugin as deel van die Docker daemon opstart. Jy kan meerdere plugins installeer en dit saamketting. Hierdie ketting kan georden word. Elke versoek aan die daemon beweeg in volgorde deur die ketting. Slegs wanneer alle plugins toegang gee tot die hulpbron, word die toegang toegestaan.
Die plugin authz laat jou toe om 'n eenvoudige JSON lêer te skep wat die plugin sal lees om die versoeke te autoriseer. Daarom bied dit jou die geleentheid om baie maklik te beheer watter API eindpunte elke gebruiker kan bereik.
Dit is 'n voorbeeld wat sal toelaat dat Alice en Bob nuwe houers kan skep: {"name":"policy_3","users":["alice","bob"],"actions":["container_create"]}
Op die bladsy route_parser.go kan jy die verhouding tussen die gevraagde URL en die aksie vind. Op die bladsy types.go kan jy die verhouding tussen die aksienaam en die aksie vind.
Jy kan 'n maklik verstaanbare plugin met gedetailleerde inligting oor installasie en foutopsporing hier vind: https://github.com/carlospolop-forks/authobot
Lees die README en die plugin.go kode om te verstaan hoe dit werk.
Die hoof dinge om te kontroleer is die watter eindpunte toegelaat word en watter waardes van HostConfig toegelaat word.
Om hierdie enumerasie uit te voer, kan jy die hulpmiddel https://github.com/carlospolop/docker_auth_profiler.
run --privilegedIn this case the sysadmin het gebruikers verbied om volumes te monteer en houers met die --privileged vlag te draai of enige ekstra vermoë aan die houer te gee:
However, a user can create a shell inside the running container and give it the extra privileges:
Nou kan die gebruiker uit die houer ontsnap deur enige van die voorheen bespreekte tegnieke te gebruik en privileges te verhoog binne die gasheer.
In hierdie geval het die stelselaanvaarder gebruikers verbied om houers met die --privileged vlag te laat loop of enige ekstra vermoë aan die houer te gee, en hy het slegs toegelaat om die /tmp gids te monteer:
Let daarop dat jy dalk nie die gids /tmp kan monteer nie, maar jy kan 'n ander skryfbare gids monteer. Jy kan skryfbare gidse vind met: find / -writable -type d 2>/dev/null
Let daarop dat nie al die gidse in 'n linux masjien die suid bit sal ondersteun nie! Om te kyk watter gidse die suid bit ondersteun, voer mount | grep -v "nosuid" uit. Byvoorbeeld, gewoonlik ondersteun /dev/shm, /run, /proc, /sys/fs/cgroup en /var/lib/lxcfs nie die suid bit nie.
Let ook daarop dat as jy /etc of enige ander gids wat konfigurasie lêers bevat, kan monteer, jy dit as root vanuit die docker houer kan verander om dit te misbruik in die gasheer en voorregte te verhoog (miskien deur /etc/shadow te wysig).
Die verantwoordelikheid van die sysadmin wat hierdie plugin konfigureer, sal wees om te beheer watter aksies en met watter voorregte elke gebruiker kan uitvoer. Daarom, as die admin 'n swartlys benadering met die eindpunte en die eienskappe neem, mag hy dalk van sommige daarvan vergeet wat 'n aanvaller kan toelaat om voorregte te verhoog.
Jy kan die docker API nagaan in https://docs.docker.com/engine/api/v1.40/#
Dit is moontlik dat toe die sysadmin die docker vuurmuur gekonfigureer het, hy van 'n belangrike parameter van die API soos "Bindings" vergeet het. In die volgende voorbeeld is dit moontlik om hierdie miskonfigurasie te misbruik om 'n houer te skep en te laat loop wat die wortel (/) gids van die gasheer monteer:
Let op hoe ons in hierdie voorbeeld die Binds parameter as 'n wortelvlak sleutel in die JSON gebruik, maar in die API verskyn dit onder die sleutel HostConfig
Volg dieselfde instruksies as met Binds in root deur hierdie aanvraag aan die Docker API te doen:
Volg dieselfde instruksies as met Binds in root deur hierdie versoek aan die Docker API te doen:
Volg dieselfde instruksies as met Binds in root deur hierdie versoek aan die Docker API te doen:
Dit is moontlik dat toe die stelselaanvoerder die docker-vuurmuur gekonfigureer het, hy vergeet het van 'n belangrike attribuut van 'n parameter van die API soos "Capabilities" binne "HostConfig". In die volgende voorbeeld is dit moontlik om hierdie miskonfigurasie te misbruik om 'n houer met die SYS_MODULE vermoë te skep en te laat loop:
Die HostConfig is die sleutel wat gewoonlik die interessante privileges bevat om uit die houer te ontsnap. Dit is egter belangrik om te noem, soos ons voorheen bespreek het, dat die gebruik van Binds buite dit ook werk en jou mag toelaat om beperkings te omseil.
As die sisteemadministrateur vergeet het om die vermoë om die plugin te deaktiveer te verbied, kan jy hiervan voordeel trek om dit heeltemal te deaktiveer!
Remember to heraktiveer die plugin na die eskalering, or a herbegin van die docker diens sal nie werk nie!
Leer & oefen AWS Hacking:HackTricks Opleiding AWS Red Team Expert (ARTE) Leer & oefen GCP Hacking: HackTricks Opleiding GCP Red Team Expert (GRTE)
