WordPress yönlendirme saldırısı: bulma ve temizleme

WordPress yönlendirme saldırısı, siz yani site sahibi görmeyesiniz diye tasarlanır. Kötü amaçlı kod kimin geldiğine bakar ve yalnızca bazı ziyaretçileri yönlendirir: mobil kullanıcıları, Google veya sosyal medyadan gelenleri ve çoğu zaman her ziyaretçiyi yalnızca bir kez. Oturum açmış kullanıcıları ve yöneticileri ise bilerek atlar.

Bu yüzden bir müşteri "siteniz beni sahte bir ödül sayfasına attı" diyorsa ve siteniz kendi dizüstü bilgisayarınızda normal görünüyorsa, müşteriye inanın. Hedef sayfalar genellikle dolandırıcılık sayfaları, sahte çekilişler, agresif reklam ağları veya zararlı yazılım indirmeleridir. Google siteyi işaretleyebilir, ziyaretçiler de güvenini kaybeder. Yönlendirmeler birkaç belirtiden yalnızca biridir. Diğerlerini WordPress siteniz hacklendiğinin 12 işareti yazımızda bulabilirsiniz.

WordPress yönlendirme saldırısını site sahibi neden göremez?

Koşullar basit ve etkilidir. Kod, telefonları ayırt etmek için User-Agent başlığını, arama trafiğini ayırt etmek için Referer başlığını okur. WordPress oturum çerezinin olup olmadığına da bakar. İlk yönlendirmeden sonra kendi çerezini bırakır veya IP adresini kaydeder; böylece aynı kişi bir daha yönlendirilmez.

"Yeniden üretemiyorum" şikâyetlerinin çoğu bu kombinasyonla açıklanır. Siz oturum açmış durumdasınız, masaüstündesiniz, adresi doğrudan yazıyorsunuz ve belki de daha önce bir kez yönlendirildiniz. Bu koşullardan herhangi biri yönlendirmeyi devre dışı bırakmaya yeter.

Yönlendirmeyi güvenli biçimde yeniden üretin

Dosyalarda arama yapmadan önce nasıl bir yönlendirmeyle karşılaştığınızı belirleyin. Yanıt türü, hangi katmanı arayacağınızı gösterir.

Tarayıcıyla başlayın. Gizli bir pencere açın ve oturumunuzun kapalı olduğundan emin olun. Geliştirici araçlarını açın (Chrome, Edge ve Firefox'ta F12) ve telefonu taklit etmek için cihaz çubuğunu etkinleştirin (Ctrl+Shift+M). Network sekmesinde Preserve log seçeneğini işaretleyin (Firefox'ta Network ayarları menüsündeki Persist Logs); böylece sayfa değişse de kayıtlar silinmez. Gerçek bir Google yönlendireni (referrer) elde etmek için Google'da kendi alan adınızı aratın ve sonuca tıklayın.

Şimdi Network sekmesindeki ilk kayda bakın:

• **301, 302, 307 veya 308 durum kodu ve yabancı bir Location**: yönlendirme sunucu tarafında gerçekleşiyor. CDN, web sunucusu kuralları, PHP ve WordPress'in kendisi bunun içindedir.
• 200 durum kodu, ardından yabancı bir alan adına istek: sayfa normal yüklendi, sonra JavaScript (veya bir meta refresh etiketi) tarayıcıyı başka yere gönderdi. Enjekte edilmiş betik arayın.

Sonucu curl ile doğrulayın. Curl JavaScript çalıştırmaz ve siz söylemedikçe yönlendirmeleri izlemez. Aşağıdaki komut normal bir GET isteği yapar ve yalnızca yanıt başlıklarını yazdırır. curl -I kullanmayın, çünkü bazı enjekte kodlar HEAD isteklerini görmezden gelir:

curl -s -o /dev/null -D - \
  -A "Mozilla/5.0 (iPhone; CPU iPhone OS 17_5 like Mac OS X) AppleWebKit/605.1.15 (KHTML, like Gecko) Version/17.5 Mobile/15E148 Safari/604.1" \
  -e https://www.google.com/ \
  https://example.com/

Tanımadığınız bir alan adına işaret eden Location: satırı, sunucu tarafında bir yönlendirme olduğunu doğrular. Durum satırı 200 gösteriyorsa sayfa gövdesini indirin ve içinde yönlendirme kodu ile gizleme (obfuscation) izleri arayın:

curl -s -A "Mozilla/5.0 (iPhone; CPU iPhone OS 17_5 like Mac OS X)" \
  -e https://www.google.com/ https://example.com/ \
  | grep -Eio 'window\.location|location\.href|location\.replace|http-equiv=.?refresh|atob\(|eval\(|fromCharCode|script[^>]+src="[^"]+"'

Testi -A ve -e olmadan da tekrarlayın ve sonuçları karşılaştırın. Ardından bir blog yazısı, bir ürün sayfası ve iletişim sayfası gibi birkaç farklı URL'yi deneyin. Birçok enjeksiyon yalnızca bazı şablonlara dokunur.

Temiz çıkan bir sonuç sitenin temiz olduğunu kanıtlamaz. Kod her IP'yi yalnızca bir kez yönlendiriyorsa veya yalnızca belirli ülkeleri hedefliyorsa testiniz onu kaçırabilir. Başka bir ağdan, örneğin mobil veride bir telefonla yeniden deneyin.

Sunucu tarafı yönlendirmeler: .htaccess, sunucu yapılandırması ve önce çalışan PHP

curl yabancı bir alan adına 3xx gösteriyorsa, sunucuda ve WordPress herhangi bir şey üretmeden önce çalışan kodda arama yapın.

Apache'de yalnızca web kök dizinindeki değil, tüm .htaccess dosyalarını kontrol edin. User-Agent veya referrer üzerine kurulu rewrite koşullarına ve auto_prepend_file yönergesine bakın. Bu yönerge, PHP'nin her istekten önce saldırganın dosyasını yüklemesini sağlar:

grep -rn --include=.htaccess -E "HTTP_(USER_AGENT|REFERER)|auto_prepend_file" .
grep -rn --include=.user.ini --include=php.ini "auto_prepend_file" .

Bazı önbellek eklentilerinde olduğu gibi meşru RewriteCond %{HTTP_USER_AGENT} satırları da vardır. Ancak mobil veya Google trafiğini tanımadığınız bir alan adına gönderen bir kural meşru değildir.

Sonra yakın zamanda değişen PHP ve yapılandırma dosyalarını listeleyin. Saldırganlar dosya zaman damgalarını sıfırlayabilir; bu yüzden listeyi kanıt değil, başlangıç noktası sayın. Komutu WordPress kök dizininde çalıştırın:

find . -type f \( -name "*.php" -o -name ".htaccess" -o -name ".user.ini" \) -mtime -14 -print

wp-config.php dosyasının başına veya sonuna eklenmiş her şeye ve wp-content/mu-plugins içindeki her dosyaya dikkatle bakın. Must-use eklentiler otomatik yüklenir ve normal eklenti listesinde görünmez. Etkin temanın functions.php dosyasını da kontrol edin. Ardından değiştirilmiş çekirdek dosyaları yakalamak için wp core verify-checksums çalıştırın. Çıktının nasıl okunacağını ve çekirdeğin güvenle nasıl yeniden kurulacağını WordPress sağlama toplamlarını doğrulama rehberimizde bulabilirsiniz.

nginx'te kurallar .htaccess içinde değil, sunucu yapılandırmasında bulunur. Yönetilen barındırmada bunları göremeyebilirsiniz. Her iki durumda da barındırma sağlayıcınızdan sunucu düzeyinde yönlendirme kurallarını ve prepend ayarlarını kontrol etmesini isteyin.

siteurl ve home seçenekleri

Daha kaba bir başka varyant siteurl ve home seçeneklerini değiştirir. WordPress bu durumda sizin de dahil olduğunuz her ziyaretçiyi saldırganın alan adına yönlendirir. İki değeri de kontrol edin:

wp option get siteurl
wp option get home

WP-CLI yoksa phpMyAdmin'i açın ve wp_options tablosuna bakın. Tablo önekiniz wp_ olmayabilir; wp-config.php içindeki $table_prefix değerini kontrol edin. Değerleri düzeltmek için:

wp option update siteurl 'https://example.com'
wp option update home 'https://example.com'

Ayrıca grep -n "WP_HOME\|WP_SITEURL" wp-config.php komutunu çalıştırın. Bu sabitler tanımlıysa veritabanındaki değerlerin yerine geçer. Saldırgan bunları oraya yerleştirmiş olabilir; o zaman veritabanındaki düzeltmeniz hiçbir şey yapmamış gibi görünür.

Yazılarda, widget'larda, tema dosyalarında ve üstbilgi betiklerinde JavaScript yönlendirmeleri

200 yanıtının ardından başka bir alan adına geçiş, sayfada bir betiğin çalıştığı anlamına gelir. Betik birkaç yerden gelebilir:

• Yazı içeriği: post_content içine enjekte edilmiş script etiketleri; çoğu zaman düzinelerce yazıda aynı anda.
• Seçenekler: wp_options içindeki widget satırları (widget_*), tema seçenekleri ve sayfa oluşturucu ayarları.
• "Insert headers and footers" ayarları: kod parçacığı eklentileri ve sayfa oluşturucular site genelindeki betikleri burada saklar. Yönetici girişi olan bir saldırganın tek yapması gereken bir satır yapıştırmaktır.
• Tema ve eklenti dosyaları: header.php, footer.php ve kuyruğa eklenmiş JavaScript dosyaları.

Hızlı bir veritabanı araması (tablo öneki farklıysa wp_posts adını uyarlayın):

wp db query "SELECT ID, post_title FROM wp_posts WHERE post_content LIKE '%script%src=%';"
wp db search 'fromCharCode' --all-tables
wp option list --search='widget_*' --fields=option_name

Gizlenmiş kod bekleyin. Enjekte edilen kod hedef URL'yi nadiren düz metin olarak içerir. atob(, uzun base64 dizileri, String.fromCharCode ve bilinen CDN veya analitik alan adlarını biraz farklı yazımla taklit eden betik kaynaklarını arayın. Veritabanı arama tekniği ve temizlik WordPress SEO spam yazısında daha ayrıntılı anlatılıyor.

Önbellekteki kopyalar: önbellek eklentileri, sunucu önbelleği ve CDN

Kaynağı (origin) tamamen temizleyebilirsiniz, ziyaretçiler yine de yönlendirilebilir; çünkü bulaşmış sayfa hâlâ bir yerde saklanıyordur. Kopyalar sayfa önbellek dosyalarında (wp-content/cache), Redis veya Memcached gibi bir nesne önbelleğinde, barındırma sağlayıcınızın sunucu önbelleğinde ve CDN uç sunucularında kalabilir.

İstek sırasına göre, kaynaktan dışarıya doğru temizleyin:

1. Kaynakta dosya ve veritabanı temizliğini bitirin.
2. Önbellek eklentisinin sayfa önbelleğini temizleyin.
3. Nesne önbelleğini wp cache flush ile boşaltın.
4. Barındırma panelinden sunucu önbelleğini temizleyin.
5. CDN'de her şeyi temizleyin (purge).
6. Yukarıdaki curl komutlarıyla, mobil user agent ve Google referrer ile ve onlarsız yeniden test edin.

Ters senaryoyu da düşünün: biri yönlendirmeyi CDN veya DNS düzeyinde tanımlamış olabilir. CDN hesabınıza erişimi olan herkes WordPress'e dokunmadan bir yönlendirme kuralı oluşturabilir. CDN panelinizdeki yönlendirme ve sayfa kurallarını ve DNS kayıtlarınızı kontrol edin. Bu hesaplara kimlerin girişi olduğunu gözden geçirin ve artık ihtiyaç duymayanların erişimini kaldırın.

Giriş noktasını bulun, yoksa yönlendirme geri gelir

Yönlendirme yalnızca yüktür (payload), açık kapı değildir. Yalnızca yükü silerseniz, giriş yolu hâlâ açık olduğu için genellikle birkaç gün içinde geri gelir. Yaygın giriş noktaları şunlardır: güvenlik açığı olan veya nulled (korsan) eklentiler, çalınmış yönetici veya barındırma kimlik bilgileri, wp-content/uploads içindeki web shell'ler ve kodu bir cron işi ya da veritabanı seçeneği üzerinden yeniden enjekte eden arka kapılar.

Kısa bir ilk kontrol:

• Tanımadığınız yöneticiler: wp user list --role=administrator
• Sizin oluşturmadığınız uygulama parolaları (Kullanıcılar > Profil)
• Tanımadığınız zamanlanmış olaylar: wp cron event list
• Uploads içindeki PHP dosyaları: find wp-content/uploads -name "*.php"
• Güncel olmayan veya nulled eklentiler ve temalar

Açığı kapattıktan sonra yönetici, barındırma, veritabanı, SFTP ve CDN parolalarını değiştirin. Ardından wp config shuffle-salts ile salt değerlerini yenileyin. Bu, herkesin oturumunu kapatır. Kanıtların korunması ile temizleme veya yedekten geri yükleme kararı için WordPress zararlı yazılım temizleme planının tamamını izleyin.

Saldırgan müşteri verilerini, iletişim formu kayıtlarını veya siparişleri okuyabilmiş olabilir. Öyleyse olayı olası bir kişisel veri ihlali olarak değerlendirin. Bkz. GDPR (AB Genel Veri Koruma Tüzüğü) kapsamındaki 72 saatlik ihlal bildirimi.

SSS

Neden yalnızca mobil kullanıcılar yönlendiriliyor?

Telefon kullanıcıları garip bir adres çubuğunu daha az fark eder ve dolandırıcılık sayfalarına tıklama olasılıkları daha yüksektir. Site sahipleri de sitelerini genellikle masaüstünde ve oturum açmış halde kontrol eder. Yalnızca mobile uygulanan koşul, yönlendirmeyi sizden saklamak için vardır.

Google "Bu site hacklenmiş olabilir" gösteriyor. Şimdi ne yapmalıyım?

Önce siteyi temizleyin, giriş noktasını kapatın ve tüm önbellekleri temizleyin. Sonra Google Search Console'dan inceleme isteyin. Süreç WordPress SEO spam yazısında anlatılıyor. Yönlendirme gerçekten ortadan kalkmadan inceleme isterseniz talep büyük olasılıkla reddedilir.

Bir güvenlik eklentisi yönlendirmeyi benim yerime kaldırabilir mi?

Tarayıcılar yönlendirmeyi bulmanıza yardım eder. Elle temizliğin ve giriş noktası aramanın yerini tutmazlar. secaudit.eu denetim eklentisi, dosya bütünlüğünü bir referans durumla karşılaştırır ve gizli yöneticiler, şüpheli cron olayları ve veritabanındaki spam gibi ele geçirilme göstergelerini işaretler. Gizli SEO spam için de tarama yapar. Tespit eder ve raporlar. Kodu kaldırmak ve açığı kapatmak sizin veya tuttuğunuz bir uzmanın işidir.