WordPress'i mi denetliyorsunuz? Eklentilerinizden başlayın

Özet

Çoğu WordPress güvenlik denetimi terstir: çekirdek güncellemelerini ve tarayıcı raporlarını vurgularken asıl zarar veren güvenlik açıkları eklentilerde yaşar. Bir SANS teknik incelemesi, ekosistemdeki güvenlik açıklarının %96'sından fazlasının üçüncü taraf eklentilerden kaynaklandığını ve yaklaşık %43'ünün kimlik doğrulama gerektirmediğini ortaya koydu. Bu makale, herkesin yanlış katmanı taradığı için saldırıya uğrayan bir site hikayesini kullanarak küçük bir dahili pazarlama ekibi için eklenti öncelikli bir denetimi adım adım anlatıyor. Her eklentiyi envantere almayı ve sınıflandırmayı, kimlik doğrulamasız saldırı yüzeylerini test etmeyi, kullanıcıları ve günlükleri elle incelemeyi ve bulguları teknik olmayan bir patronun anlayacağı bir risk diline çevirmeyi öğreneceksiniz. Sonuç, bir onay kutusu alıştırması değil, üç aylık bir triyaj ritüelidir.

Çoğu WordPress güvenlik denetimi tiyatrodan ibarettir. Bir öğleden sonrayı çekirdeği güncelleyerek, yönetici şifresini değiştirerek ve gururla "Kritik sorun yok" raporu veren bir eklenti tarayıcısı çalıştırarak geçirirsiniz. Bu sırada, dosya yüklemelerini kabul eden ve en son üç yıl önce güncellenen eklenti, davetli listesinde olmayan birini bekleyerek uploads dizininizde sessizce durur.

Rakamlar bunu destekliyor. WordPress eklentilerini taramaya ilişkin bir SANS teknik incelemesi, WordPress ekosistemindeki güvenlik açıklarının %96'sından fazlasının üçüncü taraf eklentilerden kaynaklandığını, temaların %4 ve çekirdeğin %1'in altında olduğunu buldu. Bu kusurların yaklaşık %43'ü herhangi bir kimlik doğrulama olmadan istismar edilebilir. Yani denetiminiz enerjisinin çoğunu çekirdeğe harcadığında, yan taraftaki eklenti dizininde bir orman yangını başlarken ağaçları inceliyorsunuz demektir.

Bu, çekirdek hakkında panik yapma çağrısı değil. Son zamanlarda herkese açık istismarlara konu olan wp2shell RCE gibi çekirdek güvenlik açıkları, duyuruldukları gün yamalanmalıdır. Ancak bunlar, denetim saatlerinizin çoğunu hak etmeyecek kadar nadirdir. Asıl yük eklentilere aittir ve gerçek iş akışı da burada başlar.

Önceki senaryoyu hayal edin: bir Pazar sabahı, siteniz bir kumar sayfasına yönlendiriliyor ve patronunuz e-posta atıyor: "Güvenliğimiz olduğunu sanıyordum." Güvenliğiniz vardı — bir onay kutusu denetiminiz vardı. Sonraki senaryo, eklentileri gerçekte oldukları saldırı yüzeyi olarak ele alan, onları dışarıdan test eden ve tarayıcıların göremediği şeyleri kontrol eden bir triyaj sistemidir.

2017'den beri yayında olan bir WordPress siteniz olan küçük bir pazarlama ekibindesiniz. 2019'da serbest çalışan birinin geliştirdiği özel bir etkinlik kayıt eklentisi, dosya yükleme alanı olan bir iletişim formu eklentisi ve satılmış ve artık herkese açık bir güncelleme sayfası olmayan bir kaydırıcı eklentiniz var. Bu alışılmadık bir yığın değil. Denetiminiz burada başlıyor.

---

Eklenti envanteri sizin güvenlik politikanızdır

Her eklentinin ve temanın envanterini çıkarın. Sürümü, son güncelleme tarihini, satıcının hâlâ faaliyette olup olmadığını ve gerçekten kullanılıp kullanılmadığını yazın. Ardından her birini bir kategoriye sınıflandırın: bakımı yapılıyor ve kullanılıyor, bakımı yapılıyor ama kullanılmıyor, terk edilmiş ama kullanılıyor, terk edilmiş ve kullanılmıyor. Kullanılmayanları derhal kaldırın. "Sadece ayda 50$" savunmasını görmezden gelin — kullanılmayan bir eklenti bir özellik değil, bir yükümlülüktür. Terk edilmiş ancak kullanılanlar için karar verin: değiştirin ya da riski kabul edin ve patronunuzun gördüğü bir risk kaydına yazın.

Etkinlik kayıt eklentisi terk edilmiş ancak kullanılan kategorisine giriyor. Ödemeleri alıyor ve onay e-postaları gönderiyor ve değiştirilmesi bir proje, bu yüzden şimdilik tutuyorsunuz. Ancak "bu, gelecekteki bir ihlalin en olası kaynağı" diyen bir not yazıyorsunuz ve test listesinin en üstüne ekliyorsunuz.

Saldırı yüzeyi	WordPress bilinen güvenlik açıklarındaki payı	Denetim önceliği
Üçüncü taraf eklentiler	%96'dan fazla	En yüksek — envanter çıkar, tara, test et, değiştir
Temalar	Yaklaşık %4	Orta — yalnızca özel veya güncel değilse
WordPress çekirdeği	%1'in altında	Düşük — güncel tut, devam et

SecurityWeek 2024'te 8.000'den fazla yeni WordPress güvenlik açığı saydığında, büyük çoğunluk bu türdendi: eklenti sorunları, çekirdek yamaları değil. Bir tarayıcı size açıklanmış ve CVE verilmiş olanlardan bahsedecektir. Size CVE'si olmayan özel serbest çalışan kodunu söylemez, çünkü kimse ona hiç dikkatlice bakmamıştır. Bu elle bakış sizin işiniz. Eklentiye özel kontrollerin daha derinlemesine bir incelemesi için WordPress eklentilerinizi güvenlik açıklarına karşı denetleme rehberine bakın.

---

Bir yabancı gibi test edin: şifre gerektirmeyen %43

Tarayıcınız zaten size hiçbir sorun olmadığını söyledi. Şimdi onun yapamadığını yapın: siteyi dışarıdan, oturum açmadan keşfedin. Her dosya yükleme alanıyla, her POST işleyen formla, her admin-ajax uç noktasıyla başlayın. Yükleme gerçekten dosya içeriğini mi kontrol ediyor, yoksa yalnızca uzantıyı mı? Yüklenen dosyalar nereye düşüyor ve web sunucusu bu dizinde PHP çalıştırabiliyor mu? Kimlik doğrulama gerektirmeyen eklenti kusurlarının %43'ü genellikle tam olarak bu yerlerde bulunur: kimlik doğrulamasız depolanmış XSS, keyfi dosya yükleme ve PHP nesne enjeksiyonu.

İletişim formu eklentisi ziyaretçilerin bir özgeçmiş eklemesine olanak tanır. Dosyayı ziyaretçinin orijinal dosya adını kullanarak yeniden adlandırır, bu nedenle "resume.php" yüklersiniz ve dosyayı tasarım gereği yazılabilir olan /uploads/contact/ klasörüne kaydeder. Sunucu ayrıca bu dizinde PHP çalıştırmaya izin veriyorsa, saldırgan az önce bir web kabuğu elde etmiştir. Fastly, WordPress eklentilerindeki kimlik doğrulamasız depolanmış XSS'nin aktif olarak istismar edildiğini belgelemiştir — bu niş bir slayt destesi riski değildir. Testiniz basit: bilinen içeriğe sahip bir dosya oluşturun, yükleyin ve orijinal adı ve türüyle geri gelip gelmediğine bakın. Ardından bir .php dosyası yüklemeyi deneyin. Eğer .php olarak geri gelirse, istismar edilebilir bir delik bulmuşsunuz demektir.

Bu aynı zamanda "ama güvenlik eklentimiz bir WAF'a sahip" argümanının çöktüğü yerdir. Bir WAF bilinen bir yükü engelleyebilir, ancak dayandığı yol normalleştirme kuralları genellikle sunucunun gerçekte yaptığından farklıdır. OWASP Web Güvenliği Test Rehberi, herhangi bir panelden daha iyi bir referanstır: dosya yükleme kusurlarını ve depolanmış XSS'i yöntemli bir şekilde nasıl test edeceğinizi açıklar. Ve eklentinin terk edildiğini keşfederseniz, temizlik protokolünü uygulamanın zamanı gelmiştir: terk edilmiş WordPress eklentilerinin gizli tehlikesi ölü bir eklentiyi yerinde bırakmanın, onu kaldırıp iş akışınızı ayarlamaktan neden daha kötü olduğunu açıklar.

---

Tarayıcının göremedikleri: kullanıcılar, günlükler ve eski kod

Dinamik testler şu anda açıkta olanı yakalar. Elle inceleme zaten içeride olanı yakalar. Kullanıcı hesaplarıyla başlayın: yönetici listesini açın ve sizin oluşturmadığınız hesaplara bakın. Ücretsiz e-posta adresine sahip ve arkasında insan olmayan "support" adlı bir yönetici bir meslektaş değil, bir arka kapıdır. wp-content/uploads içindeki dosya zaman damgalarını, sizin içeriğiniz olmayan yakın zamanda değiştirilmiş herhangi bir şey için kontrol edin. Sunucu erişim günlüğünü, bir kişinin tarayıcısından ziyade bir botun curl komutuna benzeyen istekler için kontrol edin.

Etkinlik eklentisinde uploads/event-headshots/ dizinine kaydeden bir "konuşmacı fotoğrafı" yüklemesi var. Test sırasında size ait olmayan bir dosya buluyorsunuz — rastgele görünümlü bir ada sahip küçük bir PHP dosyası. Bu sizin web kabuğunuz. Oraya iki hafta önce test ettiğiniz aynı yükleme açığıyla ulaşmış ve artık bir tarayıcı onu hâlâ "görmeyecek" çünkü bu bir eklenti güvenlik açığı değil; bir güvenlik açığının kanıtı. Elle inceleme onu bulur, siler ve oraya koyan IP adresi için günlüğü kontrol eder. Invicti, eklentilerdeki PHP nesne enjeksiyonunun arttığını ve kötü niyetli nesne yalnızca yürütme sırasında ortaya çıktığı için kara kutu taramalarında neredeyse görünmez olduğunu belirtti. Bunu tespit etmenin tek yolu, kullanıcı tarafından sağlanan girdide unserialize() çağırmak gibi tehlikeli kalıplar için kod okumaktır. Özel eklentinin birkaç yüz satırını okumak, bir olay müdahale avukatına ödeme yapmaktan daha ucuzdur.

Bu aynı zamanda "sadece daha fazla güvenlik eklentisi kurun" şeklindeki standart tavsiyenin sınırına ulaştığı yerdir. Üç güvenlik eklentisini üst üste eklemek size birbirini engelleyen örtüşen WAF kuralları, bir sürü yinelenen günlük e-postası ve ara sıra kendi yönetici girişinizde "yasaklandınız" hatası verir. İyi yapılandırılmış tek bir aktif güvenlik eklentisi yeterlidir. Yığına başka bir şey eklemeden önce çok fazla güvenlik eklentisinin neden ters teptiği hakkında bilgi edinin.

---

Patronunuza panik yaratmadan gerçeği söylemek

Patronunuz CVSS puanlarını veya PHP nesne enjeksiyonunu umursamaz. O, sitenin çökmesini, mağazanın sipariş almamasını ve BT bütçesini umursar. Çeviri basittir: "Bu eklentinin bilinen kimlik doğrulamasız uzaktan kod yürütme açığı var. Bir yabancı site içeriğimizi silebilir veya bir arka kapı kurabilir. Bu çeyrek içinde değiştirmemiz gerekiyor." Ardından öncelik listesini gösterin: etkinlik eklentisini değiştirin, iletişim formunun dosya yüklemesini dosya türlerini düzgün şekilde doğrulayana kadar devre dışı bırakın, tüm yönetici kimlik bilgilerini döndürün ve bir sonraki üç aylık incelemeyi planlayın.

Ayrıca bir dil avantajınız var: CISA, hangi yayınlanmış kusurların aktif olarak kullanıldığını tam olarak söyleyen Bilinen İstismar Edilen Güvenlik Açıkları kataloğunu tutar. Eklentilerinizden herhangi biri orada görünüyorsa, argüman artık teorik değildir — bilinen bir istismar vardır ve zaman sizin aleyhinize işliyor. Görünmüyorsa, yine de "acil"in ne anlama geldiğine dair bir standart olarak kullanın. CISA'nın takibi, bunun bir kimlik avı e-postası olmadığını teknik olmayan bir patrona anlatmayı kolaylaştırır; bu, saldırganların şu anda ne yaptığına dair herkese açık bir veritabanıdır. Çeyrek sona erdiğinde, tek seferlik bir onay kutusu alıştırması değil, bir iyileştirme iş akışınız olur. Güvenlik açıklarını yama döngüsüne dönüştürmek için iş akışı alışkanlığı canlı tutar.

---

Öncesi kırık bir site, telaşlı bir e-posta ve hiçbir sorun olmadığını söyleyen temiz bir tarayıcı raporuydu. Sonrası üç aylık bir ritüeldir: envanter çıkar, sınıflandır, dışarıdan test et, kullanıcıları ve günlükleri incele ve aldığın kararları ve kabul ettiğin riskleri yaz. Tarayıcı bir sağlık belgesi değil, nereye bakılacağının bir haritası haline gelir. Eklentiler ismini bildiğiniz bir liste haline gelir. Ve patronunuz bir dahaki sefere denetim hakkında sorduğunda, parmaklarınızı çaprazlamayı gerektirmeyen bir cevabınız olacak.