Easy WP SMTP Güvenlik Açıkları: Sürüm Kontrolü ve WordPress Site Temizliği

[Admin]

Easy WP SMTP Güvenlik Açıkları: Sürüm Kontrolü ve WordPress Site Temizliği​

WordPress’te e-posta gönderimini düzenlemek için kullanılan bir eklenti, giriş ekranından bağımsız olarak sitenin güvenliğini etkileyebilir. Easy WP SMTP’nin geçmişte yaşadığı güvenlik sorunları bunun örneklerinden biridir.
Mart 2019’da ortaya çıkan yetkilendirme açığı, saldırganların site ayarlarını değiştirerek yönetici hesabı oluşturabilmesine yol açıyordu. Daha sonra günlük dosyalarının açığa çıkması ve SMTP şifresinin yönetim arayüzünde görüntülenmesiyle ilgili farklı sorunlar da kayda geçti.
Bu olayları birbirinden ayırmak gerekir. Hepsi aynı koşullarda çalışmıyordu ve aynı düzeyde erişim gerektirmiyordu. Ayrıca yıllar önce yayımlanmış bir yama, o sürümün bugün bütün güvenlik sorunlarına karşı korunmuş olduğunu göstermez.
Bu rehberde geçmiş açıkların ne anlama geldiğini, hangi kontrolleri yapabileceğinizi ve ihlal şüphesi bulunan bir WordPress sitesinde nasıl ilerlemeniz gerektiğini anlatıyoruz.

Easy WP SMTP Ne İşe Yarar?​

Easy WP SMTP, WordPress’in gönderdiği e-postaları bir SMTP sunucusu veya desteklenen e-posta hizmeti üzerinden iletmek için kullanılır. İletişim formu bildirimleri, parola sıfırlama mesajları ve mağaza e-postaları bu gönderimlere örnektir.
Ancak e-posta bağlantısının çalışmasıyla eklentinin güvenli olması farklı konulardır. Test e-postasının ulaşması, ayar ekranlarının veya günlük dosyalarının doğru korunduğunu kanıtlamaz.
Bu tür eklentiler değerlendirilirken gönderim başarısının yanında güncelleme geçmişi, erişim yetkileri ve hassas bilgilerin nasıl saklandığı da incelenmelidir.

2019’daki Güvenlik Açığı Nasıl Ortaya Çıktı?​

2019 olayının merkezinde, 1.3.9 sürümünde eklenen ayar içe ve dışa aktarma özelliği vardı. İçe aktarılan verilerin işlenmesi sırasında yetkisiz kişilerin WordPress seçeneklerini değiştirmesi engellenmiyordu.
Wordfence’in olay incelemesi, saldırganların bu işlemi kullanarak kayıt ayarlarını değiştirdiğini ve ardından yönetici hesabı oluşturduğunu doğruluyor.
Sorun CVE-2019-25141 olarak kaydedildi. Güvenlik kaydında eksik yetki kontrolü ve yetersiz veri doğrulaması belirtiliyor; ilgili düzeltme sürümü ise 1.3.9.1 olarak gösteriliyor.
Buradaki ders, bir işlemin yönetim paneliyle ilişkili olmasının onu kendiliğinden korumadığıdır. İşlemi gerçekleştiren kodun, çağrıyı yapan kişinin gerçekten yetkili olup olmadığını kontrol etmesi gerekir.

admin_init Neden Tek Başına Koruma Sağlamaz?​

WordPress’te admin_init, yalnızca yönetim panelindeki sayfalar açılırken çalışan bir kanca değildir. admin-ajax.php ve admin-post.php üzerinden yapılan işlemlerde de tetiklenebilir.
Dolayısıyla “kod yönetim bölümünde çalışıyor, sadece yöneticiler erişebilir” varsayımı güvenilir değildir.
WordPress belgeleri de nonce kontrolünün kimlik doğrulama veya yetkilendirme yerine kullanılamayacağını açıkça belirtir. Kritik işlemlerde uygun yetenek kontrolü ayrıca yapılmalıdır.

Saldırganlar Hangi Ayarları Değiştiriyordu?​

İncelenen saldırılarda iki WordPress seçeneği öne çıkıyordu:

• users_can_register: Yeni kullanıcı kaydına izin verilip verilmediğini belirler.
• default_role: Yeni kaydolan kullanıcıya atanacak varsayılan rolü belirler.

Kayıt açılıp varsayılan rol yönetici yapıldığında, yeni oluşturulan hesap yüksek yetkiler kazanabiliyordu. Wordfence ayrıca bazı saldırılarda siteurl ve home seçeneklerinin değiştirildiğini, kötü amaçlı yönlendirmeler ve dosyalara eklenen betikler görüldüğünü bildirdi.
Bu nedenle olayın etkisini yalnızca “yabancı bir kullanıcı açılmış mı?” sorusuyla değerlendirmek yeterli değildir. Yönetici erişimi elde edildiyse dosyalar, ayarlar ve başka erişim bilgileri de incelenmelidir.
İçe aktarma kodunda güvenilmeyen verinin unserialize() ile işlenmesi de ayrı bir güvenlik problemidir. PHP belgeleri, güvenilmeyen girdinin bu işlevle işlenmemesi gerektiğini belirtir. Ancak böyle bir kullanımın bulunması, her kurulumda otomatik olarak uzaktan kod çalıştırılabildiğini kanıtlamaz.

Sonraki Açıklar Aynı Sorun muydu?​

Hayır. Sonraki olaylarda farklı bileşenler ve farklı saldırı koşulları söz konusuydu.

Olay	Temel sorun	Tarihsel düzeltme bilgisi
CVE-2019-25141	Yetkisiz seçenek değiştirme	1.3.9.1
2020’deki debug günlük sorunu	Hassas e-posta içeriğinin açığa çıkabilmesi	1.4.3’te listelemeye karşı önlem; sonraki sürümlerde ek koruma
CVE-2024-3073	SMTP şifresinin ayar arayüzünde görüntülenmesi	2.3.1

Bu tablo bir güncel sürüm tavsiyesi değildir. Eski bir sürümde belirli bir açığın kapatılmış olması, o sürümde kalmanız gerektiği anlamına gelmez.

2020’de Günlük Dosyalarında Ne Değişti?​

Eklentinin değişiklik kayıtlarına göre 1.4.3 sürümünde klasöre boş bir index.html dosyası eklendi. 1.4.4’te günlükler ayrı bir klasöre taşındı ve erişim koruması eklendi. 1.4.5’te ise tam e-posta içeriği yerine başlık bilgilerinin kaydedilmesine geçildi.
Bu ayrım önemlidir: Dizin listelemesini kapatmak, içindeki dosyanın doğrudan adresi bilindiğinde okunmasını her durumda engellemez.
Parola sıfırlama bağlantısı içeren bir e-postanın herkese açık günlükte tutulması, hesap güvenliğini tehlikeye atabilir. Günlüklerin erişimi ve içeriği birlikte değerlendirilmelidir.

2024’teki Açık Yönetici Erişimi Gerektiriyordu​

CVE-2024-3073 kaydı, 2.3.0 ve önceki sürümlerde SMTP şifresinin ayar alanında görüntülenmesiyle ilgilidir. Bu bilgiyi görmek için yönetici düzeyinde veya daha yüksek erişim gerekiyordu.
Dolayısıyla bu olay, hesabı olmayan herhangi bir ziyaretçinin SMTP şifresini okuyabildiği bir açık olarak anlatılmamalıdır. Özellikle ele geçirilmiş bir yönetici hesabının başka bir hizmetin kimlik bilgilerine ulaşmasını kolaylaştırabilecek bir sorun olarak değerlendirilmelidir. Düzeltme sürümü 2.3.1’dir.

Sitenizde Neleri Kontrol Etmelisiniz?​

Geçmişte sorunlu bir sürüm kullanmış olmak, tek başına sitenin ele geçirildiğini göstermez. Bununla birlikte aşağıdaki değişiklikler inceleme gerektirir:

• Tanımadığınız yönetici hesapları.
• Beklenmedik şekilde açılmış kullanıcı kaydı.
• Yeni kullanıcı rolünün yönetici olarak ayarlanması.
• Değişmiş site adresleri veya yönetici e-posta adresi.
• İstenmeyen yönlendirmeler.
• Beklenmedik dosyalar ve kod eklemeleri.
• SMTP hizmetinde olağan dışı gönderim artışı.

Bu belirtilerin başka nedenleri de olabilir. Örneğin kayıt ayarını bir üyelik eklentisi değiştirmiş olabilir. Bulguları yapılan işlemler ve sunucu kayıtlarıyla karşılaştırın.
Kullanıcı ekranındaki rol adı da tek başına yeterli değildir. WordPress’te roller, yeteneklerden oluşur; rol tanımları veya kullanıcıya verilen ek yetenekler değiştirilmiş olabilir.

WP-CLI ile İlk Kontroller​

WP-CLI kuruluysa, ilgili WordPress dizininde şu sorgularla kayıt ayarlarını okuyabilirsiniz:

wp option get users_can_register
wp option get default_role

Bu komutlar seçeneklerin değerlerini gösterir; ayarları değiştirmez.
Kullanıcıları incelemek için:
wp user list --fields=ID,user_login,user_registered,roles
Bu çıktı ilk değerlendirmeye yardımcı olur. Rol ve yetenek incelemesinin tamamı değildir.
Ele geçirilmiş bir kurulumda WordPress’i yükleyen komutlar şüpheli kodu da çalıştırabilir. Aktif ihlal şüphesinde incelemeyi izole bir kopyada veya uzman desteğiyle yürütün.

İhlal Şüphesinde Hangi Sırayla İlerlemelisiniz?​

1. Bulguları ve Mevcut Durumu Koruyun​

Temizlikten önce gördüğünüz belirtileri, fark ettiğiniz zamanı ve son yapılan değişiklikleri kaydedin. Dosyaların, veritabanının ve mevcut günlüklerin inceleme kopyasını alın.
Bu kopyayı “temiz yedek” olarak adlandırmayın. Amacı, olayın nasıl gerçekleştiğini araştırırken mevcut durumu korumaktır. WordPress’in ihlal sonrası rehberi de temizliğe geçmeden önce belgeleme ve mevcut ortamın kopyasını almayı önerir.

2. Aktif Erişimi Sınırlandırıp Açığı Kapatın​

Hosting sağlayıcınızla birlikte gerektiğinde sunucu veya proxy seviyesinde erişimi sınırlandırın. WordPress içindeki bakım ekranı, saldırganın bütün dosyalara erişimini kesen bir güvenlik önlemi sayılmaz.
Sorunlu eklentiyi güncel sürüme yükseltin veya kullanılmasını durdurun. Ardından e-posta gönderimini test edin.
Güncelleme, saldırganın daha önce bıraktığı dosyaları ve hesapları kendiliğinden temizlemez.

3. Dosyaları, Kullanıcıları ve Veritabanını İnceleyin​

WordPress çekirdek dosyalarını doğrulamak için şu komut kullanılabilir:
wp core verify-checksums
Bu komut çekirdek dosyalarını WordPress.org sağlama toplamlarıyla karşılaştırır ve doğrulama sırasında WordPress’i yüklemekten kaçınır. Ancak başarılı sonuç, tema, eklenti, yükleme dizini ve veritabanının tamamen temiz olduğunu göstermez.
Güvenlik taramasını dosya karşılaştırması ve veritabanı incelemesiyle birlikte yürütün. Şüpheli hesapları kaldırmadan önce bilgilerini kaydedin. Meşru içeriklerin sahipliğini koruyun.
Bilinen temiz bir yedekten dönüş yapılacaksa yedeğin ihlal öncesine ait olduğunu doğrulayın. Sadece mevcut dosyaların üzerine kopyalamak, sonradan eklenmiş zararlı dosyaları bırakabilir.
Mağaza sitelerinde eski veritabanına dönmek yeni siparişleri kaybettirebilir. Geri yükleme kapsamını buna göre belirleyin.

4. Erişim Bilgilerini Yenileyin​

WordPress, hosting paneli, SFTP/SSH ve etkilenmiş diğer erişimleri gözden geçirin. SMTP şifrelerini ve ilgili API anahtarlarını da kapsam dışında bırakmayın.
Temizlik tamamlandıktan sonra erişim bilgilerini yeniden yenilemek gerekebilir. İşlemleri güvendiğiniz, temiz bir cihazdan yapın.
WordPress güvenlik anahtarlarının değiştirilmesi mevcut oturum çerezlerini geçersiz kılmaya yardımcı olur. Veritabanı şifresi değiştirilirse bağlantı yapılandırması da buna göre güncellenmelidir.

Günlük Dosyalarını Nasıl Koruyabilirsiniz?​

Günlük kaydını yalnızca ihtiyaç olduğunda etkinleştirin. Gereksiz e-posta gövdelerini, şifreleri ve erişim anahtarlarını kaydetmeyin. İnceleme tamamlandığında saklama ihtiyacını yeniden değerlendirin.
Apache’de dizin listelemesi Indexes seçeneğiyle, Nginx’te ise autoindex yönergesiyle ilişkilidir. Apache’ye ait .htaccess ayarlarını Nginx için geçerli kabul etmeyin.
Listelemeyi kapatmanın yanında, günlük dosyalarının doğrudan HTTP erişimini de engelleyin. Kullanılan korumanın gerçek web sunucusu ve proxy düzeninde çalıştığını doğrulayın.

WAF ve Güncellemeler Birlikte Değerlendirilmeli​

Web uygulaması güvenlik duvarı, uygun kurallar bulunduğunda saldırı isteklerini engellemeye yardımcı olabilir. Ancak “WAF varsa güncelleme gereksizdir” sonucuna varmayın.
WordPress güvenlik rehberi güncel eklentiler kullanılmasını, kullanılmayan eklentilerin kaldırılmasını ve güvenlik duvarının ek bir katman olarak değerlendirilmesini önerir.
Kalıcı bakım için:

• Güncellemeleri düzenli takip edin.
• Otomatik güncellemeleri yedekleme ve işlev kontrolüyle birlikte planlayın.
• Yönetici yetkisini yalnızca ihtiyaç duyan hesaplara verin.
• Uygun bir iki aşamalı doğrulama çözümü kullanın.
• Yedekten geri yüklemeyi deneme ortamında test edin.
• E-posta gönderim hatalarını ve olağan dışı gönderimleri izleyin.

Sıkça Sorulan Sorular​

1.3.9.1 sürümüne geçmek bugün yeterli mi?​

Hayır. Bu sürüm tarihsel bir açığın düzeltmesidir. Bugün geliştiricinin güncel sürümünü ve mevcut güvenlik bildirimlerini değerlendirmelisiniz.

Eklentiyi güncelledim; site temizlenmiş olur mu?​

Güncelleme ile ihlal temizliği farklı işlemlerdir. Daha önce oluşturulan hesaplar, değiştirilmiş ayarlar ve zararlı dosyalar ayrıca incelenmelidir.

Dizin listelemesi kapalıysa günlükler korunmuş olur mu?​

Tek başına yeterli değildir. Dosyanın doğrudan adresinden okunması da engellenmelidir.

Yönetici listesinde yabancı hesap yoksa ihlal yok diyebilir miyim?​

Hayır. Mevcut hesaplar ele geçirilmiş veya dosya ve veritabanında başka değişiklikler yapılmış olabilir.

Easy WP SMTP’yi tamamen kaldırmak zorunda mıyım?​

Geçmişte açık yaşamış olması, güncel sürümün otomatik olarak güvensiz olduğu anlamına gelmez. Kararı güncel bakım, güvenlik bildirimleri ve ihtiyacınıza göre verin. Başka bir eklentiye geçiyorsanız parola sıfırlama, form ve mağaza e-postalarının çalıştığını mutlaka doğrulayın.