WordPress XMLRPC.php Açığı
Bugün WordPress sitem yarım saat içinde 50’den fazla dahili sunucu hatası verince panelden sunucu durumunu bir kontrol ettim. CPU, sanal bellek ve fiziki bellek kullanımı tavan yapmıştı. Belli ki yolunda gitmeyen çok şey vardı.
Panelden ham erişim kayıtlarını indirip incelediğimde farklı IP adreslerinden ama aynı tarayıcı kimliği ile xmlrpc.php dosyasına çok sayıda istek gönderildiğini farkettim. Birileri WordPress’in geri pingleme (pingback) ve gezi izleme (trackback) servisini kullanarak DDOS saldırısı yapıyordu.
Detaylar
Bogdan Calin, şurada xmlrpc.php dosyasının istismar edilebileceği dört farklı yol açıklamış:
- WordPress kaynak adresi çözümleyip adresin var olup olmadığına bakarak farklı hata mesajları gönderir. Bu, saldırganlar tarafından ağda bir hostun mevcut olup olmadığını anlamak için istismar edilebilir.
- Eğer adres doğruysa, WordPress adreste belirtilen porta bağlanmaya çalışır. Eğer saldırgan http://altsurum:22/ gibi bir adres kullanırsa, WordPress port 22’deki altsurum hostuna bağlanmaya çalışır. Portun açık veya kapalı olmasına bağlı olarak sunucu farklı cevap verecektir. Bu da saldırganlar tarafından port taramak için kullanılabilir.
- Bu ayrıca saldırgan tarafından DDOS saldırıları için de kullanılabilir. Saldırgan geri pingleme yapması için çok sayıda bloga ulaşarak istek gönderebilir. Sonuç olarak tüm bu bloglar hedef adrese saldırmış olacaktır.
- WordPres ayrıca kimlik bilgisi içeren adresleri de desteklemektedir. Yani, saldırgan iç yönlendiricileri (internal router) yeniden ayarlamak için http://kullanici:parola@192.168.0.1/DNSdegis.asp?yeniDNS=12345 gibi bir adres de kullanabilir.
Çözüm
XML-RPC özelliğini kapatıp sorundan kurtuluversek güzel olurdu ama WordPress 3.5 sürümünden beri XML-RPC yönetim panelinden devre dışı bırakılamıyor. Sorunun çözümü için bir çok farklı yol olabilir. Mesela dosyayı yeniden adlandırılabilir. Bu şekilde WordPress 404 sayfasına yönlendirecektir. Ama bu sorunu tam anlamıyla çözmez. İstekler yine de işleneceği için sunucuyu yormaya devam edecektir.
Sunucuyu yormamak için, yani saldırının amacına ulaşmaması için Apache istekleri işlemeden önce isteklerin durdurulması gerekiyor. Dolayısıyla aşağıdaki kuralı .htaccess dosyasına eklemek sorunu çözecektir.
<Files xmlrpc.php>
Order allow,deny
Deny from all
</Files>
Ancak bu dosyaya erişimi reddetmek diğer sitelerin onu çalıştırmasını da engelleyeceği için geri pingleme ya da izleme alamayacaksınız.
Geri pinglemeler sizin için önemli ise şu kuralı (ya da özelleştirilmiş şeklini) .htaccess dosyasına eklemek sorununu çözebilir.
RewriteCond %{HTTP_USER_AGENT} ^.*WinHttp\.WinHttpRequest\.5.*$
RewriteRule .* http://%{REMOTE_ADDR}/ [F,L]
RewriteCond %{HTTP_USER_AGENT} ^-?$
RewriteRule ^ - [F,L]
İlk iki satırın yaptığı şey içerisinde WinHttp.WinHttpRequest.5 geçen tarayıcı kimliği ile gelenleri 403 sayfasına yönlendirmek. Son iki satır ise boş (sadece çizgi veya boş) bir tarayıcı kimliği ile gelenleri 403 sayfasına yönlendirmek.
Saldırı yapan kişinin/uygulamanın tarayıcı kimliği Mozilla/4.0 (compatible; Win32; WinHttp.WinHttpRequest.5 veya boş olduğundan ikisini engelleyerek sorunu çözülebilir. Ancak eğer saldırıyı yapan kişi tarayıcı kimliğini değiştirirse veya saldıran uygulamanın tarayıcı kimliği değiştirilirse çözüm işe yaramaz olacaktır.
Sonuç
Sonuç olarak ya pingler ve geri izlemelerden vazgeçerek kesin çözüm bulacaksınız ya da tarayıcı kimliği engelleyeceksiniz. Ama her ne olursa olsun erişim kayıtlarınızı sık sık inceleyin.
Sonunda bir kişi çıkmış da adam akıllı açıklamış şu işi. Ellerin dert görmesin.
xmlrpc.php dosyasını sildim, sorun çözüldü.
Eğer WordPress güncelleme sırasında dosyaları kontrol ediyorsa dosyayı tekrar yerine koyabilir. Bu durumda her güncellemeden sonra dosyayı tekrar silmeniz gerekecek.
ALLAH sizden razı olsun kardeşim..
Amin, sizden de… :)
Merhaba,
Genelde İngilizce bloglarda böyle sorunları ararım, çözüm bulurum. Çünkü Türkiyede bu tür bilgileri paylaşan sayısı gerçekten çok az. Oluşturduğun bu güzel gönderi için teşekkür ederim.
Aklıma takılan bir soru var. Biz bunu .htaccess ile engelledik ama siteadresi.com/xmlrpc.php girdiğimizde halen XML-RPC server accepts POST requests only. Bilgisini veriyor bize. Bu normal mi?
Güzel günler.
XML-RPC server accepts POST requests only (XML-RPC sunucusu sadece POST isteklerini kabul eder) mesajı bir hata mesajı değil ancak bunu görüyor olmamanız gerekiyordu.
Eğer .htaccess ile xmlrpc.php erişimini engellediyseniz bu mesajı görmemeniz gerekir. Eğer görüyorsanız şu iki sebepten kaynaklanıyor olabilir: Tarayıcınız sayfayı önbellekten gösteriyordur ya da .htaccess dosyasındaki satırlarda bir yanlışınız vardır. Tarayıcınızın önbellekten gösteriyorsa gizli sekmede/pencerede ya da başka bir tarayıcıda siteadresi.com/xmlrpc.php adresine erişmeyi deneyin. Eğer .htaccess ile engelleme doğru çalışıyorsa boş bir sayfa ya da 403 ve/veya forbidden yazılı bir sayfa ile karşılaşırsınız.
HTTP İstek Metodları hakkında daha fazla bilgi: https://goo.gl/Wv7llW
Bunu ekledim .htaccess’e okadar.
Sende de açık şu an.
Ben xmlrpc.php erişimini tamamen değil de tarayıcı kimliğine dayalı olarak kısmen engellediğim için normal bir şekilde erişebiliyorsunuz.
Bilgiler için teşekkürler.
O kadar insan yazmış ve kimse sormamış; bu dosyayı tamamen erişime kapatmamızın veya silmemizin SEO’ya etkisi nasıl olur?
Gerçekten şaka gibi madem tehlikeli bir dosya neden silmiyoruz ? Her güncelleme sonrasında gelecek olması zor bir durum oluşturmuyor. Sonuçta WordPress her ay güncelleme yapmıyor? Yapsa bile ayda bir kez bu dosyayı silmek zor olmamalı.