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)
Mfumo wa idhini wa Docker wa nje ya sanduku ni kila kitu au hakuna kitu. Mtumiaji yeyote mwenye ruhusa ya kufikia Docker daemon anaweza kufanya amri yoyote ya mteja wa Docker. Hali hiyo hiyo inatumika kwa wito wanaotumia API ya Injini ya Docker kuwasiliana na daemon. Ikiwa unahitaji udhibiti wa ufikiaji zaidi, unaweza kuunda vijitendo vya idhini na kuviweka kwenye usanidi wa Docker daemon yako. Kwa kutumia kijitendo cha idhini, msimamizi wa Docker anaweza kuunda sera za ufikiaji za kina kwa ajili ya kusimamia ufikiaji wa Docker daemon.
Vijitendo vya Docker Auth ni vijitendo vya nje ambavyo unaweza kutumia kuruhusu/kukataa vitendo vinavyotakiwa kwa Docker Daemon kulingana na mtumiaji aliyeomba na kitendo kilichotakiwa.
Taarifa ifuatayo ni kutoka kwenye nyaraka
Wakati ombio la HTTP linapofanywa kwa daemon ya Docker kupitia CLI au kupitia API ya Injini, safu ya uthibitishaji inapeleka ombi kwa kijitendo cha uthibitishaji kilichosakinishwa. Ombi lina mtumiaji (mwanakitu) na muktadha wa amri. Kijitendo kina jukumu la kuamua ikiwa ruhusa itatolewa au kukataliwa.
Mchoro wa mfuatano hapa chini unaonyesha mtiririko wa ruhusa na kukataa:
Kila ombi lililotumwa kwa kijitendo linajumuisha mtumiaji aliyeidhinishwa, vichwa vya HTTP, na mwili wa ombi/jibu. Ni jina la mtumiaji tu na njia ya uthibitishaji iliyotumika inayotumwa kwa kijitendo. Muhimu zaidi, hakuna akidi za mtumiaji au token zinazotumwa. Mwishowe, sio kila mwili wa ombi/jibu unatumwa kwa kijitendo cha idhini. Ni wale tu mwili wa ombi/jibu ambapo Content-Type ni text/* au application/json ndio unatumwa.
Kwa amri ambazo zinaweza kuweza kuingilia uhusiano wa HTTP (HTTP Upgrade), kama vile exec, kijitendo cha idhini kinaitwa tu kwa ombi la awali la HTTP. Mara kijitendo kinapokubali amri, idhini haitumiki kwa mtiririko wa baadaye. Kwa hakika, data ya mtiririko haitatumwa kwa vijitendo vya idhini. Kwa amri ambazo zinarejesha jibu la HTTP lililokatwa, kama vile logs na events, ombi la HTTP pekee ndilo linalotumwa kwa vijitendo vya idhini.
Wakati wa usindikaji wa ombi/jibu, mtiririko fulani wa idhini unaweza kuhitaji kufanya maswali ya ziada kwa Docker daemon. Ili kukamilisha mtiririko kama huo, vijitendo vinaweza kuita API ya daemon kama mtumiaji wa kawaida. Ili kuwezesha maswali haya ya ziada, kijitendo lazima kitoe njia kwa msimamizi kuunda sera sahihi za uthibitishaji na usalama.
Wewe ni wajibu wa kujiandikisha kijitendo chako kama sehemu ya kuanzisha Docker daemon. Unaweza kusakinisha vijitendo vingi na kuviunganisha pamoja. Mnyororo huu unaweza kuagizwa. Kila ombi kwa daemon hupita kwa mpangilio kupitia mnyororo. Ni tu wakati vijitendo vyote vinapotoa ufikiaji kwa rasilimali, ndipo ufikiaji unapotolewa.
Kijitendo authz kinakuruhusu kuunda faili rahisi ya JSON ambayo kijitendo kitakuwa kikisoma ili kuidhinisha maombi. Hivyo, inakupa fursa ya kudhibiti kwa urahisi ni vipi API endpoints zinaweza kufikiwa na kila mtumiaji.
Hii ni mfano ambao utaruhusu Alice na Bob kuunda kontena mpya: {"name":"policy_3","users":["alice","bob"],"actions":["container_create"]}
Katika ukurasa route_parser.go unaweza kupata uhusiano kati ya URL iliyotakiwa na kitendo. Katika ukurasa types.go unaweza kupata uhusiano kati ya jina la kitendo na kitendo.
Unaweza kupata kijitendo rahisi kueleweka chenye taarifa za kina kuhusu usakinishaji na urekebishaji hapa: https://github.com/carlospolop-forks/authobot
Soma README na msimbo wa plugin.go ili kuelewa jinsi inavyofanya kazi.
Mambo makuu ya kuangalia ni ni vipi endpoints zinazoruhusiwa na ni vipi thamani za HostConfig zinazoruhusiwa.
Ili kufanya kuorodhesha hii unaweza kutumia chombo https://github.com/carlospolop/docker_auth_profiler.
run --privilegedKatika kesi hii, sysadmin amezuia watumiaji kuunganisha volumu na kuendesha kontena kwa kutumia bendera --privileged au kutoa uwezo wowote wa ziada kwa kontena:
Hata hivyo, mtumiaji anaweza kuunda shell ndani ya kontena linaloendesha na kutoa haki za ziada:
Sasa, mtumiaji anaweza kutoroka kutoka kwenye kontena akitumia yoyote ya mbinu zilizozungumziwa hapo awali na kuinua mamlaka ndani ya mwenyeji.
Katika kesi hii, sysadmin amekataza watumiaji kuendesha kontena na bendera ya --privileged au kutoa uwezo wowote wa ziada kwa kontena, na aliruhusu tu kuunganisha folda ya /tmp:
Kumbuka kwamba huenda usiweze kuunganisha folda /tmp lakini unaweza kuunganisha folda nyingine inayoweza kuandikwa. Unaweza kupata directories zinazoweza kuandikwa kwa kutumia: find / -writable -type d 2>/dev/null
Kumbuka kwamba si directories zote katika mashine ya linux zitasaidia suid bit! Ili kuangalia ni directories zipi zinazosupport suid bit, endesha mount | grep -v "nosuid" Kwa mfano, kawaida /dev/shm, /run, /proc, /sys/fs/cgroup na /var/lib/lxcfs hazisaidii suid bit.
Kumbuka pia kwamba ikiwa unaweza kuunganisha /etc au folda nyingine yoyote iliyokuwa na faili za usanidi, unaweza kuzibadilisha kutoka kwenye kontena la docker kama root ili uzitumie kwenye mwenyeji na kupandisha mamlaka (huenda ukabadilisha /etc/shadow)
Wajibu wa sysadmin anayekamilisha plugin hii ni kudhibiti ni vitendo vipi na kwa mamlaka gani kila mtumiaji anaweza kufanya. Hivyo, ikiwa admin atachukua njia ya blacklist na viwango na sifa, huenda akasahau baadhi yao ambayo yanaweza kumruhusu mshambuliaji kupandisha mamlaka.
Unaweza kuangalia API ya docker katika https://docs.docker.com/engine/api/v1.40/#
Inawezekana kwamba wakati sysadmin alikamilisha firewall ya docker alisahau kuhusu parameta muhimu ya API kama "Binds". Katika mfano ufuatao inawezekana kutumia makosa haya kuunda na kuendesha kontena linalounganisha folda ya root (/) ya mwenyeji:
Kumbuka jinsi katika mfano huu tunatumia Binds param kama ufunguo wa kiwango cha juu katika JSON lakini katika API inaonekana chini ya ufunguo HostConfig
Fuata maelekezo sawa na Binds katika root ukifanya hii ombio kwa Docker API:
Fuata maelekezo sawa na yale ya Binds in root ukifanya ombile hili kwa API ya Docker:
Fuata maelekezo sawa na yale ya Binds in root ukifanya ombile hili kwa API ya Docker:
Inawezekana kwamba wakati sysadmin alipoandika moto wa docker alisahau kuhusu sifa muhimu ya parameter ya API kama "Capabilities" ndani ya "HostConfig". Katika mfano ufuatao inawezekana kutumia makosa haya kuunda na kuendesha kontena lenye uwezo wa SYS_MODULE:
HostConfig ni ufunguo ambao mara nyingi unashikilia privileges za kuvutia za kutoroka kutoka kwenye kontena. Hata hivyo, kama tulivyozungumzia hapo awali, zingatia jinsi matumizi ya Binds nje yake pia yanavyofanya kazi na yanaweza kukuruhusu kupita vizuizi.
Ikiwa sysadmin alipokosa kuzuia uwezo wa kuondoa plugin, unaweza kutumia hii kuondoa kabisa!
Kumbuka kurejesha plugin baada ya kupandisha hadhi, au kuanzisha tena huduma ya docker hakutafanya kazi!
Jifunze & fanya mazoezi ya AWS Hacking:HackTricks Training AWS Red Team Expert (ARTE) Jifunze & fanya mazoezi ya GCP Hacking: HackTricks Training GCP Red Team Expert (GRTE)
