Sabahın saat 04:20’si. Terminal ekranındaki o uğursuz kırmızı satırları görmeden hemen önce, kahve makinesinin son damlalarını fincana dolduruyordum. Krypton Finance (kurgusal şirket) altyapısında alışılmadık bir trafik akışı gözüme çarptı. Normalde e-posta sunucularının dış dünyayla kurduğu ilişki bellidir; standart protokoller, bilinen portlar. Ama bu kez, bir Zimbra düğümünden (node) çıkan paketler sanki kendi kendine konuşuyormuş gibi, tuhaf bir tempoyla 192.168[.]1[.]100 gibi iç ağdaki hassas bir noktaya dokunmaya çalışıyordu. O an anladım ki, bir şeyler 'standart' değil.
Zimbra gibi kurumsal e-posta platformları, saldırganlar için her zaman birer altın madenidir. Neden mi? Çünkü kurumun tüm hafızası orada. Sözleşmeler, şifre sıfırlama linkleri, gizli iç yazışmalar... Her şey tek bir 'box' içinde duruyor. Son dönemde Rus kökenli olduğu değerlendirilen tehdit aktörlerinin Amerika ve Ukrayna’yı hedef alarak Zimbra üzerindeki bir sıfırıncı gün (zero-day) açığını sömürdüğü haberi düştüğünde, aslında şaşırmadık. Şaşırtıcı olan, bu kadar göz önünde olan bir yazılımın hâlâ bu kadar kritik bir 'kör noktaya' sahip olmasıydı. (Kaynak: Dark Reading)
Hadi biraz teknik derinliğe inelim, çünkü bu sadece bir 'yazılım hatası' değil. Bu, girdinin (input) nasıl işlendiğine dair felsefi bir hata. Saldırganlar, Zimbra’nın SMTP daemon’ı içindeki bir boşluğu kullanarak, özel olarak hazırlanmış bir veri bloğuyla sunucuya komut koşturabiliyorlar. Burada asıl mesele, sunucunun gelen veriyi sadece bir 'posta' olarak değil, bir 'talimat' olarak algılaması. Düşünsenize, birine mektup gönderiyorsunuz ve zarfın üzerinde 'Bunu okuduktan sonra kasanın kapısını aç' yazıyor ve alıcı bunu harfiyen yapıyor. İşte uzaktan kod yürütme (remote code execution - RCE) dediğimiz o korkunç senaryonun özü bu.
Şunu hiç düşündünüz mü? Neden en modern güvenlik araçlarına sahip ekipler bile bu tür bir saldırı karşısında çaresiz kalabiliyor? Aslında cevap, bizim savunma mimarilerimizin 'güvenilen' servisleri çok az sorgulamasında yatıyor. E-posta sunucusu, doğası gereği her yerle konuşmak zorunda. Onu bir fanusun içine kapatamazsınız. Bir tatbikat ortamında test ettiğimde, benzer bir zafiyetin sömürülmesinin saniyeler sürdüğünü, ancak izlerini temizlemenin saatler aldığını bizzat gördüm. Eğer ağınızda sıkı bir mikro-segmentasyon (micro-segmentation) yoksa, o tek bir sızıntı tüm veri merkezinize yayılan bir vebaya dönüşebilir.
Zimbra'daki bu açık aslında basit bir web zaafiyeti değil—aslında yanlış söyledim, daha doğrusu mesele sadece web katmanıyla sınırlı değil, mail transfer ajanı (MTA) seviyesindeki bir işleme mantığından kaynaklanıyor. Yani siz ön tarafa dünyanın en pahalı WAF'ını (Web Application Firewall) koysanız bile, arka kapıdan gelen o zehirli paket içeri sızabiliyor. Bu noktada DevSecOps perspektifi devreye giriyor. Bizim sadece kodumuzu taramamız (SAST) veya uygulamamızı dışarıdan test etmemiz (DAST) yetmiyor; kullandığımız üçüncü parti bileşenlerin (Third-party components) o anki 'nabzını' tutmamız gerekiyor.
Sizin pipeline’ınız ne kadar güvenli? Örneğin, kullandığınız Docker imajındaki bir kütüphane bu sabah bir 'zero-day' ile uyandıysa, bunu fark etmeniz ne kadar sürer? Birçok ekip, sistemlerini bir kez kurup 'çalışıyorsa dokunma' mantığıyla bırakıyor. Oysa IaC (Infrastructure as Code) araçlarıyla, örneğin Terraform veya Helm kullanarak, bu tür durumlarda tüm e-posta altyapısını yamalanmış (patched) yeni bir sürümle dakikalar içinde değiştirebilmek bir lüks değil, zorunluluk haline geldi. Krypton Finance (kurgusal şirket) gibi yapılarda bu otomasyonun eksikliği, felaketle randevulaşmak demektir.
Bu arada, Zimbra'nın dünya genelinde özellikle kamu ve kritik altyapı sektörlerinde 200 binden fazla kurum tarafından kullanıldığını biliyor muydunuz? Bu devasa bir saldırı yüzeyi demek. Rus hacker gruplarının neden bu kadar iştahlı olduğunu anlamak zor değil.
Saldırganın perspektifinden düşünelim. Hedef bir kuruma girmek için en kolay yol nedir? Sosyal mühendislik (social engineering)? Belki. Ama doğrudan altyapıdaki bir sıfırıncı günü kullanmak çok daha 'temiz'. İz bırakmıyor, kullanıcı etkileşimi gerektirmiyor ve en önemlisi; siz daha yamanın (patch) ne olduğunu anlamadan onlar içeride kalıcılık (persistence) sağlamış oluyor. Bir kez içeri girdikten sonra ise senaryo hep aynı: attacker[.]example[.]com adresine komuta kontrol (C2) trafiği başlat, yetki yükselt (privilege escalation) ve ağda yanlara doğru hareket et (lateral movement).
Genelde şöyle bir hata yapıyoruz: 'Bizim sistemimiz güncel, bize bir şey olmaz.' Oysa sıfırıncı günün tanımı zaten bu; henüz aşısı olmayan bir hastalık. Burada asıl odaklanmamız gereken, sızıntının olacağını peşinen kabul edip (assume breach), sızıntı sonrası ne yapacağımızı planlamak. Tehdit avcılığı (threat hunting) bu yüzden sadece bir moda terim değil. Eğer loglarınızda alışılmadık bir süreç (process) türemesi veya e-posta sunucusundan gelen garip bir DNS sorgusu yakalayamıyorsanız, o sıfırıncı gün sizi uykunuzda yakalayacaktır.
Pek çok ekibin düştüğü bu tuzak, yani 'güvenlik bir üründür' sanrısı, bu Zimbra vakasıyla bir kez daha yüzümüze çarptı. Güvenlik bir süreçtir ve bu sürecin en zayıf halkası genellikle yazılımın kendisi değil, o yazılımın operasyonel süreçlerine dahil edilmeyen 'güvenlik görünürlüğü'dür. E-posta sunucunuzun neden dışarıdaki rastgele bir IP adresine şifrelenmiş veri gönderdiğini açıklayamıyorsanız, siber güvenlikte 'sahada' değilsiniz demektir.
Şimdi kendinize şu soruyu sorun: Yarın sabah uyandığınızda, kullandığınız en kritik yazılımın bir sıfırıncı gün açığıyla dünyayı sarstığını öğrenseniz, ilk 30 dakikada ne yapacağınızı biliyor musunuz? Ya da daha korkutucu olanı; o açık zaten haftalardır sömürülüyorsa ve siz sadece 'her şey yeşil' yanan dashboard’unuza bakıp kahvenizi yudumluyorsanız?
Bakalım bir sonraki yama döngüsüne kadar kaç kurum daha bu sessiz sızıntının kurbanı olacak...