SQL-Injection? User hat sich Zugriff aufs Admin-Konto geholt und Änderungen vorgenommen.

Oh Mann.

In /sites/all/themes/ befindet sich die api.php

Die wurde heute früh, um 5:30 Uhr, vom Angreifer dort hochgeladen.

Das ist ein Dateimanager über den man über den Browser Zugriff auf alle Ordner/Dateien der Drupalinstallation bekommt (kannte ich bisher nicht).

Darüber hat der Angreifer einige Dateien hochgeladen, auch Module, dann damit irgendwas gemacht, und anschließend wieder restlos gelöscht.

Was diese Dateien und Module jetzt im System angerichtet haben, kann ich leider nicht erkennen/nachvollziehen.

Was tun?

Kann die Ursache eventuell an der php.ini 7.4 liegen, die nicht mehr unterstützt wird?

Kannst du ein Backup einspielen von vorgestern unter .htaccess / Passwort Schutz und dann gleich in der Konfiguration erstmal umstellen, das nur Admins neue Konten freigeben können und / oder neue User eine E-Mail Bestätigung erhalten vor Freischaltung etc. ?

Eventuell auch mit dem Hoster sprechen, wie weit der Idiot gekommen ist, also das du den Webspace komplett bereinigen kannst. Ich habe da immer Alpträume von versteckten Dateien, die man nicht sieht!

Bessere Tipps habe ich leider nicht, viel Glück...
Grüße Jenna

Ich würde dir ebenfalls raten, den Webspace einmal komplett zu leeren und Backups einzuspielen. Auch die Datenbank würde ich komplett neu aufsetzen und dann die letzte verfügbare (sichere) Sicherung einspielen.

Viel Glück!

Hallo,

danke für die Hinweise aber ich betreibe einen Root-Server, keinen Webspace.

Das System ist jetzt sauber.

Noch unter Drupal 6 schrieb ich mir ein PHP-Script (das mit jquery-autocomplete zusammenarbeitet).

Darüber kann man in einem Textfeld des User-Profiles (Node) die ersten 3 Buchstaben eines Ortes eingeben und jquery-autocomplete zeigt dann eine Liste mit max. 7 Einträgen von Städtenamen an, die mit diesen 3 Buchstaben beginnen. Man kann auch 4 oder mehr Buchstaben verwendet um den richtigen Ort zu finden/auszuwählen.

In diesem PHP-Script war die Sicherheitslücke.

Dummerweise habe ich die Städte-Tabelle, auf die das Script zugreift, in der Drupal-Datenbank angelegt.

Bei jedem Upgrade auf eine neue Drupalversion habe ich dieses Script mit übernommen (und fast vergessen). Darüber hat der Angreifer per SQL-Injection Zugriff auf die Städte-Tabelle bekommen und auch über die gesamte Drupal-Datenbank.

Wie er mein Admin-Passwort (das ja in der Datenbank verschlüsselt vorliegt) auslesen konnte, ist mir schleierhaft. Höchstwahrscheinlich hat er den Hash oder die Session geklaut und konnte sich darüber einloggen. Wie er das genau gemacht hat, weiß ich nicht.

Er hat dann, in einem Contribmodul, zusätzlichen Code eingefügt, der dafür sorgte, dass im Footer jedes Nodes ein JS-Script eingebunden und aufgerufen wurde. Das führte dazu, dass jeder User/Besucher meiner Webseite über einen Affilate-Link auf eine Pornseite umgeleitet wurde.

Der Affilate-Link war "zerstückelt" und codiert, sodass man mit "find" oder "grep" die einzelnen Link-Stück (z.B. "trafficpartner") nicht finden konnte.

Zum Glück hatte ich vor einigen Jahren ein Script geschrieben, dass Änderungen in der Drupal-Datenbank mitloggt. Der Angriff, bis zum Erfolg, dauerte 3 Stunden und in diesem Logfile waren tausende Einträge, da meine User ja auch aktiv waren (Bilder hochgeladen, Nachrichten verschickt, ihre Profile geändert haben usw) und ich musste diese tausende Logeinträge händisch durchschauen und überprüfen. Darüber habe ich herausgefunden, wo der Angreifer aktiv war und welche Änderungen er vorgenommen hat.

In der Datenbank ist kein Code zu finden, den man als Backdoor verwenden kann.

Anschließend habe ich noch mit den Modulen "hacked" und "diff" die Drupalinstallation überprüft ... und weil ich schon dabei mit "find (...) -mtime -1" den gesamten Server auf veränderte Dateien (in den letzten 24 Stunden) durchsuchen lassen.

Das alles hat die ganze Nacht gedauert.

Die Sicherheitslücke ist geschlossen, die Städtetabelle habe ich in eine eigene Datenbank verschoben (mit neuem (User/Group)) und den Schreibzugriff (dort) deaktiviert. Falls der Angreifer noch eine andere Möglichkeit findet, per SQL-Injection einzubrechen, bekommt er nur Zugriff auf die Städtedatenbank. Weiter kommt er dann nicht.

Ich schreibe gerade an zwei Shell-Scripten.

Nr. 1 sorgt dafür, dass morgends um 3:30 Uhr ein Backup der gesamenten Drupalinstallation erstellt wird, und dann, gezippt und verschüsselt (10GB), auf eine andere Festplatte kopiert wird.
Nr. 2 wird, per Cron, alle 5 Minuten aufgerufen und überprüft, ob jemand sich die Rolle "administrator" verschafft hat, was mir dann sofort per Mail oder SMS mitgeteilt wird.

So, das wars, im großen und ganzen.

Der Hacker war aber (zum Glück) nur ein halbböser ... er hat sogar ein Foto hinterlassen, auf dem eine männliche Person zu sehen ist, die mit einem Glas Bier der Kamera zuprostet und dabei grinst. Ob das der Angreifer ist, ist unwahrscheinlich, aber wer weiß

Aber, da er Adminrechte erlangt hatte, hätte der mir meine gesamt Drupalinstallation, samt Datenbank, löschen können, was er aber nicht getan hat. Darüber bin ich froh, denn das letzte Backup ist schon ein paar Tage alt.

Und, ich habe viel gelernt, denn so etwas habe ich das erste Mal überhaupt erlebt und bin jetzt senibilisiert und weiß mehr..

Gruß Ionit

Ich weiß gar nicht wo ich anfangen sollte, um alles aufzulisten, was hier unklug realisiert wurde. Leider sind irgendwelche "einfachen" Datenbank-Abfragen häufig gerne für irgendwelche Autocompletion Aufgaben eine Ursache für SQL-Injections. Dafür ein zweite DB zu nutzen hilft vllt. ein wenig in diesem Kontext. Leider erschwert dies dann Backup-Skripte und Automatische Tests, die in einem sinnvollen Drupal-Betrieb nützlich wären. Am besten als konkreten Tipp auch für alle anderen für die Zukunft: Mit einer sauberen Datenbank-Abfrage, die der Core bereit stellt sowie auch "Bereinigungs"-funktionen (Sanitation) für User-Angaben aller Art wäre das nicht passiert. Hier gäbe es noch viel zu schreiben, aber das wäre für diesen post zu viel. Nur so viel: Wenn ein boshafter Angreifer eine SQL-Injection von Remote ausnutzen kann, dann kann sich dieser auch des User 1 bemächtigen. Das Skript bezüglich der Role-Überprüfung bringt somit nicht viel. Ich würde vor allem mehr Zeit in die Absicherung von Custom Code stecken. Das Einspielen von Security Updates für Server und Drupal setze ich hier mal vertrauensvoll voraus.

Wenn der Webserver übrigens genau so "geschickt" konfiguriert wurde wie der angreifbare Custom Code, könnte sich Angreifer auch Zugriffe außerhalb des Drupal-Systems verschafft haben. Vor solchen Neben-Effekten wurde vom offiziellen Drupal Security Team 2014 im Zusammenhang mit Drupalgeddon (auch SQL-Injection from Remote) auch explizit gewarnt. Da wurde generell empfohlen im Zweifel auch Server neu aufzusetzen

Da hier offensichtlich eine User-Datenbank kompromittiert wurde gehe ich davon aus, daß hier auch Informationspflichten bezüglich der DSGVO in Wege geleitet wurden/werden.

Um Abschließend noch ein Moderations-Hinweis: Bitte den Thread als "[gelöst] " markieren.

Da hier offensichtlich Schadcode an eine Stelle geladen wurde, an dem er am besten gar nicht ausführbar sein sollte, hier noch ein Hinweis auf ein altes und leider immer noch auch von Drupaladmins viel zu sehr vernachlässigtes Thema:
Sichere Dateirechte: Wissen verbreiten und Provider überzeugen

Das ist leider sehr einfach, wenn er schon soweit gekommen ist, ich brauchte das auch mal und wenn er ohnehin in die DB kommt, dauert das 2 Min.

Vor Jahren hatte ich für ein halbes Jahr auch mal einen eigenen Rootserver und bin wieder auf einen Top betreuten Flexserver (Managed-Server) umgestiegen, mit 24/7 Support (echte Techniker, kein CallCenter), weil es fast nicht mehr möglich ist auf dem laufenden zu bleiben, um immer wieder neue Schwachstellen abzusichern und mir war das auch zeitlich ein zu hoher Aufwand. Mein Hoster macht bei diesem Tarif jede Nacht ein komplettes Backup des gesamtes Servers (alle Installationen) und ich kann diese rückwirkend 14 Tage auf alle einzelnen Sicherungspunkte wieder einspielen lassen. Eigene Backups sind natürlich zusätzlich jederzeit möglich. Kostet ein paar Euro mehr, aber mir ist es das wert.

Ich stimme Carsten zu, das die jetzige Lösung nicht wirklich 100 pro Sicherheit bietet. Wenn schon eine 2. DB, dann pack doch alle Orte als Taxo-CSV da rein und nehme eine Autocomplete-Auswahl als Modul. Drupal ist doch die Menge der Taxonomiebegriffe völlig egal und zudem kannst du dieses Feld überall wieder verwenden, ohne mit eigenen Scripten zu arbeiten.

Guck dir doch mal https://www.drupal.org/project/autoban an, ich hatte das im Einsatz und das ist echt genial (eigene Rules erstellen usw.). Da kommt so schnell keiner mehr ins System, zumindest nicht, wenn er mehr als 2 oder 3 Anläufe braucht, was ja fast immer der Fall ist (glaube ich...). Der einzige Grund, warum ich das momentan nicht nutze, ist, das ich mich mehrmals selbst ausgesperrt habe, das lag aber daran das ich nicht so viel Zeit in die Logik gesteckt habe bzw. die logischen Schritte meiner eigenen Rules nicht bis zu Ende gedacht habe.

Grüße Jenna