Nulled Tema ve Eklenti Sitenizi Neden Hackletir?

Bir tema beğendiniz. Satış sayfasında 59 dolar yazıyor, ama arama kutusuna temanın adının yanına "v7.4 free download" yazdığınızda ilk sayfada onlarca sonuç çıkıyor. İndirdiğiniz ZIP sorunsuz kuruluyor, demo içerik içeri aktarılıyor, lisans uyarısı bile vermiyor. Site iki hafta boyunca tıkır tıkır işliyor.

Sorun genellikle üçüncü ayda görünür: Search Console'dan "bu sitede kötü amaçlı yazılım tespit edildi" bildirimi gelir, hosting firması spam gönderimi nedeniyle hesabı askıya alır ya da yalnızca mobil ziyaretçiler bambaşka bir siteye yönlendirilmeye başlar. O noktada temayı silmek işe yaramaz, çünkü tema klasöründeki kod haftalar önce başka dosyalara da yerleşmiştir.

Bu yazı ahlak dersi vermek için değil. Nulled bir pakette lisans kontrolünün teknik olarak nerede kırıldığını, aynı erişime sahip kişinin koda başka ne eklediğini, o kodun nasıl gizlendiğini ve kendi sitenizde bu izleri hangi komutlarla arayacağınızı anlatıyor. Sonunda halihazırda nulled paket kullananlar için sıralı bir temizlik planı var.

Nulled Ne Demek ve Lisans Kontrolü Tam Olarak Nerede Kırılır?#

Ticari bir WordPress eklentisi ya da teması, satın alındığını doğrulamak için tipik olarak üç şey yapar: kurulumda bir lisans anahtarı ister, bu anahtarı satıcının sunucusundaki bir uç noktaya gönderir, gelen cevabı bir transient içinde birkaç gün önbelleğe alır. Güncelleme kanalı da aynı doğrulamaya bağlıdır — anahtar geçerliyse yeni sürüm paketinin indirme adresi döner.

Basitleştirilmiş hâliyle kontrol şuna benzer:

// Orijinal: cevap satıcının sunucusundan gelir
function tema_lisans_gecerli_mi() {
    $cached = get_transient( 'tema_lisans_durumu' );
    if ( false !== $cached ) {
        return 'valid' === $cached;
    }

    $response = wp_remote_post( 'https://api.saticifirma.com/v1/activate', array(
        'timeout' => 15,
        'body'    => array(
            'key'    => get_option( 'tema_lisans_anahtari' ),
            'domain' => home_url(),
        ),
    ) );

    if ( is_wp_error( $response ) ) {
        return false;
    }

    $data = json_decode( wp_remote_retrieve_body( $response ), true );
    set_transient( 'tema_lisans_durumu', $data['status'], DAY_IN_SECONDS * 3 );

    return 'valid' === $data['status'];
}

"Null"lama işlemi bu fonksiyonu bulup dışarıya çıkan isteği devre dışı bırakmaktır. En kaba hâli tek satırdır:

// Nulled: ağa hiç çıkılmaz, her koşulda "satın alınmış" cevabı döner
function tema_lisans_gecerli_mi() {
    return true;
}

Daha özenli sürümlerde wp_remote_post çağrısı silinmez; bunun yerine pre_http_request filtresi ile satıcının alan adına giden istekler yakalanıp sahte bir "valid" cevabıyla yanıtlanır, ya da wp-config.php üstünden satıcı alan adı 127.0.0.1'e yönlendirilir. Amaç aynıdır: doğrulama zincirini koparmak.

Buraya kadar teknik olarak sıradan bir düzenleme. Kritik nokta şu: bu düzenlemeyi yapabilen kişi paketin tamamı üzerinde yazma yetkisine sahiptir ve dosyaları yeniden paketleyip dağıtan da odur. Siz sadece "lisans kontrolü kaldırılmış" bir paket indirdiğinizi sanırsınız; aslında kaynağını doğrulayamadığınız bir kişinin yeniden derlediği, hiçbir imzası olmayan bir kod yığınını sunucunuzda çalıştırırsınız.

Kırılan Sadece Lisans Değil: Pakete Ne Ekleniyor?#

Nulled paket dağıtan siteler hayır kurumu değildir. Sunucu, alan adı ve trafik maliyeti vardır; bu maliyeti karşılayan bir gelir modeli olmak zorundadır. Reklam gelirini geçen üç yaygın model şu:

Üçüncüsü en sinsisidir çünkü kurulduğu gün hiçbir şey yapmaz. Bir arka kapı, saldırgan onu kullanmaya karar edene kadar sessiz kalır. Sitenizin "aylardır sorunsuz çalışıyor" olması temiz olduğunun kanıtı değildir.

Arka kapı çoğu zaman temanın kendi klasöründe de durmaz. İlk çalıştırmada kendini wp-content/uploads/ altına, mu-plugins/ dizinine ya da çekirdek dosyaların arasına kopyalar. Bu yüzden "temayı sildim, sorun çözüldü" cümlesi hemen hemen her zaman yanlıştır. Yeniden bulaşma mekanizmalarının nasıl kurulduğunu WordPress malware temizleme yazısında ayrıntısıyla ele alıyoruz.

Zararlı Kod Nasıl Gizleniyor: Tipik Obfuscation Yöntemleri#

Kod, dosyayı açan birinin gözüne çarpmayacak şekilde saklanır. Karşılaşacağınız kalıplar sınırlı sayıdadır:

Kodlama katmanları. En bilinen kalıp, kodun base64 ile kodlanıp çalışma anında çözülmesidir. Genellikle tek katman değildir; gzinflate, str_rot13 ve base64_decode iç içe geçirilir:

// Tipik çok katmanlı yükleyici — hiçbir meşru tema bunu yapmaz
$fn = 'ba' . 'se' . '64_de' . 'code';
@eval( gzinflate( $fn( 'S8vPS0/NS7VVKC5JzEtOVUjLzEtVKMlIVchILUpVKMlXKC7NLU4tKS4A' ) ) );

İsim parçalama. Yukarıdaki örnekteki gibi fonksiyon adı parçalara bölünüp çalışma anında birleştirilir. Bu, grep -r "base64_decode" aramasını atlatmak içindir. Aynı amaçla onaltılık kaçış dizileri kullanılır: "\x65\x76\x61\x6c" dizesi eval demektir.

Dolaylı çağrı. $f = 'assert'; $f($kod); biçiminde değişken üzerinden çağrı yapılır, böylece dosyada tehlikeli fonksiyon adı düz metin olarak geçmez.

Boşlukla itme. Zararlı satır, meşru bir dosyanın sonuna yüzlerce boş satır eklendikten sonra yazılır. Dosyayı editörde açan kişi sona kadar kaydırmadığı için hiçbir şey görmez.

Masum dosya adı. wp-cache-config.php, class-wp-blocks.php, favicon_e7d1.php gibi çekirdek dosyalara benzeyen adlar seçilir. Bir tema klasöründe wp- ön ekli bir dosya görmek başlı başına şüphelidir.

Zaman damgası taklidi. Dosya yazıldıktan sonra touch ile komşu dosyaların tarihine ayarlanır, böylece "en son değişen dosyalar" listesinde öne çıkmaz.

Bu kalıpları tanımanız kod okumayı bilmenizi gerektirmez. Meşru bir tema, çalışma anında string çözüp eval etmez. Bu ikilinin bir arada bulunması tek başına yeterli sinyaldir.

Kendi Sitemde Arka Kapı Var mı, Nasıl Ararım?#

Aramaya SSH erişiminiz varsa komut satırından başlayın. Yoksa cPanel dosya yöneticisinin arama kutusu da içerik araması yapabilir, ama çok daha yavaştır.

Önce en yaygın kalıpları site kökünde tarayın:

cd ~/public_html

# Kod çalıştırma ve kodlama fonksiyonlarını birlikte ara
grep -rn --include="*.php" -E "eval[[:space:]]*\(|base64_decode|gzinflate|str_rot13|create_function" . | head -50

# Uzaktan girdiyi doğrudan çalıştıran kalıplar
grep -rn --include="*.php" -E "\\\$_(POST|GET|REQUEST|COOKIE)\[[^]]+\][[:space:]]*\)" . | head -30

# Yükleme dizininde PHP dosyası olmamalı
find wp-content/uploads -name "*.php" -o -name "*.phtml"

Son komut özellikle değerlidir: wp-content/uploads içinde bir PHP dosyası bulmanın meşru bir açıklaması yoktur. Bir tane bile çıkarsa arama aşamasını bitirip doğrudan temizlik aşamasına geçin.

Aradığınız desenleri şu tabloya göre önceliklendirin:

İkinci adım, dosyaları resmî sürümleriyle karşılaştırmaktır. WordPress.org üzerindeki eklentiler ve çekirdek için bu iş otomatiktir:

# Çekirdek dosyalarında değişiklik var mı
wp core verify-checksums

# WordPress.org'daki tüm eklentileri kendi sürümüyle karşılaştır
wp plugin verify-checksums --all

wp plugin verify-checksums yalnızca resmî dizindeki eklentiler için çalışır; premium bir eklenti için "checksum bulunamadı" uyarısı verir. Bu bir hata değildir, aracın sınırıdır. Premium paketler için karşılaştırmayı elle yapmanız gerekir: satıcının panelinden aynı sürümün orijinal ZIP'ini indirip açın ve diff ile kıyaslayın.

# Orijinal paketi geçici bir dizine aç, sonra karşılaştır
mkdir -p /tmp/orijinal && cd /tmp/orijinal && unzip -q ~/tema-7.4.zip

diff -rq /tmp/orijinal/temaadi ~/public_html/wp-content/themes/temaadi

diff çıktısında beklemediğiniz "differ" ya da "Only in" satırları varsa o dosyaları tek tek açın. WP-CLI'yi henüz kurmadıysanız WP-CLI kullanımı yazısındaki adımlar birkaç dakika sürer ve bu tür denetimleri kat kat hızlandırır.

Üçüncü adım, kod dışındaki kalıcılık noktalarına bakmaktır. Zararlı yazılım yalnızca dosyada durmaz; veritabanına da yerleşir:

# Sizin oluşturmadığınız yönetici hesabı var mı
wp user list --role=administrator --fields=ID,user_login,user_email,user_registered

# Zamanlanmış görevler arasında tanımadığınız kanca
wp cron event list --fields=hook,next_run_relative

# Otomatik yüklenen ve anormal büyüklükteki seçenekler
wp db query "SELECT option_name, LENGTH(option_value) AS boyut FROM wp_options WHERE autoload='yes' ORDER BY boyut DESC LIMIT 15;"

# Son 7 günde değişen PHP dosyaları
find ~/public_html -name "*.php" -mtime -7 -printf "%TY-%Tm-%Td %p\n" | sort

Son komuttaki çıktı, güncelleme yapmadığınız bir dönemde uzunsa dikkatle okunmalıdır.

Güncelleme Alamamak Neden Zamanla Kendi Başına Bir Açık Yaratır?#

Diyelim ki indirdiğiniz nulled paket gerçekten temiz — arka kapı yok, sadece lisans kontrolü kaldırılmış. Bu durumda bile ikinci bir risk devreye girer ve bu risk zamanla büyür.

Lisans kontrolünü kıran düzenleme, güncelleme kanalını da kapatır. Satıcının sunucusuna "yeni sürüm var mı" sorusu gitmediği için WordPress panelinizde o eklenti hiç güncelleme uyarısı vermez. Panelde "her şey güncel" görürsünüz.

Bu arada gerçek dünyada şu olur: eklentide bir güvenlik açığı bulunur, satıcı yamayı yayınlar, açık bir zafiyet veritabanına kaydedilir ve teknik ayrıntısı kamuya açılır. Otomatik tarama botları o gün itibarıyla açık sürümü çalıştıran siteleri toplu olarak taramaya başlar. Kullandığınız sürüm 14 ay öncesine ait olduğu için hedef listesindesiniz ve haberiniz yok.

Bu tablo tek bir eklenti içindir. Beş nulled bileşen kullanan bir sitede beş ayrı takvim aynı anda işler ve açık borcu birikir. Güncelleme disiplininin bütününü WordPress sertleştirme yazısında ele alıyoruz.

GPL Dağıtımı ile Nulled Arasındaki Fark Nedir?#

Bu konuda en çok karıştırılan nokta hukuk ile güvenliğin birbirine karıştırılmasıdır.

WordPress GPLv2 lisansıyla dağıtılır. WordPress'in fonksiyonlarını kullanan tema ve eklentiler türev çalışma sayılır ve aynı lisansı taşımak zorundadır. GPL, kodu aldıktan sonra yeniden dağıtma hakkını verir. Bu yüzden "GPL kulübü" denilen siteler, satın aldıkları eklentileri yeniden dağıtırken çoğu durumda telif hakkını ihlal etmez. Satıcının sattığı şey kodun kendisi değil, lisans anahtarı, güncelleme kanalı ve destektir.

Aradaki teknik fark tek cümleyle şudur: yasal GPL dağıtımında kod değiştirilmemiştir, nulled pakette tanım gereği değiştirilmiştir. Pratikte bu ayrımın da bir sınırı var — "GPL" etiketiyle dağıtım yapan birçok site aslında paketi kırıp yeniden paketliyor. Ayrımı iddiadan değil, diff çıktısından öğrenirsiniz; referans ZIP'iniz yoksa öğrenemezsiniz.

Ticari eklentilerde sıkça karşılaşılan bir başka gerçek de şu: yıllık yenileme çoğu satıcıda kullanım için değil, güncelleme ve destek için zorunludur. Aboneliğinizin süresi dolduğunda eklenti çalışmaya devam eder. Bütçe sıkışıksa doğru hamle nulled paket indirmek değil, ilk yılı satın alıp yenilemeyi bütçeye göre planlamaktır — hem kaynağı doğrulanmış kod alırsınız hem de en az bir yıl yama akışında kalırsınız. Ücretsiz alternatiflerin nasıl değerlendirileceğine WordPress tema seçimi yazısında değiniyoruz.

Halihazırda Nulled Paket Kullanıyorsanız: Temizlik Sırası#

Sırayı bozmayın; özellikle ilk iki adımı atlamak sonraki her şeyi tekrar ettirir.

1. Önce tam yedek alın, sonra hiçbir şey silmeyin. Dosya + veritabanı yedeğini bulaşmış hâliyle saklayın. Temizlik sırasında bir şeyi kırarsanız geri dönecek noktanız olur; ayrıca sonradan neyin bulaştığını incelemeniz gerekebilir. Yedek stratejisi için WordPress yedekleme yazısına bakın.
2. Envanter çıkarın. Hangi tema ve eklentilerin kaynağı belirsiz, yazın. wp plugin list --fields=name,version,status çıktısını bir yere kaydedin. Ayrıca sitenin ihtiyaç duyduğu ayarları not alın; kaldıracağınız eklentinin verisi silinebilir.
3. Kaynağı belirsiz paketleri kaldırın, üzerine kurmayın. Aynı adla temiz sürümü üstüne kurmak, klasörde kalan fazladan dosyaları silmez. Önce eklentiyi/temayı tamamen kaldırın, klasörün gerçekten gittiğini FTP'den doğrulayın, sonra temiz paketi kurun.
4. Çekirdeği yeniden yazın. wp core download --force --skip-content komutu, içerik dizinine dokunmadan tüm çekirdek dosyalarını resmî kopyalarıyla değiştirir. Çekirdeğe sızmış bir dosya varsa burada temizlenir.
5. Kalıntıları arayın. Bu yazının arama bölümündeki komutları tekrar çalıştırın: uploads altındaki PHP dosyaları, mu-plugins, beklenmedik yönetici hesapları, zamanlanmış görevler, .htaccess içeriği.
6. Bütün sırları döndürün. Yönetici parolaları, veritabanı kullanıcısı parolası, FTP/SSH parolaları ve wp-config.php içindeki güvenlik anahtarları. Anahtarlar değişince tüm oturumlar düşer; saldırganın elindeki çerez de geçersiz kalır.
7. Dosya izinlerini düzeltin. Dizinler 755, dosyalar 644, wp-config.php 640 iyi bir başlangıçtır. Ayrıntı için WordPress dosya izinleri yazısına bakın.
8. İtibar tarafını kapatın. Search Console'da "Güvenlik ve Manuel İşlemler" bölümünden inceleme talebi gönderin, arama sonuçlarında kalmış spam sayfaları için kaldırma isteği açın, hosting sağlayıcınıza temizliğin bittiğini bildirin.

Bulaşmanın kapsamı belirsizse — özellikle birden fazla site aynı hosting hesabındaysa — dosyaları temizlemek yerine temiz bir kurulum üzerine yalnızca içeriği taşımak daha hızlı ve kesin sonuç verir. Bu senaryonun adımlarını hacklenmiş site kurtarma yazısında bulabilirsiniz.

Sıkça Sorulan Sorular#

Nulled tema kullandım ama sitemde hiçbir sorun yok, yine de risk var mı?#

Belirti görmemek temiz olduğunuz anlamına gelmez. Arka kapıların işlevi zaten fark edilmemektir; kurulduktan sonra aylarca hiçbir şey yapmadan bekleyebilir, erişim üçüncü tarafa satıldığında devreye girer. Ayrıca kod tamamen temiz olsa bile güncelleme kanalı kapalı olduğu için sürüm eskidikçe bilinen açıklar birikir. En azından yazıdaki arama komutlarını çalıştırıp dosyaları resmî sürümle karşılaştırın.

Antivirüs ya da güvenlik eklentisi taraması yeterli mi?#

Yardımcı olur ama tek başına yeterli değildir. Güvenlik eklentileri bilinen imzaları ve şüpheli kalıpları yakalar; özel yazılmış ya da yeni obfuscate edilmiş bir yükleyici imza veritabanında bulunmayabilir. Ayrıca tarayıcı eklentisi sitenin kendi içinden çalıştığı için, çekirdeğe sızmış bir kod tarayıcının sonuçlarını da etkileyebilir. En güvenilir yöntem dosyaları resmî paketle karşılaştırmaktır.

Temayı silersem zararlı kod da gider mi?#

Genellikle hayır. İlk çalıştırmada kendini kopyalayan bir yükleyici, tema klasörünün dışına — yükleme dizinine, mu-plugins'e ya da çekirdek dosyalarının arasına — yerleşmiş olabilir. Ayrıca veritabanındaki zamanlanmış görev ya da gizli yönetici hesabı tema silinince kaybolmaz. Temayı kaldırdıktan sonra mutlaka kalıntı taraması yapın ve parolaları yenileyin.

GPL sitelerinden indirmek nulled ile aynı şey mi?#

Hukuken farklıdır: GPL, kodu yeniden dağıtma hakkını verir, dolayısıyla değiştirilmemiş bir paketin dağıtılması telif ihlali sayılmaz. Teknik olarak fark ise kodun değiştirilip değiştirilmediğidir. Sorun şu ki bu ayrımı iddiaya bakarak yapamazsınız; satıcının orijinal ZIP'i elinizde olmadan diff alamaz, paketin dokunulmamış olduğunu doğrulayamazsınız.

Premium eklentinin lisansı bitti, eklenti çalışmayı durdurur mu?#

Çoğu satıcıda durmaz. Yıllık yenileme genellikle güncelleme ve destek erişimi içindir, kullanım hakkı için değil. Süre dolduğunda eklenti çalışmaya devam eder, sadece yeni sürüm uyarısı ve otomatik güncelleme gelmez. Bu durumda doğru hamle kırık sürüme geçmek değil, o eklenti için bir yenileme takvimi belirlemek ya da bakımı sürdürülen ücretsiz bir alternatife geçmektir.

Nulled eklenti yüzünden hosting hesabım askıya alınabilir mi?#

Evet, en sık görülen senaryolardan biridir. Bulaşmış bir site genellikle spam e-posta gönderimi, phishing sayfası barındırma ya da başka sunuculara saldırı trafiği üretme gibi davranışlar sergiler. Bu davranışlar sunucunun IP itibarını da etkilediği için sağlayıcılar hesabı askıya alma yoluna gider. Askı kaldırıldıktan sonra da temizliği belgelemeniz istenebilir.