unerwünschte Weiterleitung durch Veränderung der PHP-Datei

  • Guten Abend,


    ich habe bemerkt, dass eine meiner Wordpress Installation durch einen Angreifer verändert worden ist.

    Verändert worden sind alle index.php der index.html Dateien, es wurde immer der gleiche 1-Zeiler JS Code platziert.

    Einige Blogeinträge / Unterseiten, die in der DB gespeichert werden, waren ebenso infiziert und mussten bereinigt werden.

    Dies habe ich auch getan und habe vermutet, dass der Angreifer entweder das Passwort herausgefunden hat, die WP Installation zu alt war, PlugIns veraltet waren, PHP Version veraltet etc.


    Ich habe nach der Reinigung fast alle Passwörter verändert, PHP von 5.XX auf 7.4 aktualisiert, Wordpress + PlugIns auf den aktuellsten Stand aktualisiert.

    Dies hat genau drei Tage gehalten, dieses Mal war die WP-Installation erneut angegriffen worden, allerdings ohne die Blogeinträge / Unterseiten zu verändern,

    dafür wurden aber alle .js Dateien mit einem zusätzlichen Script versehen, der die Webseite auf eine Gewinnspiel-Webseite weiterleitet.

    Zusätzlich sind jetzt noch drei weitere Projekte (1x Wordpress, 1x HTML Webseite, 1x kleines Script) mit infiziert, dort sind ebenfalls alle index-Dateien + .js Dateien mit einem Code des Angreifers für die Weiterleitung versehen.


    Ich bin gerade dabei wieder die Codes zu entfernen, da diese Anhand des Änderungsdatums (alle fast zur gleichen Sekunde) schnell gefunden werden können.

    Habt ihr eine Idee, wie es zu dieser Infizierung kommen konnte? Ich habe jetzt alle FTP-Zugänge gelöscht (die PWs waren nicht verändert) und werde das Passwort von netcup CCP zurücksetzen.

    Nutzen tue ich das Webhosting 8000 Paket. Eine Anmerkung: bei den drei PHP-Webseiten kann ich mir vorstellen, dass vllt. eine Sicherheitslücke genutzt worden ist im PlugIn oder Script,

    aber wie konnte der Angreifer die HTML Webseite verändern? Dies sollte ja nur per FTP möglich sein, oder? Die Webseiten liegen in separaten Ordner und die Berechtigungen der Dateien stehen auf rwx-r--r--


    Ich bin gespannt ob jemand eine Idee hat :)


    Viele Grüße

    Crash

  • Wenn der Open-Basedir es erlaubt oder Funktionen wie exec() aktiviert sind, kann sich ein Angreifer unter Umständen beliebig zwischen den Websites austoben. Und somit auch bei anderen Projekten, die nur aus HTML-Dateien bestehen.


    Falls Du kein deutlich älteres Fullbackup (Dateien + DB) hast, würde ich Dir empfehlen, überall nochmals bei Null anzufangen. Also alles herunterladen und sichern, am Server komplett löschen, neu installieren und dann Stück für Stück die alten Inhalte zu importieren bzw. Plugins wieder zu aktivieren. Dabei sollte man natürlich aufpassen, dass bei den zu importierenden Daten nichts infiziert ist. Notfalls ältere Backups nehmen.


    Im Moment kannst Du wohl kaum ausschließen, dass Du irgendein Backdoor übersehen hast, über das der Angreifer immer wieder eindringt. Die Modification-Time einer Datei ist jedenfalls nicht aussagekräftig, die kann man fälschen.


    Neben geknackten Accountpasswörtern solltest Du auch in Betracht ziehen, dass Dein eigener PC/Laptop/Tablet/Handy infiziert sein könnte.


    Edit: Findest Du in den Serverlogdateien (Access-/Errorlog) irgendwelche Auffälligkeiten, die zu den bekannten Änderungszeiten passen? Dadurch könntes Du das Einfallstor eventuell eingrenzen.

    "Wer nur noch Enten sieht, hat die Kontrolle über seine Server verloren." (Netzentenfund)

  • Wie sehen die Pfade zu den Ordnern der PHP und HTML-Websites aus? Und wie die Systemsubdomain (hostingxxxxxx....)? Ist bei den PHP-Einstellungen eventuell open_basedir verändert worden, so dass auf die Webspace-Root zugegriffen werden kann per PHP? Was meinst du mit "fast alle Passwörter geändert"? Und warum nicht alle?

  • Meist handelt es sich um ein Problem bei einem Plugin, dass ist auch häufig unabhängig von der PHP Version.

    zB bestimmte Versionen von Revolution Slider, oder von Plugins welche die Timthumb Library verwenden, usw.

    Solche Probleme kann der Angreifer meist über eine Suche identifizieren, weil die Plugins eine meist erkennbare Auswirkung auf den Quellcode haben. Mit der Liste wird dann ein Bot gefüttert. Er braucht dann auch kein Passwort, weil er einfach eine Lücke verwendet um auf den Webspace zu schreiben.


    Es ist dann fast egal was du absicherst, oder ob du neu anfängst. Irgendwie wirst du auch an den Webseiten schrauben müssen, sonst passiert es immer wieder.
    Du könntest alte Webseiten auch lokal hosten und mit httrack einen html Mirror machen den du dann hochlädst. Hat aber auch einige Nachteile hinsichtlich Bearbeitbarkeit, wenn mehrere User dran sind.


    --


    Die Empfehlung wäre:
    0) Alle Webseiten/Domaininhalte leeren.
    1) Mit htaccess den Webspace nur für deine IP freigeben
    2) Die erste Webseite neu installieren mit einer Version des Projekts vor dem Problem, oder mit einer ganz neuen Wordpressinstallation und Neuinstallation aller Plugins. Dann musst du nur das Theme genau anschauen.

    3) Ansonsten die Plugins durchschauen und für diese Versionsnummern mal schauen, ob es exploits gibt. Um dem auf den Grund zu gehen: https://wpvulndb.com/

    4) Alle Plugins updaten, das ist für die Webseite meist kein Fehler und unbenötigte Plugins löschen

    5) Webspace hinsichtlich Berechtigungen und PHP Einstellungen absichern. PHP Version ist auch wichtig, aber das ist nicht das Hauptding für dein Problem (Es gibt nur einen Supportstop, aber noch keinen fatalen Bug).

    6) Passwörter der Wordpressinstallationen ändern, Passwörter von FTP und Admin soll man auch ändern, aber hier ist der Angreifer zu 99,9% nie dran gewesen.

    7) Webseite wieder freigeben, und die nächste Webseite wieder ab 1) durcharbeiten


    --

    Hinsichtlich Punkt 5 bin ich jetzt aber selbst ins Zweifeln gekommen, ob wir dies mit unserem Produkt überhaupt korrekt machen können. :(

    Was ich beim Produkt Webhosting 8000 als Problem sehe:

    -) exec scheint standardmässig aktiviert zu sein und die disabled_functions in der php.ini können nicht individuell bearbeitet werden (1)

    -) die open_basedir standardmässig und nicht umfangreich veränderbar (2) im Admin auf folgendes zeigt: /var/www/vhosts/hosting111110.a11111.netcup.net/:/tmp/:/var/lib/php5/sessions:/var/lib/php/sessions


    So sieht dies in meinem Admin aus:

    Einstellungen.PNG


    --


    Ich habe es getestet man kann mit einem PHP Script in der Installation auf einer Domain auf alle Dateien anderer Domains zugreifen, sowie auch exec ausführen.
    Dies geht zum Beispiel mittels require() bei beiden open_basedir Einstellungen.


    Ich habe auch 2 Funktionen recherchiert, die PHP Versions unabhängig sein sollten, um dies zu testen:


    Ein direkter Zugriff auf die php.ini ist aber nach meiner Recherche nicht erlaubt. Die Ordnerrechte zu reduzieren führt dazu, dass die Webseiten nicht mehr ausführbar wären.

    Bei bisherigen Hostern sind einzelne Accounts immer unter einem eigenen User gelaufen und bei eigenen Installationen habe ich dies selbst ändern können.


    Hoffentlich übersehe ich eine ganz banale Lösung, da ich ja selbst erst begonnen habe mit dem Webhosting 8000 zu arbeiten.

  • Cataloging 17842 WordPress Core Vulnerabilities, Plugin Vulnerabilities and Theme vulnerabilities

    https://wpscan.org/


    Kannst ja mal bei der alten Installation drüber laufen lassen (bzw. die aktuell gehackte). Dann wird dir sicherlich direkt angezeigt wo das Vuln ist. Wenn nicht, dann eventuell "nulled plugins" installiert ? Eher unwahrscheinlich 0-Day Exploits aber man weiß ja nie.


    Interessant bei dem Thema auch (Auch wenn nicht auf Wordpress passend:)

    https://media.ccc.de/v/36c3-10…ecution_from_using_sqlite