Yanlış yapılandırılan tek bir Kubernetes YAML, tüm GCP organizasyonunu ele geçirebiliyor

Security researcher Justin O'Leary, yanlış yetkilendirilmiş Google Kubernetes Config Connector kurulumu üzerinden izlenen bir namespace’e erişimi olan kullanıcının tek bir IAMPolicyMember manifestiyle GCP organizasyon sahipliğine yükselebileceğini gösterdi.

Security researcher Justin O'Leary, Google Kubernetes Config Connector kullanımındaki bir hatalı yapılandırmanın, tek bir YAML manifestiyle Google Cloud organizasyonunun kontrolünü ele geçirmeye izin verebileceğini ortaya koydu. Burada sorun, izlenen bir Kubernetes namespace’ine erişimi olan saldırganın, KCC üzerinden beklenenden çok daha geniş yetkiler kazanabilmesi.

KCC, Kubernetes manifestlerini izleyip bunlara karşılık gelen Google Cloud kaynaklarını ilgili API çağrılarıyla oluşturan veya güncelleyen bir GitOps tarzı denetleyici olarak çalışıyor. Tüm bu işlemleri, Google Cloud’a kendi adına kimlik doğrulaması yapan KCC servis hesabı üzerinden gerçekleştiriyor. Bu servis hesabına çoğu zaman birden fazla proje, klasör veya tüm organizasyonu yönetmeye izin veren role/owner ya da roles/resourcemanager.organizationAdmin gibi geniş roller atanabiliyor.

ConfigConfusion adı verilen teknik, KCC’nin hangi Kubernetes kullanıcısının kaynağı gönderdiğine bakmaksızın tüm Google Cloud işlemlerini yalnızca kendi servis hesabıyla yapmasını istismar ediyor. Yani, kullanıcı yetkili olmasa bile, KCC onun talimatlarını sanki yetkiliymiş gibi yerine getiriyor.

Bir saldırgan, KCC’nin izlediği bir namespace’te IAMPolicyMember nesneleri oluşturabiliyorsa, KCC servis hesabının atayabildiği herhangi bir IAM rolünü kendine bağlatabiliyor. Buna, tüm organizasyon üzerinde roles/owner atanması da dahil. Bu yükseltme, tek bir IAMPolicyMember YAML manifestiyle, bir Organization kaynağı üzerinde roles/owner rolünün saldırganın kontrol ettiği bir servis hesabına bağlanması şeklinde uygulanabiliyor.

Bu sırada Kubernetes RBAC, yalnızca kullanıcının ilgili namespace’te IAMPolicyMember kaynağı oluşturma yetkisine bakıyor. Google Cloud IAM ise sadece KCC servis hesabının istenen IAM bağlamasını yapmaya yetkili olup olmadığını kontrol ediyor. Hiçbir noktada, ilk isteği yapan Kubernetes kullanıcısının Google Cloud tarafında bu seviyede hakka sahip olup olmaması uçtan uca değerlendirilmiş olmuyor.

Ortaya çıkan tablo klasik bir confused deputy problemi: Google Cloud’da geniş yetkileri olan KCC, ondan daha düşük yetkiye sahip kullanıcıların talimatlarını sorgulamadan yerine getiriyor ve kendi ayrıcalıklarını onların adına kullanmış oluyor. Bu durum, KCC ile GitOps yaklaşımında ayrıcalıkların merkezileştirilmesinden kaynaklanıyor. Normalde geliştiricilerin Google Cloud kimlik bilgisi taşımasını gereksiz kılan model, KCC’nin aşırı ayrıcalıklı tanımlandığı ortamlarda dar Kubernetes erişimini tüm GCP organizasyon kontrolüne çevirebilen bir saldırı yüzeyi oluşturuyor.