Bu güvenlik açığı, 8,8'lik bir CVSS puanı kaydetti ve eklentiyi birden çok saldırı vektörüne maruz bıraktı. Yerel Dosya Dahil Etme (LFI), Sunucu Tarafı İstek Sahteciliği (SSRF) ve PHP Arşivi (PHAR) serisini kaldırmayı içerir. Uzaktan Kod Yürütmeye yol açma potansiyeli vardır. Özellikle, bu sorun 2.1.7'ye kadar olan sürümleri etkiler, ancak sonraki güncellemelerde giderilmiştir.
Kamuya açık bir Kavram Kanıtı (POC) bulunmadığından, güvenlik açığının temel neden analizini yapmayı ve bir kavram kanıtı sunmayı amaçlıyoruz.
Kamuya açık bir Kavram Kanıtı (POC) bulunmadığından, güvenlik açığının temel neden analizini yapmayı ve bir kavram kanıtı sunmayı amaçlıyoruz.
Yama Farkına Girin
WordPress eklentileri açık kaynak olduğundan, farklılık nispeten kolay olmalıdır. Neyse ki, hayatımızı kolaylaştırmak için, CVE kimliğinin NIST referansları , eklentinin 'classes/Actions.php' dosyasına işaret ediyor. 2.17 ve 2.18 sürümlerini aşağıda gösterildiği gibi farklılaştırdık:
Şekil 1: Karşılaştırılan sürümler
Şekil 2: Değiştirilen işlevler
Dosyanın güvenlik açığı bulunan ve yamalı sürümleri arasında yalnızca 2 işlevin değiştirildiğini görebiliriz; bunlar, profil resmi yüklemeyle ilgili işlevler gibi görünen 'profiles_default_cover_upload' ve 'profile_cover_upload'.
Şekil 3: Güvenlik açığının NIST açıklaması
Ayrıca, NIST açıklamasından, 'file_get_contents'ın güvenlik açığına neden olan herhangi bir temizleme yapılmadan kullanıldığını biliyoruz. Farkta da aynı şeyin yamalandığını görebiliriz, bu yüzden doğru yoldayız.
Şekil 4: image_blob verileri işleniyor
statik kod analizinden, 'image_blob' parametresi olarak geçirilen profil resmi verileri için kullanıcı girişi, belirli bir formata uymuyorsa, else bloğunun bir parçası olarak 'file_get_contents'a iletilir gibi görünüyor. Daha fazla analize geçmeden önce, dinamik davranışı anlamak için savunmasız bir ortam oluşturalım.
Exploit'i Çalıştıralım
WordPress'i kurmak nispeten kolay olmalı, sayısız çevrimiçi öğretici var. İşleri hızlandırmak için bir liman işçisi örneği kullanacağız.
Şekil 1: Karşılaştırılan sürümler
Şekil 2: Değiştirilen işlevler
Dosyanın güvenlik açığı bulunan ve yamalı sürümleri arasında yalnızca 2 işlevin değiştirildiğini görebiliriz; bunlar, profil resmi yüklemeyle ilgili işlevler gibi görünen 'profiles_default_cover_upload' ve 'profile_cover_upload'.
Şekil 3: Güvenlik açığının NIST açıklaması
Ayrıca, NIST açıklamasından, 'file_get_contents'ın güvenlik açığına neden olan herhangi bir temizleme yapılmadan kullanıldığını biliyoruz. Farkta da aynı şeyin yamalandığını görebiliriz, bu yüzden doğru yoldayız.
Şekil 4: image_blob verileri işleniyor
statik kod analizinden, 'image_blob' parametresi olarak geçirilen profil resmi verileri için kullanıcı girişi, belirli bir formata uymuyorsa, else bloğunun bir parçası olarak 'file_get_contents'a iletilir gibi görünüyor. Daha fazla analize geçmeden önce, dinamik davranışı anlamak için savunmasız bir ortam oluşturalım.
Exploit'i Çalıştıralım
WordPress'i kurmak nispeten kolay olmalı, sayısız çevrimiçi öğretici var. İşleri hızlandırmak için bir liman işçisi örneği kullanacağız.
- Buradan bir bitnami WordPress docker örneği kuruyoruz .
- Blogu yazarken, eklentinin WordPress mağazasındaki savunmasız sürümü zaten değiştirilmişti, ancak eklentinin savunmasız sürümünü buradan indirebiliriz .
- Eklenti dosyasını aşağıdaki gibi yükleyip aktif hale getirebiliriz.
Şekil 5: Eklentileri Wordpress'e Yükleme
Eklenti etkinleştirildikten sonra, ana web sayfasında aşağıdaki gibi yeni bir 'Forumlar' düğmesi bulunmalıdır.
Şekil 6: Forumlar seçeneği
Exploit için ne tür bir izin gerektiğini daha sonra anlayabiliriz, şimdilik forum alanında admin olarak giriş yapalım ve inceleyelim.
Şekil 7: Oturum Açma
Güvenlik açığının profil resmi yükleme işlevinde olduğunu önceden bildiğimiz için, profil bölümünü inceliyoruz ve bir resim yüklemeyi deniyoruz (aşağıdaki benim kedim)
Gerçekte neler olup bittiğini incelemek için BurpSuite proxy'sini çalıştırır ve trafiği inceleriz.
Şekil 9: BurpSuite'ten Yanıt İsteyin
Eylem adına 'wpforo_profile_cover_upload' (adlandırma kuralı gibi görünen wpforo başına önceden eklenen işlev adı) ve ayrıca kod analizimiz sırasında gördüğümüz gibi 'image_blob' parametresine sahip olduğumuz için aslında bitiş noktasına ulaştığımızı doğrulayabiliriz. Blobun değerinin kodunu çözersek, bunun dosya biçimi (image/jpeg), kodlama (base64) ve virgülle ayrılmış gerçek verilerden oluştuğunu görebiliriz.
Şekil 10: image_blob verilerinin kodu çözüldü
Koda tekrar bakarsak, verileri virgülle ayırmaya çalışır ve ikinci bir dizin yoksa, her şeyi 'get_file_contents'a geçirir, böylece 'image_blob' parametresinin bir parçası olarak virgül dışında istediğimizi iletebiliriz ve kodun savunmasız bölümüne ulaşıp dosyayı aşağıda gösterildiği gibi getirmelidir -
Şekil 11: Sömürü
Aynı isteği diğer savunmasız olan eylem adını 'wpforo_profiles_default_cover_upload' olarak değiştirerek deneyebiliriz ve orada da başarı elde ederiz. Görüntü olarak saklandığından dosya içeriğini geri alamıyoruz. "profiles_default_cover_upload" eylemi için veriler alınıyor, çünkü bu eylem onu settings_custom_default_cover.jpg statik adıyla kaydediyor
Şekil 12: Sabit kodlanmış görüntü yolu
Böylece, aşağıdaki gibi bir kıvrılma isteği göndererek içeriği kolayca alabiliriz
Şekil 13: /etc/passwd içeriği alındı
Açıktan yararlanmayı https://github.com/ixiacom/CVE-2023-2249 adresindeki bir kavram kanıtı koduyla uygulayabiliriz . 'file_get_contents' uzak yolları da alabildiğinden, açıktan yararlanma, kavram kanıtımızla getirilen bir dosyayı dağıttığımız aşağıdaki gibi dahili uç noktalara ulaşmak için kullanılabilir.
Şekil 14: Barındırılan dahili dosyaların taklit edilmesi
Şekil 15: Dahili dosyaları getirebilen SSRF
Yukarıdaki kavram kanıtı ekran görüntüsünde, yalnızca bir abone olan ve aynı zamanda çalışan bir kullanıcının kimlik bilgilerini sağladık, bu nedenle çok az ayrıcalık gerekir.
Şekil 16: kurban testi, düşük ayrıcalıklı kullanıcı
