WordPress backdoor tahlili: real buzilish qanday topildi va tozalandi

Yaqinda mijozimizning WordPress sayti bilan ishladik: sayt buzilgan, unda bir necha oy davomida begona kod ishlab turgan edi. Bu maqolada hujumchi qanday kirgani, nimalarni qoldirgani, biz uni qanday topganimiz va qanday tozalaganimizni ko'rsatamiz. Maqsad — qo'rqitish emas, balki shunga o'xshash holatni o'z saytingizda qanday tanib olish va nimadan boshlashni ko'rsatish.

Mijoz ma'lumotlari anonimlashtirilgan: domen, biznes turi va boshqa tafsilotlar keltirilmaydi.

Kirish nuqtasi: eskirgan plagin

Saytda Backup Migration plaginining 1.4.0 versiyasi o'rnatilgan edi. Bu versiyada ma'lum zaiflik bor — CVE-2023-6553: autentifikatsiyasiz masofadan kod bajarish (unauthenticated RCE). Ya'ni hujumchiga login ham, parol ham kerak emas: maxsus so'rov yuborib, serverda o'z PHP kodini bajara oladi.

Zaiflik ancha oldin e'lon qilingan va tuzatilgan. Lekin plagin yangilanmagan, va avgust oyida hujumchi aynan shu plagin papkasi ichiga web shell'lar joylashtirgan. Ikki oydan keyin ikkinchi to'lqin keldi: yangi fayllar, yangi yashirinish usullari.

Buzilishlarning ko'pchiligi murakkab hujum bilan emas, yangilanmagan bitta plagin bilan boshlanadi.

Hujumchi nimalarni qoldirgan

Tahlil davomida quyidagilar topildi:

• ~20 ta soxta plagin — tasodifiy nomlar bilan, w2s va undan keyin hex belgilar (masalan, w2s3fa1c9). Admin panelda ular oddiy plaginlar orasida ko'zga tashlanmaydi.
• Soxta mavzu (theme) — haqiqiy mavzular yonida.
• wp-validate.php dropper'lari — ko'plab papkalarda. Nomi WordPress fayliga o'xshaydi, lekin core'da bunday fayl yo'q.
• Yashirin papkalar — nuqta bilan boshlanadigan, tasodifiy hex qo'shimchali papkalar, ichida kichik .htaccess va index.php jufti. Ular haqiqiy plaginlar ichiga — WooCommerce, Yoast, Elementor — va wp-includes ichiga joylangan. Shuning uchun "begona plaginni o'chirish" ularni yo'q qilmaydi.
• uploads ichidagi PHP fayllar — bu papkada PHP umuman bo'lmasligi kerak.
• Tashqi domendan kod yuklaydigan loader'lar — rot13 bilan obfuskatsiya qilingan.
• Soxtalashtirilgan vaqt belgilari — fayllarning o'zgartirilgan sanasi 2020-yilga qo'yilgan (timestomping), shunda ular "eski, tegilmagan fayl" bo'lib ko'rinadi.
• O'chirilgan wp-login.php — standart kirish sahifasi yo'q qilingan.

Bularning har biri alohida qayta kirish yo'li. Bittasini qoldirsangiz, hujumchi qaytib keladi — ikkinchi to'lqin aynan shuni ko'rsatdi.

Eng yashirin qism: core fayllardagi bir qatorli yuklovchi

Doimiy (persistent) yuklovchi eng qiziq topilma bo'ldi. 9 ta WordPress core fayliga va wp-config.php ga bitta qator qo'shilgan:

@include_once("php://filter/read=zlib.inflate|string.rot13|convert.base64-decode/resource=wp-includes/...");

Bu qator nima qiladi? PHP'ning php://filter oqim o'ramidan foydalanib, diskdagi faylni o'qiydi, uni ketma-ket base64'dan dekodlaydi, rot13 bilan qaytaradi va zlib bilan ochadi — va natijani PHP kod sifatida bajaradi. Ya'ni zararli kod diskda ochiq PHP ko'rinishida turmaydi.

Bundan tashqari:

• Qatordagi satr hex escape ko'rinishida yozilgan ("\x70\x68\x70...") va tasodifiy izohlar bilan aralashtirilgan — oddiy grep 'php://filter' uni topmaydi.
• Asosiy yuk (payload) soxta .svg, .css, .js fayllar ichiga yashirilgan. Fayl nomi va kengaytmasi zararsiz ko'rinadi.
• Yuk har bir sahifa ochilganda tashqi so'rov yuborgan. Bu PHP error log'ida g'ayrioddiy qatorlar sifatida ko'rinib qolgan — tahlilni boshlash uchun birinchi ishora aynan shu bo'ldi.

Biz uni qanday topdik

1. Core fayllarni rasmiy nazorat yig'indilari bilan solishtirish

WordPress har bir versiya uchun core fayllarining MD5 nazorat yig'indilarini api.wordpress.org/core/checksums orqali e'lon qiladi. WP-CLI bu tekshiruvni bitta buyruq bilan bajaradi:

wp core verify-checksums
wp plugin verify-checksums --all

Birinchi buyruq o'zgartirilgan core fayllarni va core'da bo'lmasligi kerak bo'lgan fayllarni ko'rsatadi. Ikkinchisi wordpress.org katalogidagi plaginlarni tekshiradi (pullik plaginlar uchun nazorat yig'indisi bo'lmasligi mumkin). 9 ta o'zgartirilgan core fayl aynan shu yerda chiqdi.

2. uploads ichida PHP qidirish

find wp-content/uploads -type f -iname '*.php*'

Normal saytda bu buyruq hech narsa chiqarmasligi kerak.

3. Ma'lum belgilar bo'yicha qidiruv

find . -name 'wp-validate.php'
find wp-content/plugins -maxdepth 1 -type d -name 'w2s*'
find . -type d -name '.*' ! -name '.' ! -name '.well-known'
grep -rlE '(\\x[0-9a-fA-F]{2}){8,}' --include='*.php' .
grep -rl 'php://filter' --include='*.php' .

Hex escape'lar ketma-ketligini qidirish obfuskatsiya qilingan qatorlarni topishga yordam beradi.

4. Fayllarni vaqt bo'yicha guruhlash

Fayllarni o'zgartirilgan vaqti bo'yicha guruhlasak, bir xil daqiqada yaratilgan "to'da" ko'rinadi. Lekin timestomping tufayli mtime ga ishonib bo'lmaydi. Shuning uchun ctime (inode o'zgargan vaqti) ham tekshiriladi — uni oddiy usullar bilan soxtalashtirish ancha qiyin:

find . -type f -printf '%C+ %T+ %p\n' | sort | awk '{print substr($1,1,16)}' | uniq -c | sort -rn | head

mtime 2020-yilni ko'rsatib, ctime esa avgustni ko'rsatadigan fayllar — darhol shubhali.

5. Loglarni tahlil qilish

Access log'da web shell fayllarga POST so'rovlar va zaif plagin endpoint'iga murojaatlar, PHP error log'da esa yuklovchining tashqi so'rovlari bilan bog'liq qatorlar topildi. Bu ikki to'lqinning vaqtini aniqlashga yordam berdi.

Qanday tozaladik

Tartib muhim. Biz quyidagi ketma-ketlikda ishladik:

1. Avval dalillarni saqlash. Sayt fayllari va bazaning to'liq nusxasi, fayllar xeshlari, veb-server va PHP loglari alohida joyga ko'chirildi. Tozalashdan keyin "nima bo'lgan edi" degan savolga javob berish faqat shu nusxalar orqali mumkin.
2. Backdoor yo'llarini veb-serverda bloklash. Fayllar bilan ishlayotganda hujumchi ulardan foydalana olmasligi uchun ma'lum yo'llar veb-server darajasida yopildi:

location ~* /wp-content/uploads/.*\.php$ { deny all; }
location ~* /wp-validate\.php$          { deny all; }
location ~* /\.(?!well-known)           { deny all; }

3. Karantin, o'chirish emas. Zararli fayllar o'chirilmadi, balki veb-ildizdan tashqaridagi karantin papkaga ko'chirildi. Bu tahlilni davom ettirish imkonini beradi.
4. Core'ni toza fayllar bilan almashtirish. WordPress core rasmiy manbadan qayta yuklandi va nazorat yig'indilari qayta tekshirildi:

wp core download --version=$(wp core version) --force --skip-content
wp core verify-checksums

5. Boshqa fayllardan yuklovchilarni olib tashlash. wp-config.php va boshqa fayllardagi qo'shilgan qatorlar qo'lda olib tashlandi.
6. Zaif plaginni o'chirish. Backup Migration 1.4.0 butunlay olib tashlandi.
7. WordPress salt'larini almashtirish. wp-config.php dagi kalitlar va salt'lar yangilandi — bu barcha mavjud sessiyalarni bekor qiladi:

wp config shuffle-salts

Hali bajarilishi kerak bo'lgan qadamlar

Fayllarni tozalash — ishning bir qismi. Shundan keyin albatta quyidagilar bajariladi:

• Ma'lumotlar bazasi auditi: begona administrator foydalanuvchilar, wp_options jadvaliga qo'shilgan yozuvlar, postlar ichidagi skriptlar, spam sahifalar.
• Plaginlarni toza manbadan qayta o'rnatish — mavjud papkalarni tozalashga urinish o'rniga.
• Barcha parollarni almashtirish: WordPress foydalanuvchilari, ma'lumotlar bazasi, hosting paneli, FTP/SFTP, SSH.
• Hammasini yangilash: core, plaginlar, mavzular, PHP.

Bazani tekshirish uchun boshlang'ich buyruqlar:

wp user list --role=administrator --fields=ID,user_login,user_email,user_registered
wp db query "SELECT option_name FROM wp_options WHERE option_value LIKE '%<script%' OR option_value LIKE '%eval(%';"
wp db query "SELECT ID, post_title FROM wp_posts WHERE post_content LIKE '%<script%';"

Nima uchun bu ekspertiza uchun muhim

Rasmiy ekspertiza buzilgan saytni tekshirishi mumkin bo'lgan eng yomon holat — tekshiruvchi web shell yoki begona fayllarni o'zi topishi. Hatto sayt to'g'ri ishlayotgandek ko'rinsa ham, zaif plagin versiyasi, uploads dagi bajariladigan PHP fayllar, ochiq yashirin papkalar — har biri alohida topilma. Shuning uchun WordPress saytni ekspertizaga topshirishdan oldin uning toza ekanini tekshirish kerak, faqat "yangilash" yetarli emas. Profilaktika qadamlarini WordPress xavfsizligi checklist maqolasida yig'ganmiz.

Qisqa checklist

1. wp core verify-checksums va wp plugin verify-checksums --all toza natija beradi.
2. wp-content/uploads ichida PHP fayl yo'q va veb-server u yerda PHP bajarishni taqiqlaydi.
3. Plaginlar ro'yxatida tanimagan, tasodifiy nomli plagin yoki mavzu yo'q.
4. Nuqta bilan boshlanadigan yashirin papkalar va wp-validate.php kabi begona fayllar yo'q.
5. Core fayllarda va wp-config.php da php://filter, uzun hex satrlar yoki begona include yo'q.
6. PHP error log'ida tushunarsiz tashqi so'rovlar yo'q.
7. Administratorlar ro'yxati tekshirilgan, parollar va salt'lar almashtirilgan.
8. Barcha plaginlar so'nggi versiyada, ishlatilmaydiganlari o'chirilgan.

Xulosa

Bu holatda bitta yangilanmagan plagin hujumchiga sayt ustidan to'liq nazorat berdi, va u o'zi uchun o'nlab qayta kirish yo'llarini qurdi. Ularni topish uchun nazorat yig'indilari, fayl tizimi tahlili va loglar birgalikda kerak bo'ldi. Tozalash esa dalillarni saqlashdan boshlanib, parollar va bazani tekshirish bilan tugashi kerak.

WordPress saytingizda shunga o'xshash izlar yo'qligiga ishonch hosil qilmoqchimisiz? Skanerlash uchun ariza qoldiring — Claude AI agenti va mutaxassisimiz fayllar, plaginlar va server sozlamalarini ko'rib chiqadi, topilgan teshiklarni yopishga yordam beramiz.