[gelöst] Hilfe! SPAM-Mail-Versand per Skript

Den Provider fragen welches Script die Mails versandt hat. Das lässt sich normalerweise recht schnell nachvollziehen

Da war der Haken: Der Provider hat sich damit nicht auseinandergesetzt. Inzwischen konnte ich es lösen: Es lag nicht an Drupal, sondern an MySQL Dumper - dort war eine Lücke im Verzeichnisschutz.

Grüße

Hallo,

ich muss diesen Thread reanimieren. Der Grund ist, dass es scheinbar noch immer Sicherheitslücken in Drupal gibt, die das hochladen (POST*) von php-Skripten in das Dateisystem ermöglichen - sowohl im sites/ [default]/files als auch in sites/all/* - Verzeichnis.

Der .htaccess-Schutz von Drupal 7.34 reicht anscheinend nicht aus.

Ich habe nun einige IP-Bereiche und Länder per folgenden Eingriff in die .htaccess gesperrt:

Weiß jemand, ob das .htaccess-Modul hilfreich ist oder es irgendeine andere Möglichkeit gibt, POST-Zugriffe generell nur auf das System zu beschränken? Im privaten Verzeichnis wird der Schutz per

erreicht. Würde man dies in der Root-htaccess von Drupal eintragen, sperrrt man sich selbst aus...

Hab dies jetzt erstmal mit

in der root-htaccess probiert, ohne zu wissen, ob es was bringt.

Eventuell war das System doch schon vor dem Update gehacked und das Update hat den Hack nicht beseitigt? Erstens können durch den Hack auch Änderungen in der Datenbank erfolgt sein, die durch das Update NICHT beseitigt werden. Zweitens ist die Frage, wie genau das Update eingespielt wurde. Sollten nämlich nur die neuen Dateien hochgeladen worden sein, die die alten überschrieben haben, dann sind auch im Rahmen des Hacks angelegte PHP-Dateien noch vorhanden.

Mir hat jetzt die Tage übrigens meine eigene Schusseligkeit in die Hände gespielt: Ein vergessenes "Mach ich irgendwann mal"-Projekt mit zwei Alibi-Einträgen dümpelte noch irgendwo einsam und verlassen auf einem 1&1-Webspace rum. Alle anderen Projekte hatten zeitnah ihre Updates bekommen, nur dieses eine nicht. Am Sonntag kam dann eine Abuse-Mail von 1&1 (deren Virenscanner hatte eine verdächtige Datei entdeckt). Es war ein typisches Drupageddon-Angriffsszenario in einem schon etwas weiter entwickelten Stadium - 6 Wochen nach dem eigentlichen Hack. Das Projekt habe ich natürlich direkt vom Netz abgeklemmt, ansonsten aber so belassen, und ich bin dankbar, ein eigenes Modell zur umfassenden Analyse zu besitzen. Die Rückschlüsse können evtl. nämlich auch bei Kundenprojekten mal hilfreich sein. Ein wichtiger Punkt ist zum Beispiel, dass einige, aber nicht alle Spuren wieder beseitigt wurden (bzw. dass man das in Drupals Protokollnachrichten nachvollziehen konnte, was angelegt und wieder gelöscht wurde). Da werde ich sicherlich noch einen Blogbeitrag draus machen.

Ich halte es definitiv für möglich, dass das Update ein bereits gehacktes System bei Dir nicht absichern konnte. Insofern bleibt Dir nur eine umfassende Kontrolle auf weitere PHP-Dateien und letztlich Deiner Datenbank (hier hatte ich aber noch keine Zeit für eine Analyse, aber es gibt ja durchaus einige Beiträge im Netz, die ein paar Möglichkeiten der Kompromittierung aufzeigen).

Ach so, und der Angriff am Sonntag kam aus Schweden. ^^

Ich habe bei der betreffenden Seite eine komplett neue Installation angelegt und die Inhalte manuell eingespielt. Das war notwendig, da durch den ersten Angriff auch einige Funktionen nicht mehr ordnungsgemäß liefen und die Fehlersuche in diesem Fall länger gedauert hätte, als der neue Upload (wir reden von 50 Nodes einer Fotowebseite). Abschluss war am 23.11.2014
In dieser neuen Installation wurden in das Verzeichnis sites/[sitename]/files/pictures, sites/all/modules und sites/all/libraries php-Schadcodes hochgeladen und gestern (03.12.2014) per POST ausgeführt.

Welches System meinst du? In meinem Fall ergaben die Protokollnachrichten nichts, da der Upload der Skripte nicht über die Installation erfolgte.

Das wäre super!

Da stimme ich dir zu. Es wäre ein Traum, wenn Drupal z.B. während des Cron alle nicht zugehörigen Dateien löschen würde.

In meinem Fall mal wieder aus Russland. Ich werde beobachten, wie sich das ganze entwickelt und ggf. nur noch deutschsprachige Länger erlauben (da die Seite auf deutsch ist). Ich bin leider noch nicht fündig geworden, wie man generelle POST-Aufrufe, die nicht über Drupal erfolgen, blockieren kann.

Merkwürdigerweise habe ich ca. 10 Installationen auf dem Webserver und trotzdem ist stets die gleiche Ziel der Angriffe. Für mich auch insofern eine Überlegung, auf Multisites zu verzichten, damit nicht gleich mehrere Installationen bei einen Eingriff in modules oder libraries Schaden nehmen.

Grüße