Şirketinizi HackTricks'te reklamını görmek istiyorsanız veya HackTricks'i PDF olarak indirmek istiyorsanız [ABONELİK PLANLARI]'na göz atın (https://github.com/sponsors/carlospolop)!
Eğer aws eks get-token --name <cluster_name> komutu ile bir token alabilirseniz ancak küme bilgilerini alacak izniniz yoksa (describeCluster), kendi ~/.kube/config dosyanızı hazırlayabilirsiniz. Ancak, token'a sahip olsanız bile, hala bağlanılacak url uç noktasına ihtiyacınız vardır (eğer bir JWT tokenı bir pod'dan aldıysanız buraya bakın) ve küme adına ihtiyacınız vardır.
Benim durumumda, CloudWatch günlüklerinde bilgi bulamadım, ancak LaunchTemplates userData ve EC2 makinelerinde de userData içinde buldum. Bu bilgiyi userData içinde kolayca görebilirsiniz, örneğin aşağıdaki örnekte (küme adı cluster-name idi):
EKS kümesinin oluşturucusu her zaman kubernetes kümesine (k8s yönetici) system:masters grubunun içine girebilecektir. Bu yazının yazıldığı sırada, kümenin kim tarafından oluşturulduğunu bulmanın doğrudan bir yolu yok (CloudTrail'ı kontrol edebilirsiniz). Ve bu yetkiyi kaldırmanın bir yolu yok.
AWS IAM kullanıcılarına veya rollerine K8s üzerinde erişim vermenin yolu, aws-auth adlı configmap'i kullanmaktır.
Bu nedenle, aws-auth config haritası üzerinde yazma erişimi olan herkes, tüm kümenin tehlikeye girebileceği anlamına gelir.
Aynı veya farklı hesaptaki IAM rollerine ve kullanıcılarına ek ayrıcalıklar vermenin ve bunu kötüye kullanmanın yolunu öğrenmek için bu sayfaya bakın.
Ayrıca, IAM kimlik doğrulamasının Kubernetes üzerinden nasıl çalıştığını öğrenmek için bu harika yazıyabakın.
Kubernetes'ten AWS'ye
Kubernetes servis hesaplarına AWS'de rolleri assume etmelerine izin vermek için OpenID kimlik doğrulamasına izin vermek mümkündür. Bu sayfada nasıl çalıştığını öğrenin.
JWT Belirtecindeki Api Sunucusu Uç Noktasını Al
JWT belirtecini çözerek küme kimliğini ve aynı zamanda bölgeyi alırız. EKS URL için standart formatın olduğunu bilerek
Belirli 'iki karakter' ve 'sayı' için kriterleri açıklayan herhangi bir belge bulamadım. Ancak kendi adıma bazı testler yaparak şunları tekrarlayarak gördüm:
- gr7- yl4Neyse ki sadece 3 karakter oldukları için bunları brute force yöntemiyle deneyebiliriz. Listeyi oluşturmak için aşağıdaki betiği kullanın
Bir saldırgan, bir AWS'nin EKS üzerinde izni olan kimlik bilgilerini elde ederse ve saldırgan, önceki açıklamalarda açıklandığı gibi kendi kubeconfig'ini yapılandırırsa ( update-kubeconfig çağırmadan), get-token CloudTrail'de kayıt oluşturmaz çünkü AWS API'siyle etkileşime girmez (yalnızca yerel olarak belirteci oluşturur).
Bu nedenle saldırgan EKS kümesiyle iletişim kurduğunda, cloudtrail, çalınan kullanıcıyla ilgili ve erişim sağlayan herhangi bir şeyi kaydetmeyecektir.
EKS kümesinin etkinleştirilmiş günlüklerinin olabileceğini unutmayın (ancak varsayılan olarak devre dışı bırakılmış olabilir).
EKS Fidye?
Varsayılan olarak bir küme oluşturan kullanıcı veya rolün, küme üzerinde her zaman yönetici ayrıcalıklarına sahip olacağını ve AWS'nin Kubernetes kümesi üzerinde tek "güvenli" erişiminin olacağını unutmayın.
Bu nedenle, bir saldırgan fargate kullanarak bir küme ele geçirirse ve diğer tüm yöneticileri kaldırır ve küme oluşturan AWS kullanıcısını/rolünü silerse, saldırgan kümeyi fidyeyle alabilir.
Küme EC2 VM'ler kullanıyorsa, Yönetici ayrıcalıklarını Node'dan almak ve kümesi kurtarmak mümkün olabilir.
Aslında, Eğer küme Fargate kullanıyorsa, EC2 düğümlerine veya her şeyi EC2'ye taşıyarak kümesine erişerek düğümdeki belirteçlere erişerek kümesi kurtarılabilir.