Arkadaşlar, bugün biraz farklı bi konuya değinmek istedim. Son dönemde Kubernetes cluster'larında gördüğüm bir saldırı zincirini anlatıcam. Direkt exploit yazmak yerine, mevcut CVE'leri ve yanlış konfigürasyonları nasıl birleştirip ciddi bi persistence elde edebileceğimizi konuşalım. Konu biraz uzun olacak çünkü birden fazla katmanı var.
Öncelikle hedef ortamda bir web uygulaması var, deployment'ında istemsizce "istio-proxy" tarzı sidecar'lar inject ediliyor. Bu sidecar'lar sayesinde pod içinden AWS metadata servisine (169.254.169.254) ulaşmak mümkün hale geliyor. Normalde IMDSv2 ile korunuyor ama cluster'da bazı node'larda IMDSv1 hala açık kalıyor. Bunu tespit etmek için basit bi curl ile başlıyoruz.
Hidden content - for more
Konuyu Görebilmeniz için "Beğenmeniz ve Yorum yapmaniz" Gerekir.
Bu çıktıdan sonra role adı geliyor, hemen credential'ları çekmek için ikinci istek atıyoruz. Tabii production'da rate-limit ve hop-limit kontrolleri var ama sidecar üzerinden yapınca source IP pod IP'si olduğu için biraz daha rahat oluyor.
Buradan aldığımız credential'larla AWS CLI üzerinden ECR ve S3 bucket'lara bakıyoruz. Asıl eğlence buradan sonra başlıyor. Cluster içinde bir de ArgoCD kurulu olduğunu görüyoruz. ArgoCD'nin son zamanlarda çıkan bir RBAC bypass'ı (CVE-2023-50726 benzeri mantık) ile manifest dosyalarını değiştirebiliyoruz. Değiştirdiğimiz manifest'te yeni bir init container ekliyoruz, bu container runc 1.1.5 öncesi versiyonlarda bulunan CVE-2024-21626 exploit'ini tetikleyip node'a escape ediyor.
Hidden content - for more
Konuyu Görebilmeniz için "Beğenmeniz ve Yorum yapmaniz" Gerekir.
Node'a çıktıktan sonra eBPF ile process tracing yaparak diğer pod'lardaki secret'ları izlemeye başlıyoruz. Bu kısım oldukça stabil çalışıyor çünkü çoğu cluster'da Falco veya trace gibi tool'lar sadece user-space event'lere bakıyor. Kernel seviyesinde 5-10 dakikalık bi window yakalıyoruz.
Son aşamada persistence için Kubernetes audit log'larını bypass eden bi webhook admission controller kuruyoruz. Bu controller her create pod event'inde küçük bi base64 encoded init container ekliyor. Tabii bunu yaparken de rate limiting ve namespace isolation'lara dikkat etmek lazım yoksa hemen yakalanırsınız.
Bu zincir tamamen güncel CVE'ler ve yaygın konfigürasyon hatalarına dayanıyor. Eğer cluster'ınızda hem IMDSv1 hem de eski runc versiyonu varsa işiniz bayağı zor demektir. Denemeden önce mutlaka lab ortamında test edin, yoksa production cluster'ınız anında owner değişir.
