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’ın kutudan çıktığı gibi yetkilendirme modeli ya hepsi ya hiçbiri şeklindedir. Docker daemon'a erişim iznine sahip herhangi bir kullanıcı, herhangi bir Docker istemci komutunu çalıştırabilir. Docker’ın Engine API'sini kullanarak daemon ile iletişim kuran çağrıcılar için de aynı şey geçerlidir. Eğer daha fazla erişim kontrolü gerekiyorsa, yetkilendirme eklentileri oluşturabilir ve bunları Docker daemon yapılandırmanıza ekleyebilirsiniz. Bir yetkilendirme eklentisi kullanarak, bir Docker yöneticisi Docker daemon'a erişimi yönetmek için ayrıntılı erişim politikaları yapılandırabilir.
Docker Auth eklentileri, kullanıcı tarafından talep edilen hareketleri izin verme/red etme amacıyla Docker Daemon'a iletilen harici eklentilerdir.
Aşağıdaki bilgi belgelerden alınmıştır
Bir HTTP isteği, CLI aracılığıyla veya Engine API üzerinden Docker daemon'a yapıldığında, kimlik doğrulama alt sistemi isteği yüklü kimlik doğrulama eklenti(ler)ine iletir. İstek, kullanıcı (çağrıcı) ve komut bağlamını içerir. Eklenti, isteği izin verme veya red etme kararı vermekten sorumludur.
Aşağıdaki sıralama diyagramları, izin verme ve red etme yetkilendirme akışını göstermektedir:
Eklentiye gönderilen her istek, kimlik doğrulaması yapılmış kullanıcıyı, HTTP başlıklarını ve istek/yanıt gövdesini içerir. Sadece kullanıcı adı ve kullanılan kimlik doğrulama yöntemi eklentiye iletilir. En önemlisi, hiçbir kullanıcı kimlik bilgisi veya token iletilmez. Son olarak, tüm istek/yanıt gövdeleri yetkilendirme eklentisine gönderilmez. Sadece Content-Type
'ı text/*
veya application/json
olan istek/yanıt gövdeleri gönderilir.
HTTP bağlantısını potansiyel olarak ele geçirebilecek komutlar (HTTP Upgrade
) için, örneğin exec
, yetkilendirme eklentisi yalnızca ilk HTTP istekleri için çağrılır. Eklenti komutu onayladıktan sonra, yetkilendirme akışın geri kalanına uygulanmaz. Özellikle, akış verileri yetkilendirme eklentilerine iletilmez. Parçalı HTTP yanıtı döndüren komutlar için, örneğin logs
ve events
, yalnızca HTTP isteği yetkilendirme eklentilerine gönderilir.
İstek/yanıt işleme sırasında, bazı yetkilendirme akışları Docker daemon'a ek sorgular yapmayı gerektirebilir. Bu tür akışları tamamlamak için, eklentiler, normal bir kullanıcı gibi daemon API'sini çağırabilir. Bu ek sorguları etkinleştirmek için, eklentinin bir yöneticinin uygun kimlik doğrulama ve güvenlik politikalarını yapılandırmasını sağlaması gerekir.
Eklentinizi Docker daemon başlatma sürecinin bir parçası olarak kaydetmekten siz sorumlusunuz. Birden fazla eklenti yükleyebilir ve bunları birleştirebilirsiniz. Bu zincir sıralı olabilir. Daemona yapılan her istek, zincir boyunca sırayla geçer. Tüm eklentiler kaynağa erişim izni verdiğinde, erişim izni verilir.
Eklenti authz, istekleri yetkilendirmek için eklentinin okuyacağı basit bir JSON dosyası oluşturmanıza olanak tanır. Bu nedenle, her kullanıcının hangi API uç noktalarına erişebileceğini çok kolay bir şekilde kontrol etme fırsatı sunar.
Bu, Alice ve Bob'un yeni konteynerler oluşturmasına izin verecek bir örnektir: {"name":"policy_3","users":["alice","bob"],"actions":["container_create"]}
route_parser.go sayfasında istenen URL ile eylem arasındaki ilişkiyi bulabilirsiniz. types.go sayfasında ise eylem adı ile eylem arasındaki ilişkiyi bulabilirsiniz.
Kurulum ve hata ayıklama hakkında ayrıntılı bilgiye sahip anlaşılması kolay bir eklenti bulabilirsiniz: https://github.com/carlospolop-forks/authobot
Nasıl çalıştığını anlamak için README
ve plugin.go
kodunu okuyun.
Kontrol edilmesi gereken ana şeyler hangi uç noktaların izin verildiği ve hangi HostConfig değerlerinin izin verildiğidir.
Bu belirlemeyi yapmak için şu aracı kullanabilirsiniz https://github.com/carlospolop/docker_auth_profiler.
run --privileged
Bu durumda sistem yöneticisi kullanıcıların hacimleri bağlamasını ve --privileged
bayrağı ile konteyner çalıştırmasını veya konteynere herhangi bir ek yetenek vermesini engelledi:
Ancak, bir kullanıcı çalışan konteyner içinde bir shell oluşturabilir ve ona ek ayrıcalıklar verebilir:
Şimdi, kullanıcı daha önce tartışılan tekniklerden herhangi birini kullanarak konteynerden çıkabilir ve yetkileri artırabilir.
Bu durumda sistem yöneticisi kullanıcıların --privileged
bayrağı ile konteyner çalıştırmalarını yasakladı veya konteynere herhangi bir ek yetki vermedi ve yalnızca /tmp
klasörünü bağlamalarına izin verdi:
Not edin ki /tmp
klasörünü bağlayamayabilirsiniz ama farklı bir yazılabilir klasör bağlayabilirsiniz. Yazılabilir dizinleri bulmak için: find / -writable -type d 2>/dev/null
komutunu kullanabilirsiniz.
Not edin ki bir linux makinesindeki tüm dizinler suid bitini desteklemeyecektir! Hangi dizinlerin suid bitini desteklediğini kontrol etmek için mount | grep -v "nosuid"
komutunu çalıştırın. Örneğin genellikle /dev/shm
, /run
, /proc
, /sys/fs/cgroup
ve /var/lib/lxcfs
suid bitini desteklemez.
Ayrıca, eğer /etc
veya konfigürasyon dosyalarını içeren başka bir klasörü bağlayabiliyorsanız, bunları docker konteynerinden root olarak değiştirip host'ta kötüye kullanmak ve ayrıcalıkları artırmak için (belki /etc/shadow
dosyasını değiştirerek) kullanabilirsiniz.
Bu eklentiyi yapılandıran sistem yöneticisinin sorumluluğu, her kullanıcının hangi eylemleri ve hangi ayrıcalıklarla gerçekleştirebileceğini kontrol etmektir. Bu nedenle, eğer yönetici uç noktalar ve nitelikler ile ilgili bir kara liste yaklaşımı benimserse, bir saldırganın ayrıcalıkları artırmasına izin verebilecek bazılarını unutabilir.
Docker API'sini https://docs.docker.com/engine/api/v1.40/# adresinde kontrol edebilirsiniz.
Sistem yöneticisi docker güvenlik duvarını yapılandırırken API gibi bazı önemli parametreleri unutmuş olabilir. "Binds" gibi. Aşağıdaki örnekte, bu yanlış yapılandırmayı kötüye kullanarak host'un kök (/) klasörünü bağlayan ve çalıştıran bir konteyner oluşturmak mümkündür:
Bu örnekte Binds
parametresini JSON'da kök düzey anahtar olarak kullandığımıza dikkat edin, ancak API'de HostConfig
anahtarı altında görünmektedir.
Kökteki Binds ile aynı talimatları izleyerek bu isteği Docker API'sine gerçekleştirin:
Binds in root ile aynı talimatları izleyerek bu isteği Docker API'sine gerçekleştirin:
Kökteki Binds ile aynı talimatları izleyerek bu isteği Docker API'sine gerçekleştirin:
Sysadmin docker güvenlik duvarını yapılandırırken, API içindeki "HostConfig" parametresinin "Capabilities" gibi bazı önemli özelliklerini unutmuş olabilir. Aşağıdaki örnekte, bu yanlış yapılandırmayı kullanarak SYS_MODULE yetkisine sahip bir konteyner oluşturmak ve çalıştırmak mümkündür:
HostConfig
, genellikle konteynerden kaçmak için ilginç yetkileri içeren anahtardır. Ancak, daha önce tartıştığımız gibi, bunun dışındaki Binds kullanımının da işe yaradığını ve kısıtlamaları aşmanıza izin verebileceğini unutmayın.
Eğer sistem yöneticisi eklentiyi devre dışı bırakma yetkisini unutmuşsa, bunu tamamen devre dışı bırakmak için kullanabilirsiniz!
Remember to re-enable the plugin after escalating, or a restart of docker service won’t work!
AWS Hacking öğrenin ve pratik yapın:HackTricks Training AWS Red Team Expert (ARTE) GCP Hacking öğrenin ve pratik yapın: HackTricks Training GCP Red Team Expert (GRTE)