SQL Injection – Drupal 7.31 User "drupaldev" mit der Rolle "megauser"

Stimmt, bei einer meiner Seiten gibt es auch diese Rolle megauser.
Was mich wundert: Diese Rolle hat keinerlei Rechte.
D.h. der User "drupaldev" kann also nicht viel machen.
Was ist dann der Sinn von so einer Attacke?
Trotzdem muß natürlich das Sicherheitsupdate eingespielt werden.

Nein, wenn da jemand dran war kann da noch viel mehr passiert sein. Je nachdem, wie unsicher das Gesamt-System (Server) konfiguriert ist könnte sogar Schadcode dazu installiert worden sein. Denn der Angreifer könnte zwischenzeitlich Zugang zum User/1 gehabt haben darüber das PHP-Modul installiert haben und danach wieder aufgeräumt haben und vieles mehr.
Man sollte alle aktiven User-Sessions löschen mit Zusatzmodul, schauen ob (noch) das PHP-Modul aktiv ist (und eigentlich nicht sein sollte) usw. Auf jeden Fall sollte man sich das betroffene System ganz genau anschauen.

edit: Link zur Sicherheits-Meldung: Gefährliche Sicherheitslücke in Drupal 7: Dringend Patch einspielen oder auf Version 7.32 wechseln

Wie kann ich denn nachvollziehen ob eine Installation betroffen ist?

Ich habe bei allen Installationen das Update durchgeführt und es erscheinen nirgendwo neue Rollen oder User.

Kann man nun sicher davon ausgehen das die Site nicht betroffen ist oder gibt es bestimmte Tabellen in der MySQL die man noch händisch prüfen sollte?

Grüße Jenna

Wenn keine User und Rollen angelegt wurden, sollte der Krug an Dir vorrüber gegangen sein.

Ich möchte keine Panik schüren, aber wir haben es bei dieser Sicherheitslücke wirklich mit einer sehr boshaften zu tun. Als ich in einem Contib-Modul eine SQL-Injection-Lücke entdeckt habe (siehe SA-CONTRIB-2014-075), habe ich, ohne dies jemals zuvor gemacht zu haben in 30 Minuten einen Exploit gebaut, um als nicht angemeldeter Besucher eine boshafte Datenbank-Abfrage zu machen. Mein Beispiel-Hack, den ich auch auf dem Drupal-Meetup Frankfurt im August präsentiert habe, erlaubt das ersetzen der Mail-Adresse vom user/1 und dessen Ersatz mit der Anfangs-Adresse nach erfolgreichem Zusenden des One-Time-Logins.

Nein, das kann sehr trügerisch sein. Ein geschickter Angreifer verwischt seine Spuren! Wenn ich boshaft diese Sicherheitslücke ausnutzen wollte, würde ich mir nur Zugang zum user/1 verschaffen und so wenig verdächtige Daten einbringen inkl. weiterer Benutzer, wie nur irgend möglich. Der Nachteil an "digitalen Einbrüchen" ist, daß man einerseits leicht die "Tür" leider reparieren kann und auch nicht so leicht erkennbar ist, wenn Daten gestohlen wurden, da man sie in der Regel ja nur kopieren kann. Die Drupal-Internen Logs assen sich auch löschen, somit macht es auch Sinn z.B. in die Server-Logs zu schauen.

Der Weg vom User/1 über den PHP-Filter zu allem, was dem Webserver via PHP erlaubt ist ermöglicht bösen Leuten enorme Möglichkeiten. Die meisten mir bekannten managed Hosting-Server erlauben leider auch zu viel "Drupal kann sich selbst manipulieren". Aber auch Root-Server sind diesbezüglich nicht immer optimal konfiguriert. Mit zwei Linux-Usern zu operieren, macht sehr viel Sinn wie ich müde werde zu erwähnen (z.B. hier).

Auf jeden Fall macht es neben dem Blick ins Drupal-"Backend" auch Sinn, sich mal die PHP-Files anzuschauen, ob diese verändert wurden. Oft wird versucht über die Templates Schadcode in dafür anfällige Browser zu bekommen. Ich würde den Stand der Dinge sichern und offline in Ruhe noch mal durchsuchen und dann den gesamten Core und Contrib-Module austauschen. Module wie "hacked" helfen auch bei der Analyse. Dann sollte man noch schauen, ob eigener Code wie z.B. Templates und Custom Module nicht manipuliert wurde. Vor allem, sollte man auch schauen, ob sich nicht irgendwo im Webroot nun neue verdächtige Dateien verbergen.
Mit Zusatz-Modulen kann man allen seine Beeutzer die aktiven Sessions löschen und dazu zwingen, neue Passwörrter zu setzen. Anfangen würde ich dabei den Admins.

Wenn man übrigens Drush-Zugang hat, kann man ein Drupal-System auch massiver abschotten z.B. mit dem von mir geschriebenen Modul "gate". Damit wäre mein eigener Hack über die E-Mail-Adresse vom user/1 z.B. nicht möglich.

Vielen Dank Carstens für Deine Tipps!

Vielen Dank Carsten für die ganzen Infos.
Bei einer Installation habe ich vom 23.10. diese Einträge unter Drupal Reports gefunden, können die damit zusammen hängen?

Ich kann allerdings keine weiteren Benutzer oder Rollen finden, weder in Drupal noch in der DB.

Ich habe auch nach den 3 Meldungen gegoogelt und es scheint sich um andere Probleme zu handeln, da Threads dazu existieren die 1-2 Jahre alt sind. Nur sind diese Meldungen in den letzten 2 Jahren nie aufgetaucht und es wird auch an der Seite nicht aktiv gearbeitet, keine neuen Module oder Inhalte, daher meine Nachfrage woher die Meldungen so plötzlich kommen könnten.

Grüße Jenna ( @montviso, deine Lösung hat mir besser gefallen....)

Hier ist ja über's Wochenende viel passiert. Ich habe nun mal die Seiten genauer unter die Lupe genommen. Wie schon erwähnt habe ich bei alle Angriffen die selben Einträge für User und Rolle gehabt - mit dem Unterschied zu dir – montviso – dass diese erstellte Rolle durchaus mit Rechten bestückt war.

Ich habe jetzt erst mal den Patch eingesielt und mir lokale Sicherungen abgelegt. Zwei der Seiten haben keine weiteren Auffälligkeiten im Code.
Bei einer habe ich jedoch das hier gefunden:

Dieser Eintrag tauchte bei mir 2 Mal in den Core-Modulen filter und profile in dort abgelegten Dateien den Namen qjwu.php und moui.php auf.

Was genau macht denn der Code?

Das mit dem Cookie-Code habe ich auf dem ersten Blick noch nicht ganz verstanden. Die Ausgabe von "phpinfo();" dient aber wohl zum weiteren Ausspähen des Systems.

Bedeutet das, das man unter Module den PHP Filter an sich deaktiviert lassen sollte, würde schon die Aktivierung eine Lücke ermöglichen?

Falls ja, was macht man dann mit Modulen wie https://www.drupal.org/project/views_pdf die nur in Abhängigkeit vom PHP Filter laufen.

Noch kann ich alles umbauen, wüßte nur gern ob der Aufwand Sinn macht und ob ich das richtig verstanden habe, besten Dank....

Grüße Jenna

Hacked! in Verbindung mit Diff geht ab - vielen Dank für den super Tipp.

Grüße Simon

Erst ab Drupal 8 wird PHP Filter ein Contrib-Modul. Solange ist es ja da, wenn man es nicht automatisch raus schmeißt nach update.
Ich selbst finde das Modul nicht so böse wie manch anderer. Wichtig ist vielmehr daß das ganze Drupal-System sich nicht selbst manipulieren dürfen sollte per Server-Konfiguration, das heißt vor alem nur dort Dateien ablegen und verändern zu dürfen, die nicht ausführbar sind wie man es z.B.a uch zum Speichern von PDF-Dateien benötigt.
Was ich mit meiner Aussage meinte ist, daß eben der user/1 sich das PHP-Modul selbst aktivieren kann und dann darüber mehr Möglichkeiten bekommt.

Hallo zusammen,

bei mir haben sich auch zwei User eingeschlichen, u.a. "Drupaldev/Megauser". Ich habe heute auf die aktuelle Version upgedatet und die beiden User aus der Datenbank entfernt. Reichen diese Maßnahmen aus um die Seite wieder sicher zu machen?

Danke schonmal!

https://www.drupal.org/PSA-2014-003

http://t3n.de/news/drupal-kritische-luecke-575379/
http://www.heise.de/security/meldung/Drupal-Luecke-mit-dramatischen-Folg...
http://www.zdnet.com/drupal-warns-unless-you-patched-within-seven-hours-...

Ein ähnliches Muster wurde auch hier angewendet, bei meiner Seite wurden allerdings verschiedene Linuxwerkzeuge mitsamt Ordnern in dem Überordner des Webverzeichnis installiert (unter anderem etc/, home/ und bin/ mit einigen ausführbaren Dateien.)

Danke Carsten, ich hab wohl Glück gehabt, werde mich aber trotzdem in deine Infos / Module gründlich einarbeiten und einlesen.

Irgendwann kommt (wie bei jedem System...) sicher die nächste Lücke, dann schadet es nicht etwas Ahnung zu haben, PHP Filter bleiben jetzt deaktiviert und ich gewöhne mir nun auch an ältere Backups auf einer gesonderten Installation zu sichern. Bei diesem Crash hätte es ja fatal enden können wenn nur ein aktuelles Backup vorliegt welches vielleicht auch schon betroffen ist.

Grüße Jenna

Gibt es hier noch jemand wo gar nichts passiert ist?
Hatte ca. 20 Projekte am 16. Oktober (Nachmittag) aktualisiert. Ein paar weitere erst in den letzten Tagen. Da konnte ich aber auch nichts feststellen.
Es gab keine neuen User, Rollen, keine neuen Dateien. Diff und Hacked Module hatten auch keine Veränderungen feststellen können.
Waren die Angriffe eher zufällig? Gab es ein bestimmtes Schema?

also ich habe bei meinen kunden und von anderen kunden erst nach dem 15.10. aktualisiert und alle nutzer überprüft. bei einem war auch ein dev nutzer
habe ich sicherheitshalber alles gelöscht: db, ftp und neu aufspielen können.
von meinem provider habe ich auch keine nachrichten, bei einigen kunden hat sich 1und1 gemeldet deswegen

Also ich habe bei einem Projekt festgestellt, dass es den drupaldev User und die Rolle megauser gibt. Hier gab es auch Versuche, mit file_put_contents Dateien zu hinterlegen, das scheint aber nicht funktioniert zu haben (haben mir die Drupal-Loggings verraten - ist hier beschrieben: https://www.acquia.com/blog/learning-hackers-week-after-drupal-sql-injec...). Wie wir damit weiter machen, weiß ich auch noch nicht - das Projekt ist eh recht tot und und könnte vielleicht sogar einfach eingestampft werden.

Mich würde auch mal interessieren, wie viele Seiten letztendlich wirklich betroffen waren oder sind (soweit man das halt feststellen kann). Ich fand die Meldung schon irgendwie überzogen, dass nun alle Drupal-Seiten, die nicht innerhalb von 7 Stunden aktualisiert wurden, als gehackt anzusehen sind. Ich verstehe ja, dass es schwierig sein kann, gehackte Seiten tatsächlich zu erkennen und dass diese Sicherheitslücke echt eine krasse Nummer war - dass die Hacker nach wenigen Stunden schon automatisierte Angriffe auf drupal-Seiten starten ist schon fast gespenstisch... aber wenn das automatisierte Angriffe waren, werden die doch wohl im Groben stets das gleiche Muster haben, oder? Kann man dann nicht wenigestens anhand dieser Muster herauslesen, welche Seite von diesen Angriffen übernommen wurde?

@ Goekmen: JA. Gleicher Fall bei mir. Keine der Kundenseiten war betroffen. Updates wurden 12 Stunden nach Bekanntgabe eingespielt. 2x Seiten konnten leider erst 48 Stunden später auf Drupal 7.32 aktualisiert werden. Auch hier keine Hack erkennbar.

Ich bin intensiv die Verzeichnisse durchgegangen und habe nach den Mustern gesucht wie auf Acquia.com beschrieben. Keine Auffälligkeiten, Dateiänderungen, geänderte Zeitstempel, keine neuen User/Rollen, keine neuen Blöcke mit Code oder dergleichen etc. erkennbar. Die Aussage wer nicht 7 Stunden nach der Veröffentlichung der Ankündigung aktualisiert/gepacht hat, wurde gehackt, tritt bei mir (zum Glück/anscheinend) nicht zu. Auf allen Seiten wird kein Meta Generator Eintrag mit Drupal 7 Zusatz verwendet. Vielleicht waren die Seiten dadurch bei der 1. Angriffswelle schwerer "crawlbar". Aber wahrscheinlich reine Einbildung......

Zu weiteren Analyse empfehle ich die Drush Erweiterung Drupalgeddon und Site Audit

drush dl site_audit
drush dl drupalgeddon
drush cache-clear crush

drush asec
drush -y @sites drupalgeddon-test

Welche weiteren Maßnahmen habt ihr ergriffen?

Interessant, bei mir waren auch keine Kunden-Webseiten betroffen, sondern nur drei eigene Projekte, die alle auf dem gleichen Managed Server liegen.
Bei welchem Hoster sind Deine betroffenen Installationen, Howdytom?

Folgendes habe ich gemacht:
- Update eingespielt
- User und Rolle entfernt
- Module hacked und diff ausprobiert
- Mit Linuxbefehl via SSH auf der Konsole nach Dateien gesucht, die jünger sind als xy Tage und diese einzeln angesehen
- Datenbank-Dumps von vor und nach dem kritischen Termin mit Winmerge auf Änderungen untersucht.

Ich konnte weder auf Datenbank-ebene noch in den Dateien Änderungen entdecken, die da nicht hin gehören.

@montviso: Keine Drupal Installation ist betroffen. Hosting erfolgt in Colocation, Myloc, 1&1, Hetzner.
Außer dem üblichen massenhaften „Ausprobieren“ und Crawlen ist auch in den Apache access und error Logs nichts erkennbar, was auf den Hack hindeutet.

Kann mich dem nur anschließend. Die Professionalität und Vielfältigkeit der unterschiedlichen Muster, die hier an den Tag gelegt wurde ist schon sehr erschreckend.

Ich habe auf einem Server ca. 15 Projekte laufen.

Es war nur eines betroffen.

In diesem Projekt war nur die genannte Rolle mit dem entsprechenden User angelegt.
Die Rolle hatte Rechte, wie ich sie niemals vergeben würde.

Ansonsten keine Veränderungen.

Die Rolle habe ich entfernt, den User gesperrt.

Wenn das ein Automat ist, kann es genügen, den User in die Sperrliste zu nehmen, dann ist er nicht anlegbar.

Hallo,
auf der seite acquia.com wird von über 38000 Aufrufen innerhalb kurzer zeit aus Russland geschrieben.

Da ich auf meinen Seiten den neuen user und rolle nicht habe (die seiten ohnehin ohne ecommerce und mit maximal 3 admins/redakteuren laufen ohne kommentare oder foren, inhalte kein besonderen betriebsgeheimnisse sind, reichweite vglweise gering), ich aber seit langem countryban und honeypot nutze, wo russland, china, rumänien und co. soweit möglich "ausgesperrt" sind, würde ich gern wissen, ob alle angriffe bei euch aus einem land kamen?

Über die info würde ich mich sehr freuen.
Schöne grüße
Knobelvogel

Obwohl ich erst 48 bzw. 72 Stunden nachdem die Sicherheitslücke bekannt wurde, das System gefixt habe, sind bei mir keine Einbrüche feststellbar.

Auf meinem System ist allerdings im html-Code/Metas etc. kein Hinweis zu finden, dass es mit Drupal gemacht wurde (die Hacker müssen die betroffenen Drupalinstallationen ja irgendwie ausfindig gemacht haben).

Habe ebenfalls im Zeiraum 24-36 h gefixt durch update auf 7er 32 und bei keiner Installation bisher Auffälliges gefunden...

Trotzdem nochmal die Frage:

Gab es Angriffe abgesehen von RU ? Konnte bisher davon nichts lesen, habe allerdings auch gepostete IPs im Netz jetzt nicht getraced.

Ich habe überall den Drupal Metagtag drin. Bei 90% der Projekte ist aber die Registrierung ausgeschaltet.
Ansonsten lösche ich normalerweise auch alle Dateien im Root Ordner die auf Drupal hinweisen (license, mainteiners, install etc)

Guter Tip ... prüft Hacked eigentlich auch, ob zusätzliche Dateien vorliegen oder "nur" ob Drupal-Core bzw. Modul-Datein geändert wurden?

Herzlich
Andreas

Benennt Ihr auch Euer sites-Verzeichnis um?
Andernfalls kann man ja Drupal-Installationen auch ganz gut mit der Suche nach "sites/default/files" finden.

Das Hacked Modul prüft nur vorhandene Dateien bzw gelöschte Dateien - neu hinzugefügte prüft es nicht. Am besten auch gleich mit dem Diff-Modul installieren, dann sieht man auch gleich, was eigentlich anders ist.

Ich habe auch schon mal überlegt, ob ich das öffentliche Verzeichnis anders benenne... ist vielleicht gar nicht so schlecht, um nicht aller Welt zu zeigen, dass Drupal das verwendete CMS ist?!

Mal eine Frage: wenn man die Dateiberechtigungen einstellt wie hier (http://www.studiosdigital.at/blog/drupal-going-live-checklist) bechrieben - würde das verhindern, dass solche Dateien eingebaut werden können?

Ich habe mal geschaut - leider verrät sich das Theme, wenn z.B. Favicon und Logo vom Theme genommen werden, aber da könnte man vielleicht noch nacharbeiten. Und ich kann mir vorstellen, dass die Bildstile mit den pfaden "styles/public" auch alles verraten...

Das entscheidende, ist ob Drupal (als der Linux-Benutzer, der Webserver/Drupal ausführt) das Recht hat, Daten zu schreiben oder zu ändern. Bei vielen Webhostern kann das nicht sicher eingestellt werden. Ich kenne nur eigentlich nur Hosteurope. Bei selbst verwalteten Servern gibt es wie üblich mehr Möglichkeiten, obwohl ich Kunden Projekten oft trotzdem eine problematische Konfiguration vorfinde (z.B. Owner:Apache und Gruppe:Apache).

Ich habe mich am Wochenende ein wenig mehr eingelesen in die Hack-Möglichkeiten und nun auch die Suche nach "access_callback" in der "menu_router" Tabelle verstanden. Die Funktion "file_put_contents" nach der gesucht werden soll, ermöglicht es den Code, den die Hacker in das Feld "access_arguments" mit der SQL-Injection einbringen in die zusätzlichen Dateien zu schreiben. Dies geht aber auch ohne jegliche Form von zusätzlichem Benutzer in Drupal und ohne PHP-Modul, aber soweit ich weiß nicht ohne Schreibrecht im System (siehe oben). Wer also nur fröhlich nach Drupal-Benutzern sucht und meint er/sie wäre sicher, weil nicht vorhanden, befindet sich in einer trügerischen Sicherheit (siehe mein Kommentar oben).

Das mit dem Verbergen von Drupal als CMS ist gar nicht so einfach. Allein die Suche nach "/sites/default" würde doch auch schon ausreichen. Aber im Grunde zählt das alles zu dem Konzept "Security by Obscurity". Das bringt sehr viel weniger als die Beseitigung realer Gefahren. Also sorgt lieber für ein sicheres Datei-System.

Ähnlich wie bei Goekmen. Ich konnte auch noch nichts feststellen. Core Update von 7.19 auf 7.32 wurde eine Woche später aktualisiert.
Bei mir ist die user/register seite nicht aktiv. Weiss nicht ob das damit zusammenhängt.
Zurzeit sind im "recent log messages" regelmäßig Aufrufe der Seite user/register und node/add aus unterschiedlichen Ländern zu sehen.
Das kommt mir etwas komisch vor, da es eigentlich keinerlei Verlinkungen zu diesen Bereichen gibt.

Das sind die normalen Link-Spamm-Bots die überprüfen ob Nodes auch von Gästen erstellt werden dürfen oder die dann versuchen einen Account anzulegen. Das hat mit der jetzigen Sicherheitslücke nichts zu tun.

OK. Danke für den Hinweis.

Ich habe auch so eine Installation und ständig diese Aufrufe, oft auch /wordpress.php und ähnliches. Aus Spaß habe ich vor 3 Monaten angefangen alle IPs zu sperren die das versuchen.
Meine Protokollliste ist von 9 Seiten auf 1 Seite geschrumpft... und die krieg ich auch noch weg... Diese IPs sammle ich und werde die dann auf jeder Install sperren, mal gucken was das bringt.

Das Hacked Modul ist ja phantastisch, zeigt mir 4 Änderungen in Core Dateien (die sind auch korrekt 2 x Patch für system requierment, 1 x php.ini Eintrag in der .htaccess, 1 x robots.text Umleitung oder flag Eintrag für anonyme User - Merkliste ), das ist nicht nur genial zwecks aktuellem Anlass zu checken, sondern weil ich oft nicht mehr weiß in welcher Datei eigene Einträge waren, super geeignet um das schnell nachzuvollziehen. Ein grosser Dank an den Entwickler.

Würde das Diff Modul zusätzlich angelegte Dateien anzeigen (ausser im Root), also innerhalb Drupal, was "Hacked" ja nicht macht?

Was ich mir wünschen würde ist hier im Handbuch eine verständliche Anleitung nach der Installation oder für bestehende Sites (Sicherheitseinstellungen) oder gibt es das und ich habs nicht gefunden?
Zum Beispiel eine Liste mit empfohlenen Dateirechten für "dateinamen.php", wie den sites Ordner besser absichern und eben alles was man selbst dazu tun kann, es aber nicht weiß.
Momentan versuche ich mir die ganzen Tipps zusammen zu suchen, aber es ist ziemlich schwierig, für Neustarter mit Drupal noch schwieriger.
Ich würde das ja selbst schreiben... wenn ich könnte.. wäre aber sofort mit einer Paypal Spende dabei...
Kann man jemanden überreden so etwas übersichtlicher zusammen zu stellen, und aktuell zu halten (ergänzen) oder bin nur ich das die langsam nicht mehr durchsteigt?

Grüße Jenna

Ein Großteil kommt aus China, einige aus Honkong, auch Russland ist recht weit verbreitet.
Aber is sind auch USA, Venezuela, Polen und andere dabei.

Das mit der IP-Sammlung ist eine gute Idee.

Vielleicht sollten wir eine Datenbank mit solchen IP-Adressen aufbauen? Möglichst mit Herkunftsland.
Und für die Anfänger eine vorbereitete Sperrdatei mit einigen Einträgen.

Bei diesen Angriffen wird oft versucht auf WP und JOOMLA zuzugreifen.
Diese Leute geben sich also nicht die Mühe, sich vorher über das System zu informieren, sondern ballern einfach darauf los, bis sie eine Lücke gefunden haben.

Ich habe, nachdem diese Spamregistrierungsversuche überhand nahmen, die IP-Ranges von China und Indien komplett ausgesperrt und die restlichen IPs aus anderen Ländern per Hand in die htaccess eingetragen.

Ein paar Tage war dann Ruhe aber nach kurzer Zeit ging es wieder los. Die Spammer nutzen immer neue IP-Adressen - das ist ein Kampf gegen Windmühlen den man nicht gewinnen kann.

Ich habe es dann irgendwann aufgegeben .... Honeypot reicht aus ... da werden die Spamregistrierungen zu hundert Prozent geblockt. Das Logfile läuft zwar über (pro Minute wird das ein bis zwei mal versucht) aber es kommt zu keiner einzigen erfolgreichen Registrierung.

Um eine aktuelle IP-Liste anzufertigen (und up-to-date zu halten) da müsste man eine Person festanstellen die das den ganzen Tag über macht (was natürlich unsinnig ist).

Dummerweise gibts ja auch Spamregistrierungsversuche, die Honeypot nicht abfängt, weil echte Menschen dahinter sitzen.
Die kommen dann immer haufenweise von der gleichen Email-Adressen-Endung, z.B. netcourrier.com oder itregi.com.
Da hilft nur ein Eintrag im Modul user-restrictions.

Ja - das nutze ich auch und genau wie bei dir habe ich über user-restriction netcourrier.com und itregi.com komplett gesperrt. Das sind die einzigen und weitere Probleme gabs bisher nicht.

auf einem ftp server wo ich dachte da wäre nichts! hier einmal ein screenshot der dateien, die dort nicht hingehörten!
die hatten komischerweise keine rechte zum download per ftp und sind deshalb aufgefallen.

Habe jetzt auch eine Seite, die offensichtlich doch betroffen war. Bei mir wurde mit großer Vorliebe unter CKEditor/Plugins allerhand php Dateien angelegt, darunter sogar ein eigenes Plugin-Verzeichnis und unter den modules im Rootverzeichnis bei image, toolbars, Statistics ... bin noch am Suchen, lässt sich anhand des Datums aber gut erkennen. Außerdem sind in den Serverlogs die Posts gelistet. Wird also Spam versendet.

EDIT:

Ist das krass! Ich hatte die Drupal-Version 32 Installationsdateien noch entpackt auf dem Server in einem Unterverzeichnis. Selbst da wurden Dateien eingefügt.

Wir das mit dem Drupalgeddon Modul geprüft oder wie hast Du diese dateien gefunden?

Eigentlich war ich bereits davon ausgegangen, dass das Thema erledigt war, bis ich Nachricht bekam, dass von der Seite Spam versendet wurde. Daraufhin habe ich nach auffälligen Dateien gesucht und natürlich in die Logs geschaut. Bei mir war es so, dass für jede SPAM-Mail in den Logs ein POST dokumentiert war von einer russischen IP (offensichtlich hatte ich die htaccess bei einem Update überschrieben) über den Aufruf EINER immer gleichen .php-Datei gelistet war (ansonsten normalerweise nur GET natürlich). Als nützlich hat sich im Nachhinein bisher erwiesen, nicht sofort die aufgerufene PHP-Datei zu löschen, sondern erstmal die anderen PHP-Dateien zu suchen, die abgelegt wurden, um diese PHP notfalls zu ersetzen und die anderen erstmal zu erfassen/zu löschen (wobei besser erst nach Sperrung der IPs löschen). Dazu war es hilfreich, mit nicht befallen Installationen die Verzeichnisse und Datumsangaben/Änderungsdaten aller Dateien zu vergleichen (selbst nach Update, da auch dann diese auffallen). Dann die IP bzw. am besten gleich den IP-Bereich des Providers sperren in htaccess und entsprechende PHP-Dateien löschen (oder bei Unsicherheit umzubenennen). Nicht sogleich, aber ziemlich zügig innerhalb der nächsten Stunden, nach etlichen vergeblichen Aufrufversuchen der einen Datei, versuchte der Bot dann endlich seine "Sicherheitskopien" erfolglos zu aktivieren, wodurch ich vier oder fünf weitere, von denen ich eine zuvor übersehen hatte (und ein paar andere zuvor schon löschte), eindeutig bestätigen und löschen konnte. Die erste Datei aus den Logs wurde dann nocht etwa 10 weitere Stunden lang versucht aufzurufen.

Die weiterhin bestehende Gefahr ist allerdings vorhanden. Von Datenbankmanipulationen abgesehen darf man nicht die Problematik mit der Settings.php nicht vergessen. Einen neuer User und PW der Datenbank wäre wohl angebracht, wenn man sicher ist, dass keine weitere Lücke da ist.

Wichtige Ergänzung!!! :

Natürlich hat der Bot nicht alle Kopien aufgerufen bzw. versucht zu aktivieren. Z.B. die im vorher erwähnten Installations-Quellverzeichnis der Drupal Version 7.32 in einem Unterverzeichnis, wo er ebenfalls PHPs hineinkopierte, hat er nicht versucht aufzurufen (EDIT: s.u.). Es sollte jedem wie auch mir klar sein, dass immer noch Dateien vorhanden sein können, die nur nicht aufgerufen wurden.

Edit: Hatte heute noch nicht so genau nachgeschaut, aber von der nachwievor selben IP wurden heute doch wieder allemöglichen Dateien versucht aufzurufen innerhalb weniger Minuten (ca. 50 Versuche). Auch in dem Quellverzeichnis von Drupal V 7.32, nur eben nicht die erste Datei

Welche Plug-Ins/Funktionen/Möglichkeiten gibt es eigentlich, die die Server-Logs überwachen können (evtl. auch serverseitig/Apache/MySQL) und Triggern mit Benachrichtigung? (Z.B. Posts melden oder bestimmte IPs)