Selam dostlar, son dönemde epey kafa yorduğum bir konuyu buraya bırakıyorum. Direkt exploit yazmak yerine, 2023-2024’te hâlâ yaşayan birkaç kritik açığı birleştirip gerçekçi bir persistence + data exfil senaryosu kurdum. Konu hem Linux kernel tarafını hem de container orchestrator’ı aynı anda ilgilendiriyor, o yüzden herkesin ilgisini çekeceğini düşünüyorum.
Kısa Başlıklar:
- Neden eBPF hâlâ bu kadar güçlü?
- CVE-2023-52447 + kubelet misconfig kombinasyonu
- Gizli kanal kurulum adımları
- Tespit zorlukları ve kaçınma taktikleri
Asıl iş, eBPF programlarını kullanarak kernel seviyesinde bir “görünmez” socket oluşturmak. Normalde çoğu EDR araçları netlink veya kprobe ile yakalıyor ama son kernel yamalarında ufak bir race condition var. Bunu da Kubernetes içindeki service account token’ıyla birleştirince işler çok daha eğlenceli hale geliyor.
Öncelikle hedef kümedeki bir worker node’da yüksek yetkili bir pod’a erişimimiz olduğunu varsayalım. Pod’un service account’u cluster-admin scope’ta olmasa bile, “pod/exec” ve “pods/log” yetkileriyle kubelet API’sine doğrudan bağlanabiliyoruz.
Buradan sonra eBPF ile bir “tc egress” hook’u atıp, container içinden dışarıya çıkan trafiği manipüle ediyoruz. Normal tcpdump veya ss ile görünmüyor çünkü hook’u skb’yı klonlayarak yapıyoruz.
Bu sayede C2 trafiğini normal HTTPS paketlerinin içine gömmüş oluyoruz. eBPF programı yüklendikten sonra pod restart’ı bile programı silmiyor çünkü hook doğrudan kernel’da kalıyor.
Tespit tarafında en büyük tehlike, kube-audit log’larında “exec” çağrılarının görünmesi. Bunu da “kubectl cp” yerine doğrudan kubelet 10250 portuna raw HTTP isteği atarak bypass ediyoruz. İstek gövdesini base64 + XOR ile hafifçe şifrelediğimiz için signature tabanlı WAF’lar da kolay kolay yakalayamıyor.
Sonuç olarak, 2024 itibarıyla hâlâ birçok managed Kubernetes servisinde (özellikle eski node image’ları kullananlarda) bu zincir çalışıyor. Tek gereken şey, bir kere yüksek yetkili token yakalamak ve eBPF’yi yükleyecek kadar yetki. Bundan sonrası tamamen kernel’da saklı kalıyor.
Konuyla ilgili daha derin kernel tracepoint detayları veya farklı C2 implant varyasyonları isterseniz söyleyin, ayrıca yazarım.
Kısa Başlıklar:
- Neden eBPF hâlâ bu kadar güçlü?
- CVE-2023-52447 + kubelet misconfig kombinasyonu
- Gizli kanal kurulum adımları
- Tespit zorlukları ve kaçınma taktikleri
Asıl iş, eBPF programlarını kullanarak kernel seviyesinde bir “görünmez” socket oluşturmak. Normalde çoğu EDR araçları netlink veya kprobe ile yakalıyor ama son kernel yamalarında ufak bir race condition var. Bunu da Kubernetes içindeki service account token’ıyla birleştirince işler çok daha eğlenceli hale geliyor.
Öncelikle hedef kümedeki bir worker node’da yüksek yetkili bir pod’a erişimimiz olduğunu varsayalım. Pod’un service account’u cluster-admin scope’ta olmasa bile, “pod/exec” ve “pods/log” yetkileriyle kubelet API’sine doğrudan bağlanabiliyoruz.
Hidden content - for more
Konuyu Görebilmeniz için "Beğenmeniz ve Yorum yapmaniz" Gerekir.
Hidden content - for more
Konuyu Görebilmeniz için "Beğenmeniz ve Yorum yapmaniz" Gerekir.
Tespit tarafında en büyük tehlike, kube-audit log’larında “exec” çağrılarının görünmesi. Bunu da “kubectl cp” yerine doğrudan kubelet 10250 portuna raw HTTP isteği atarak bypass ediyoruz. İstek gövdesini base64 + XOR ile hafifçe şifrelediğimiz için signature tabanlı WAF’lar da kolay kolay yakalayamıyor.
Sonuç olarak, 2024 itibarıyla hâlâ birçok managed Kubernetes servisinde (özellikle eski node image’ları kullananlarda) bu zincir çalışıyor. Tek gereken şey, bir kere yüksek yetkili token yakalamak ve eBPF’yi yükleyecek kadar yetki. Bundan sonrası tamamen kernel’da saklı kalıyor.
Konuyla ilgili daha derin kernel tracepoint detayları veya farklı C2 implant varyasyonları isterseniz söyleyin, ayrıca yazarım.
Bu içeriği görmek için giriş yapın.