Kubernetes Enumeration
Last updated
Last updated
AWS Hacking'i öğrenin ve pratik yapın:HackTricks Training AWS Red Team Expert (ARTE) GCP Hacking'i öğrenin ve pratik yapın: HackTricks Training GCP Red Team Expert (GRTE)
Bir makineye erişiminiz varsa, kullanıcı bazı Kubernetes platformlarına erişime sahip olabilir. Token genellikle env var KUBECONFIG
tarafından işaret edilen bir dosyada veya ~/.kube
içinde bulunur.
Bu klasörde API sunucusuna bağlanmak için tokenler ve yapılandırmalar içeren yapılandırma dosyaları bulabilirsiniz. Bu klasörde ayrıca daha önce alınan bilgileri içeren bir önbellek klasörü de bulabilirsiniz.
Eğer bir Kubernetes ortamında bir pod'u ele geçirdiyseniz, tokenler ve mevcut K8 ortamı hakkında bilgi bulabileceğiniz başka yerler de vardır:
Devam etmeden önce, Kubernetes'te bir servisin ne olduğunu bilmiyorsanız, bu bağlantıyı takip etmenizi ve en azından Kubernetes mimarisi hakkında bilgileri okumanızı öneririm.
Kubernetes belgelerinden alınmıştır:
“Bir pod oluşturduğunuzda, bir servis hesabı belirtmezseniz, otomatik olarak aynı ad alanındaki varsayılan servis hesabına atanır.”
ServiceAccount, Kubernetes tarafından yönetilen ve bir pod içinde çalışan süreçler için bir kimlik sağlamak için kullanılan bir nesnedir. Her servis hesabının ona bağlı bir sırrı vardır ve bu sır, bir taşıyıcı token içerir. Bu, iki taraf arasında talepleri güvenli bir şekilde temsil etmenin bir yolu olan JSON Web Token (JWT) dir.
Genellikle bir dizin:
/run/secrets/kubernetes.io/serviceaccount
/var/run/secrets/kubernetes.io/serviceaccount
/secrets/kubernetes.io/serviceaccount
aşağıdaki dosyaları içerir:
ca.crt: Kubernetes iletişimlerini kontrol etmek için ca sertifikasıdır
namespace: Mevcut ad alanını belirtir
token: Mevcut pod'un servis tokenini içerir.
Artık token'e sahip olduğunuza göre, API sunucusunu KUBECONFIG
ortam değişkeni içinde bulabilirsiniz. Daha fazla bilgi için (env | set) | grep -i "kuber|kube
"
komutunu çalıştırın.
Servis hesabı tokeni, sa.key dosyasında bulunan anahtar ile imzalanır ve sa.pub tarafından doğrulanır.
Kubernetes üzerindeki varsayılan konum:
/etc/kubernetes/pki
Minikube üzerindeki varsayılan konum:
/var/lib/localkube/certs
Sıcak podlar, ayrıcalıklı bir servis hesabı tokeni içeren podlardır. Ayrıcalıklı bir servis hesabı tokeni, gizli bilgileri listeleme, pod oluşturma gibi ayrıcalıklı görevleri yapma iznine sahip bir token'dır.
Eğer RBAC'ın ne olduğunu bilmiyorsanız, bu bölümü okuyun.
k9s: Terminalden bir Kubernetes kümesini listeleyen bir GUI. Komutları kontrol edin https://k9scli.io/topics/commands/. :namespace
yazın ve tümünü seçerek tüm ad alanlarındaki kaynakları arayın.
k8slens: Bazı ücretsiz deneme günleri sunar: https://k8slens.dev/
Bir K8s ortamını listelemek için şunlara ihtiyacınız var:
geçerli bir kimlik doğrulama tokeni. Önceki bölümde bir kullanıcı tokeni ve bir servis hesabı tokeni için nerede arama yapacağımızı gördük.
Kubernetes API'sinin adresi (https://host:port). Bu genellikle ortam değişkenlerinde ve/veya kube yapılandırma dosyasında bulunabilir.
Opsiyonel: API sunucusunu doğrulamak için ca.crt. Bu, tokenin bulunabileceği aynı yerlerde bulunabilir. Bu, API sunucusu sertifikasını doğrulamak için yararlıdır, ancak kubectl
ile --insecure-skip-tls-verify
veya curl
ile -k
kullanarak buna ihtiyacınız olmayacaktır.
Bu detaylarla kubernetes'i listeleyebilirsiniz. Eğer API bir nedenle İnternet üzerinden erişilebilir ise, bu bilgiyi indirip platformu kendi makinenizden listeleyebilirsiniz.
Ancak genellikle API sunucusu dahili bir ağdadır, bu nedenle ona erişmek için ele geçirilmiş makine üzerinden bir tünel oluşturmanız gerekecektir veya kubectl binariesini yükleyebilir veya curl/wget/anything
kullanarak API sunucusuna ham HTTP istekleri gönderebilirsiniz.
list
ve get
fiilleri arasındaki farklarget
izinleri ile belirli varlıkların bilgilerine erişebilirsiniz (kubectl
'deki describe
seçeneği) API:
Eğer list
iznine sahipseniz, bir varlık türünü listelemek için API istekleri gerçekleştirme izniniz vardır (kubectl
'deki get
seçeneği):
Eğer watch
iznine sahipseniz, varlıkları izlemek için API istekleri gerçekleştirme izniniz vardır:
Bir değişiklik olduğunda (veya yeni bir tane oluşturulduğunda) size bir Deployment'ın tam manifestosunu döndüren bir akış bağlantısı açarlar.
Aşağıdaki kubectl
komutları nesneleri listelemenin nasıl olduğunu gösterir. Verilere erişmek istiyorsanız get
yerine describe
kullanmalısınız.
Bir podun içinden birkaç ortam değişkeni kullanabilirsiniz:
Varsayılan olarak pod, kubernetes.default.svc
alan adındaki kube-api sunucusuna erişebilir ve burada kubernetes DNS sunucusunun adresini bulacağınız /etc/resolv.config
dosyasında kube ağını görebilirsiniz (aynı aralığın ".1" kısmı kube-api uç noktasıdır).
Token ve API sunucusunun adresine sahip olduğunuzda, burada belirtildiği gibi erişmek için kubectl veya curl kullanabilirsiniz:
Varsayılan olarak, APISERVER https://
şeması ile iletişim kurmaktadır.
Eğer URL'de
https://
yoksa, Bad Request gibi bir hata alabilirsiniz.
Burada resmi kubectl kılavuzunu bulabilirsiniz. Aşağıdaki bölümlerin amacı, erişim sağladığınız yeni K8s'i sıralı bir şekilde enumerate etmek ve anlamak için farklı seçenekleri sunmaktır.
kubectl
'nin gönderdiği HTTP isteğini bulmak için -v=8
parametresini kullanabilirsiniz.
Eğer bazı kullanıcıların kimlik bilgilerini çalmayı başardıysanız, bunları yerel olarak yapılandırabilirsiniz şöyle bir şey kullanarak:
Bu bilgiyle listeleyebileceğiniz tüm hizmetleri bileceksiniz
Yetki kontrolü yapmanın bir diğer yolu: https://github.com/corneliusweig/rakkess****
Kubernetes RBAC hakkında daha fazla bilgi edinebilirsiniz:
Kubernetes Role-Based Access Control(RBAC)Hangi yetkilere sahip olduğunuzu öğrendikten sonra, yetkileri yükseltmek için bunları kötüye kullanıp kullanamayacağınızı öğrenmek için aşağıdaki sayfayı kontrol edin:
Abusing Roles/ClusterRoles in KubernetesKubernetes, aynı fiziksel küme tarafından desteklenen birden fazla sanal küme'yi destekler. Bu sanal kümelere ad alanları denir.
Eğer gizli bilgileri okuyabiliyorsanız, her bir token ile ilgili ayrıcalıkları almak için aşağıdaki satırları kullanabilirsiniz:
Bu sayfanın başında tartışıldığı gibi bir pod çalıştırıldığında genellikle ona bir hizmet hesabı atanır. Bu nedenle, hizmet hesaplarını, izinlerini ve nerede çalıştıklarını listelemek, bir kullanıcının ayrıcalıkları artırmasına olanak tanıyabilir.
Dağıtımlar, çalıştırılması gereken bileşenleri belirtir.
Podlar, çalışacak olan gerçek konteynerlerdir.
Kubernetes hizmetleri, bir hizmeti belirli bir port ve IP'de açmak için kullanılır (bu, aslında hizmeti sunan pod'lara yük dengeleyici olarak işlev görecektir). Bu, saldırmayı denemek için diğer hizmetleri nerede bulabileceğinizi bilmek açısından ilginçtir.
Küme içinde yapılandırılmış tüm düğümleri al.
DaemonSet'ler, belirli bir pod'un kümenin tüm düğümlerinde (veya seçilenlerde) çalıştığından emin olmayı sağlar. DaemonSet'i silerseniz, onun tarafından yönetilen pod'lar da kaldırılacaktır.
Cron işleri, belirli bir eylemi gerçekleştirecek bir pod'un başlatılmasını crontab benzeri bir sözdizimi kullanarak planlamaya olanak tanır.
configMap her zaman kubernetes'te çalışan uygulamalara sağlanan birçok bilgi ve yapılandırma dosyası içerir. Genellikle, diğer iç/dış hizmetlere bağlanmak ve doğrulamak için kullanılan birçok şifre, gizli anahtar ve token bulabilirsiniz.
Yeni pod'lar oluşturabiliyorsanız, bunlardan node'a kaçış yapabilirsiniz. Bunu yapmak için bir yaml dosyası kullanarak yeni bir pod oluşturmanız, oluşturulan pod'a geçiş yapmanız ve ardından node'un sistemine chroot yapmanız gerekir. Mevcut görüntüleri ve yolları gösterdikleri için yaml dosyası için referans olarak mevcut pod'ları kullanabilirsiniz.
Eğer belirli bir düğümde pod oluşturmanız gerekiyorsa, düğüm üzerindeki etiketleri almak için aşağıdaki komutu kullanabilirsiniz.
k get nodes --show-labels
Genellikle, kubernetes.io/hostname ve node-role.kubernetes.io/master, seçim için iyi etiketlerdir.
Sonra attack.yaml dosyanızı oluşturursunuz.
Bundan sonra pod'u oluşturursunuz.
Artık oluşturulan pod'a aşağıdaki gibi geçiş yapabilirsiniz
Ve sonunda node'un sistemine chroot yaparsınız.
Bilgi alındı: Kubernetes Namespace Breakout using Insecure Host Path Volume — Part 1 Attacking and Defending Kubernetes: Bust-A-Kube – Episode 1
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)