Google Kubernetes Engine’in (GEK), Kubernetes kümesine zaten erişime sahip olması durumunda, bir tehdit aktörünün ciddi hasar oluşturmak için kullanabileceği iki kusurla tespit edildi.
İlk sorun, varsayılan yapılandırmaya sahip FluentBit ile ilişkilendirildi. FluentBit, GKE’nin tüm kümelerde varsayılan olarak çalışan günlük kaydı aracısıdır.
İkinci sorun, varsayılan ayrıcalıklara sahip olan Anthos Service Mesh’e (ASM) bağlandı. ASM, GKE ortamında hizmetten hizmete iletişimi kontrol eder.
Google Kubernetes Engine’deki Çoklu Kusurlar
Bir saldırgan, ASM’nin de yüklü olduğu bir FluentBit konteynerinde yeterli ayrıcalığa sahip olursa, tehdit aktörü Kubernetes kümesi üzerinde tam kontrole sahip olabilecek bir saldırı zinciri oluşturabilir.
MOVEit SQLi, Zimbra XSS gibi sıfır gün güvenlik açıkları ve her ay keşfedilen 300’den fazla güvenlik açığı sorunu daha da karmaşık hale getiriyor. Bu güvenlik açıklarının düzeltilmesindeki gecikmeler uyumluluk sorunlarına yol açar; bu gecikmeler, AppTrana’daki 72 saat içinde “Sıfır güvenlik açığı raporu” almanıza yardımcı olan benzersiz bir özellik ile en aza indirilebilir.
Ücretsiz Kayıt Ol
Bunu yayınladıktan sonra tehdit aktörü, veri hırsızlığı, kötü amaçlı bölmelerin konuşlandırılması ve hatta Kubernetes kümesinin operasyonlarının kesintiye uğraması gibi çeşitli eylemleri gerçekleştirebilir. Ancak Google, bu yapılandırma sorununu Aralık 2023’ün ortasında düzeltti.
FluentBit İzinlerinin Kullanımı
Bu adımda, FluentBit’e bağlı birimin içindeki her bölme, öngörülen hizmet hesabı belirtecini içeren bir kube-api-erişim birimi içerir. Bu token, hassas bilgiler olan Kubernetes API ile iletişim kurmak için kullanılır.
FluentBit bölmesinin güvenliği ihlal edilirse tehdit aktörü, düğümdeki herhangi bir bölmenin herhangi bir jetonunu kullanabilir. Bundan sonra, tehdit aktörü aynı zamanda bir pod’un kimliğine bürünerek Kubernetes API sunucusuna ayrıcalıklı erişim elde edebilir ve bunu tüm kümenin eşlenmesi, çalışan tüm pod’ların listelenmesi vb. gibi çeşitli kötü amaçlı eylemler gerçekleştirebilir.
İkinci Adım: Istio Kurulum Sonrası İzinlerden Yararlanma
Bu adım, kurulumdan sonra aşırı ayrıcalıkları koruyan ASM’nin Konteyner Ağ Arayüzü (CNI) DaemonSet’inden yararlanılmasını içerir. ASM etkinleştirildiğinde, Istio-cni-node DaemonSet de kümeye yüklenir.
Bu Daemonset, Istio CNI eklentisini kümedeki her düğüme yüklemek ve yapılandırmak için kullanılır ve ayrıca görevleri gerçekleştirmek için daha yüksek izinlere sahiptir. Ancak çalışmaya başladıktan sonra daha yüksek izinlere ihtiyaç duymaz.
Bu Daemonset için iki rol vardır; bunlardan biri RBAC (Rol tabanlı erişim kontrolü) gerektirmeyen CNI eklentisini kurmak, diğeri ise pod’ların yapılandırma olmadan başlatılıp başlatılmadığını tespit eden ve bir miktar RBAC ayrıcalıkları gerektiren “onarım” modudur.
Bu İstismarları Zincirlemek
Bu açıklardan yararlananların zincirlenmesi için pod’da bir ASM özelliğinin yüklü olması ve tehdit aktörünün Kubernetes kümesi içinde ayrıcalıklı erişim elde etmesi gerekir. Bu iki önkoşul yerine getirildiğinde tehdit aktörü bu istismarları zincirleyebilir.
Tehdit aktörü, varsayılan yapılandırmayı kullanarak FluentBit konteynerinin kontrolünü ele geçirdikten sonra bir görevi gerçekleştirebilir. Bundan sonra tehdit aktörü kube-api-access-‘e erişebilir.
Buradan tehdit aktörü herhangi bir kötü amaçlı eylem gerçekleştirebilir ve Kubernetes kümesi üzerinde tam kontrol sahibi olabilir.
Bu iki konu hakkında Palo Alto tarafından ayrıcalıklar, kavramlar, kullanım ve diğer bilgiler hakkında ayrıntılı bilgi sağlayan eksiksiz bir rapor yayınlandı.