gehackt?

[Holger]

Wie das Script auf den Server kam, weiß ich nicht, und auch nicht wie es dort wieder hin kam – es könnte aber durchaus sein, das weitere solcher Backdoors auf der Domain (vielleicht auch irgendwo sonst auf dem Server) existieren, und der Angreifer das Script nach Belieben wieder herstellen kann.

Da kann man viel rätseln.

@albert: Logs durchsucht? Hoster gefragt?

[albert]

@albert: Logs durchsucht? Hoster gefragt?

gefragt ja, aber logs war bisher nicht aktiviert.
Über Nacht ist die html wieder rein gekommen, hab sie wieder gelöscht. Offenbar sind keine weiteren Emails verschickt worden. Nachdem alle Zugangsdaten geändert sind werd ich auf CMSimple vers. 1.7 in ein leeres neues Verzeichnis upgraden und damit müsste die Sache wohl erledigt sein - hoffentlich.

[olape]

und damit müsste die Sache wohl erledigt sein - hoffentlich.

Nur, wenn es wirklich an deiner Seite lag, keines der Plugins ein Leck hat und du wirklich keine Dateien aus der alten Installation übernimmst. Mal abgesehen vom Content, das muss ja wohl sein.

[Tata]

Nur für Information und die Dateien, die zuerst versucht sein sollen https://cmsimpleforum.com/viewtopic.php ... ilit=Virus

[cmb]

gefragt ja, aber logs war bisher nicht aktiviert.

Schau auf jeden Fall in CMSimple_XH Log, ob da ein verdächtiges Login aufgeführt wird.

Und vielleicht auch mal unter https://haveibeenpwned.com/ nachschauen.

[cmss]

Vom XH-CMS kann der Hacker doch nur Spam über eingeschleusten Code senden.

Ich empfehle mal gysecurity (github) zu installieren oder ein Spamfilter.

Man kann auch eine freie Email bei mail.aol.com eintragen, die ein integriertes Spamfilter haben.

Andererseits könnte der Provider mod_security auf seinem Apache installieren.

Es gibt auch freie Spamfilter mit mehr oder weniger Wirkung (evtl. anzupassen).
dazu https://www.georgeoffley.com/new_dev/20 ... er-in-php/
und https://github.com/IQAndreas/php-spam-filter

[olape]

Vom XH-CMS kann der Hacker doch nur Spam über eingeschleusten Code senden.

Wie kommst du zu der Erkenntnis? Wenn jemand Code einschleusen kann, dann kann er auch andere Dinge tun, als nur E-Mails versenden.

Man kann auch eine freie Email bei mail.aol.com eintragen, die ein integriertes Spamfilter haben.

Das würde vielleicht den unfreiwilligen Empfängern der E-Mails helfen. Nicht aber dem Betreiber einer gehackten Webseite.

Andererseits könnte der Provider mod_security auf seinem Apache installieren.

Da hat man als Kunde eben nur schwerlich Einfluss.

Grundsätzlich geht es aber auch nicht nur darum, das es gelungen ist, sondern mindestens gleichwertig darum, wie es gelungen ist.

[cmss]

Ich betreibe selbst eine bei einigen Kreisen unbeliebte Seite bei Strato, auf der mir gxsecurity wöchentlich über 50 IPs sperrt und bin nie gehackt worden.
Eine andere Seite mit gleichem Inhalt und XH1.69 wurde bei speicherzentrum gehackt und mir die htaccess gelöscht und stattdessen zum Hohn ein gzip-Eintrag gemacht und auch die Seite ging nicht mehr - ich würde daher den Provider wechseln.

Eine Seite hacken geschieht über den Provider oder über Anhängsel an die URL. Daher kann man auch bei den ÄÖÜ-Einträgen Sonderzeichen umbenennen. Ich habe bei Strato im htaccess einen Error 404 Eintrag, der im Fehlerfall auf eine ebenfalls angelegte Error 404 Seite umlenkt.
Eine Alternative ist eine PHP-Firewall : https://code.google.com/archive/p/php-f ... /downloads

[olape]

Ich habe bei Strato im htaccess einen Error 404 Eintrag, der im Fehlerfall auf eine ebenfalls angelegte Error 404 Seite umlenkt.

Was hat das damit zu tun?
Einen Fehler 404 kann der Server auch ohne deinen Eintrag richtig beantworten.
Der Eintrag in der htaccess dient nur dazu, eine selbst gestaltete Fehlerseite anbieten zu können.
Nicht mehr und nicht weniger.


Zum Sinn des Sperrens einzelner IPs hatte ich schon weiter oben/vorn etwas geschrieben.

[Holger]

@albert: Logs durchsucht? Hoster gefragt?

gefragt ja, aber logs war bisher nicht aktiviert.
Über Nacht ist die html wieder rein gekommen, hab sie wieder gelöscht. Offenbar sind keine weiteren Emails verschickt worden. Nachdem alle Zugangsdaten geändert sind werd ich auf CMSimple vers. 1.7 in ein leeres neues Verzeichnis upgraden und damit müsste die Sache wohl erledigt sein - hoffentlich.

Als ganz schnellen Test könntest Du auch einfach von der Installation ein Backup ziehen und dann ALLES löschen. Danach eine index.html, mit dem Hinweis das die Seite bald wieder online ist, als einzige Datei auf den Server legen.
Wenn dann über Nacht wieder etwas eingeschleust wird kannst Du sicher sein, dass es nicht an den Komponenten Deiner Installation liegt / lag. Was nicht bedeuten soll, dass jemand irgendwie nicht doch an die die Zugangsdaten des Accounts gekommen ist. Ehrlich gesagt glaube ich das aber eher nicht. Angriffe mit den Auswirkungen wie bei Dir laufen eher automatisiert ab. Die Seite von Albert Wilhelm wird nicht das bevorzugte Ziel von Hackern sein. Auch die Verbreitung von CMSimple_XH spricht gegen ein lohnendes Ziel für Hacker.

Aufräumen musst Du jetzt eh. Und es wäre schon wichtig zu wissen, auf welchem Weg der Code auf den Server kam.
Aber das der Hoster keine Access-Logs hat, kann ich nicht glauben. Einsicht / Aufbereitung der Logs für Deinen Account / Deine Zwecke, ist da wohl gemeint gewesen. Das kann man i.d.R. im ControlPanel selber einstellen.

Was genau hat der Hoster denn geantwortet? Wer ist es denn?
Ich kann nicht wirklich glauben, dass solch ein Ticket ernsthaft nur mit der Antwort "sorry, Logs waren deaktiviert" beantwortet wird. Der Provider selbst sollte ein Interesse daran haben, dass seine Infrastruktur nicht missbräuchlich verwendet wird. Aber ich kann mir schon einen Provider vorstellen, bei dem so eine Antwort möglich wäre...

Vom XH-CMS kann der Hacker doch nur Spam über eingeschleusten Code senden.

XH wird auf einem Server mit PHP-Unterstützung installiert. Gelingt es (PHP-) Code - wie in Alberst Beispiel - einzuschleusen, kann der Angreifer alles "machen" was mit der installierten PHP-Version / Konfiguration möglich ist.

Eine Seite hacken geschieht über den Provider oder über Anhängsel an die URL.

Mehr als die URL hat der Angreifer erst einmal nicht, stimmt.
Das ganze Provider gehackt werden, geschieht zum Glück eher selten.