AWS - EKS Post Exploitation
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)
Daha fazla bilgi için kontrol edin
AWS - EKS EnumEğer eks:AccessKubernetesApi
iznine sahipseniz, AWS EKS konsolu aracılığıyla Kubernetes nesnelerini görüntüleyebilirsiniz (Daha fazla bilgi edinin).
Kolay yol:
Kolay bir yol değil:
Eğer aws eks get-token --name <cluster_name>
ile bir token alabiliyorsanız ama cluster bilgilerini (describeCluster) almak için izinleriniz yoksa, kendi ~/.kube/config
dosyanızı hazırlayabilirsiniz. Ancak, token'a sahip olsanız bile, bağlanmak için url endpoint'e ihtiyacınız var (eğer bir pod'dan JWT token aldıysanız buradan okuyun) ve cluster'ın adına ihtiyacınız var.
Benim durumumda, CloudWatch loglarında bilgiyi bulamadım, ama LaunchTemplates userData'da ve EC2 makinelerinde userData'da buldum. Bu bilgiyi userData içinde kolayca görebilirsiniz, örneğin bir sonraki örnekte (cluster adı cluster-name idi):
EKS kümesinin yaratıcısı, grubun system:masters
(k8s admin) kısmına HER ZAMAN girebilecektir. Bu yazının yazıldığı sırada kümenin kim tarafından oluşturulduğunu bulmanın doğrudan bir yolu yoktur (CloudTrail'i kontrol edebilirsiniz). Ve bu yetkiyi kaldırmanın yolu yoktur.
AWS IAM kullanıcıları veya rolleri için K8s'e erişim vermenin yolu aws-auth
configmap'ini kullanmaktır.
Bu nedenle, aws-auth
config map'inde yazma erişimi olan herkes tüm kümeyi tehlikeye atabilecektir.
Aynı veya farklı hesaplarda IAM rolleri ve kullanıcılara ek yetkiler vermek ve bunu nasıl istismar edeceğiniz hakkında daha fazla bilgi için bu sayfayı kontrol edin.
Ayrıca bu harika yazıyı kontrol edin, IAM -> Kubernetes kimlik doğrulamasının nasıl çalıştığını öğrenin.
Kubernetes hizmet hesabı için OpenID kimlik doğrulamasını sağlamak, onların AWS'de roller üstlenmelerine izin vermek mümkündür. Bu sayfada nasıl çalıştığını öğrenin.
Dokümantasyonda 'iki karakter' ve 'sayı' için kriterleri açıklayan bir şey bulamadım. Ancak kendi adıma bazı testler yaparak şunların tekrar ettiğini görüyorum:
gr7
yl4
Her halükarda, sadece 3 karakter var, bunları brute force ile kırabiliriz. Listeyi oluşturmak için aşağıdaki scripti kullanın.
Sonra wfuzz ile
Unutmayın, & ile değiştirin.
Eğer bir saldırganın EKS üzerinde yetkisi olan bir AWS kimlik bilgilerini elde ederse. Eğer saldırgan daha önce açıklandığı gibi kendi kubeconfig
dosyasını ( update-kubeconfig
çağrısı yapmadan) yapılandırırsa, get-token
Cloudtrail'de log oluşturmaz çünkü AWS API'si ile etkileşime geçmez (sadece token'ı yerel olarak oluşturur).
Bu nedenle, saldırgan EKS kümesi ile konuştuğunda, cloudtrail çalınan kullanıcı ile ilgili hiçbir şeyi loglamayacaktır.
EKS kümesinin bu erişimi loglayacak logları etkinleştirilmiş olabileceğini unutmayın (ancak varsayılan olarak devre dışıdır).
Varsayılan olarak, bir küme oluşturan kullanıcı veya rol her zaman küme üzerinde yönetici ayrıcalıklarına sahip olacaktır. Ve AWS'nin Kubernetes kümesine sahip olacağı tek "güvenli" erişim budur.
Yani, eğer bir saldırgan fargate kullanarak bir kümeyi ele geçirirse ve diğer tüm yöneticileri kaldırırsa ve Küme'yi oluşturan AWS kullanıcı/rolünü silerse, saldırgan küme için fidye talep edebilir**.
Eğer küme EC2 VM'leri kullanıyorsa, Node üzerinden Yönetici ayrıcalıkları almak ve kümeyi kurtarmak mümkün olabilir.
Aslında, eğer küme Fargate kullanıyorsa, EC2 düğümlerini alabilir veya her şeyi EC2'ye taşıyabilir ve düğümdeki token'lara erişerek kurtarabilirsiniz.
JWT token'ı çözümleyerek küme kimliğini ve ayrıca bölgeyi alıyoruz. EKS url'sinin standart formatının olduğunu bilmek
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)