Drupal gehacked // Fileupload // SQL User + Rechte

die meisten Provider haben phpMyAdmin istalliert.

Damit kannst du auf die Datenbank, den neuen User mit ID#1 anlegen und den Megauser beseitigen.

Das sind die Auswirkungen von Drupalgedon (Bug vor Drupal 7.32) und bedeutet Aufwand das zu fixen. Ich habe hier schon mal eine Lösung skizziert. Viel Erfolg.

Habe einen neuen User in der Datenbank angelegt. Das Anlegen des Passwortes hat nicht auf Anhieb geklappt, habe dann aber einfach eine E-Mail-Adresse angelegt und an diese ein neues Passwort angefordert. Fertig.

So einfach ist das aber nicht!! Bei dem Hack wurde eine Backdoor in der Datenbank eingetragen, über die man Deine Seite immer wieder übernehmen kann. Du mußt versuchen Deine Inhalte zu retten und alles von Grund neu aufbauen, also

• Ganze Webpräsenz platt machen, es dürfen keine Dateien übrig bleiben, in denen sich ein Script versteckt haben könnte!
• Drupal und alle Module neu von drupal.org holen
• Eine neue Datenbank anlegen
• Eine frische Installation durchlaufen
• Alle Konfigurationen neu erstellen
• Mit Feeds die gesicherten Inhalte wieder zurückspielen
• Beim Theme, wenn man es nicht neu holen kann, weil man zu viel geändert hat, alle Dateien überprüfen
• Alle Passworte, auch das für FTP, neu vergeben

Nur so kannst Du hoffen, die Backdoor loszuwerden.

Werner hat Recht, daß das Problem mit dem User-Austausch noch lange nicht behoben ist. Aber gleich ein neues Drupal zu installieren und die Inhalte zu migrieren muß nicht unbedingt sein. Der Code-Austausch steht in jeden Fall außer Zweifel. Aber die Datenbank kann man mit einiges an Know How und Handarbeit auch analysieren und bereinigen. Wenn man selbst nicht dazu in Lage ist und leichter neu machen kann, ist letzteres vllt. leichter zu finanzieren. Man sollte meiner Meinung aber auch bei der Suche nach Dienstleistern skeptisch sein, die hier evtl. ihre Hilfe anbieten.

Daß man insgesamt alles kontrollieren und evtl. Neumachen muss, kann und sollte im Zweifel auch weit über das Drupal-System hinaus gehen.

In einem betroffenen "Webspace" gibt es auch außerhalb des Drupal-System noch Stellen wo evtl. noch "Backdoors" etabliert wurden. Und wenn noch andere Webanwendungen vorhanden sind, wurden diese evtl. von geschickten Angreifern infiziert auch wenn diese evtl. mit anderen Technologien betrieben werden. Aus diesem Grund rate ich auch dringend vom Betrieb mehrerer Systeme in einem Webspace ab und dann auch dringend dazu, daß dieser möglich so betrieben werden sollte, daß eine Webanwendung sich nicht selbst verändern kann. Siehe auch Thread "Sichere Dateirechte: Wissen verbreiten und Provider überzeugen".

Wenn z.B. der Webserver noch problematischer konfiguriert und betrieben wurde, d.h. vor der Webanwendung nicht gut genug abgeschirmt war/ist, haben sich Angreifer evtl. noch tiefer im Server "eingenistet". Aus diesem Grund gehört zu den offiziellen Empfehlungen des Security-Teams von drupal.org im Zweifel den gesamten Server von Grund auf neu aufzusetzen. Sonst lohnt die ganze Arbeit in den höheren Schichten d.h. Drupal überhaupt nicht, da evtl. eine Backdoor außerhalb von Drupal etabliert werden konnte.

Bezüglich FTP:
Ich hatte vor längerer Zeit ein Kundensystem, das sehr wahrscheinlich nicht über eine Sicherheitslücke in Drupal als vielmehr über den FTP-Zugang meines Kunden und dessen gehackten Privatrechner angegriffen wurde. Die andere Möglichkeit wäre noch eine Sicherheitslücke beim Hoster gewesen, die ich aber mangels Zugangs-Möglichkeiten nicht analysieren könnte über einen normalen Kundenzugang (was auch Sinn macht). Somit betrachte ich jeden externen Rechner, der grundsätzlich Zugang zu einem System hat als potentielles Sicherheits-Leck.