Zimbra Güvenlik Açığı Duyuruldu
Zimbra, Mart ayında yayınladığı blog ile tüm sürümlerini etkileyen bir açık olduğunu duyurdu. Elbette aynı duyuru ile beraber güvenlik yaması yayınlandı fakat çoğu kullanıcı bundan hala habersiz.
Öncelikle teknik altyapıyı merak edenler için zimbra zafiyetinin ilk defa duyurulduğu makaleye şu adresten ulaşabilirsiniz.Sunucum etkilendi mi?
En önemli soruyla başlayalım, sunucunuz zafiyetten etkilendiyse bunu nasıl tespit edebilirsiniz? Kullanıcı forumlarını baz alırsak yaygın durum etkilenen sunucuların kripto madencilik yaptığı yönünde. Fakat zafiyet, zimbra kullanıcısı gibi yetki seviyesi yüksek bir erişime izin verdiği için eposta sunucusu içerisindeki tüm verilerin etkilendiğini varsaymak (eposta içerikleri istismar edilebilir, hesaplar eklenebilir/silinebilir vb) daha doğru olacaktır.Saldırıya maruz kalan server için temel olarak şu iki soru sorulmalı:- Kullanıcılar Web Arayüzüne giriş yapabiliyorlar mı? Eğer giriş yapılamıyor ve “Yükleniyor” ekranında takılı kalıyorsa sunucunuz büyük bir ihtimalle zafiyetten etkilenmiştir.
- Top komutu ile kontrol ettiğiniz zaman %100 CPU kullanımına sahip bir process mevcut mu? (örneğin: zmswatch veya kthrotlds) Eğer mevcut ise zafiyetten etkilenmiş sunucu kripto madencilik yapıyor demektir.
Sunucu güvenliği ile eski mutlu günlere dönüş
Öncelikle kullandığınız Zimbra sürümü için yayınlanan yamayı yapmalısınız eğer yama yoksa veya kullandığınız sürüm güncelliğini yitirmişse son sürüme güncelleme/taşıma yapmanızı öneriyoruz.Kullanıcıların bir şeylerin ters gittiğini anlamaya başladıkları iki ana şikayet mevcut, bunları yukarıda 2 madde halinde bulabilirsiniz.Eğer Eposta Web arayüzüne erişemiyorsanız, görseldeki gibi anlamsız bir izin durumu mevcut mu kontrol edebilirsiniz.
Bu sorun için Zimbra’nın kendi scriptini kullanabilirsiniz. Eğer script tek başına çözüm olmuyorsa aşağıdaki komutları da uygulayabilirsiniz.find/opt/zimbra/mailboxd/webapps-typed -execchmod0755 {} \;find/opt/zimbra/mailboxd/webapps-typef -execchmod0644 {} \;
Dosya izinlerini düzelttikten sonra “zmcontrol restart” komutu ile servisleri tekrardan başlattığımız zaman artık kullanıcılar giriş yapabiliyor.
Fakat bu işlemler sunucuyu henüz temize çıkartmıyor.
İkinci adım olarak crontab kontrolü yapılmalı,
crontab -u zimbra -l
Crontab dosyası bozulmuş ise kullandığınız sürüme uygun bir crontab yardımıyla güncelleyebilir veya rebuild adımlarını uygulayabilirsiniz.
Crontab düzenlendikten sonra chattr +i değeri ile kilitlenmeli aksi halde zararlı script tekrardan değiştirebilir.
Kripto madencilik yapan bir process tespit ettiyseniz bu noktada kill komutu ile sonlandırabilirsiniz. Şüphelendiğiniz processin id değerini kullanarak aşağıdaki komut ile hangi dosyayı çalıştırdığını bulabilirsiniz.
ps aux | grep processid
Son aşama ise saldırgan tarafından yüklenmiş olan script ve kodları temizlemek. Payload olarak nitelenen kodlar yaygın olarak /tmp/.cache/ , /tmp/zmcat veya /opt/zimbra/log/ yollarında tespit ediliyor.
Exploitler içinse şu komutları kullanıyoruz,
find/opt/zimbra-name\*.jsp -exec grep--with-filename exec{} \;find /opt/zimbra/jetty/ -name "*.jsp" -mtime -15 -ls
bulunan dosyaların bazıları Zimbra’ya ait olabilir yine de içlerinde kod bloğuna benzer parçalar tespit edebilirsiniz, bu kod bloklarının ve zimbra’ya ait olmayan tüm scriptlerin silinmesi gerekiyor.
Eğer yama işlemini başarıyla gerçekleştirdiyseniz, zararlı kodlar ve dosyalar temizlendikten sonra herhangi bir dış müdahale kalmayacaktır. Yine de aktif kalmış herhangi bir reverse shelle karşı netstat yardımıyla trafiğinizi analiz etmeniz yerinde olacaktır.
