Wordpress lädt kein Theme/Layout (nackte Oberfläche)

  • Nach der Netcup-eigenen Installation von Wordpress erscheint bei mir das Frontend ohne Layout, also "nackt"/ohne Theme.

    Im Dashboard kann ich kein weiteres Theme installieren. Einen Button dafür gibt es zwar. Wenn ich den drücke, passiert

    aber nichts. Auch unter Designs und Customize kann ich ein Theme im Backend nicht bearbeiten.


    Nur im Wordpress-Netcup-Toolkit kann ich ein Theme installieren. Aber das ergibt auch keine Änderung.


    Die Seite: Cineschool.de
    SSL ist aktiviert.


    Woran kann das liegen?

  • Für Details beim Client-seitigen Zugriff empfiehlt es sich, bei Google Chrome oder Mozilla Firefox mit F12 die "Entwicklertools" einzublenden, danach die eigene Homepage zu laden und bei­spiels­wei­se auf der "Browser-Konsole" nach Fehlermeldungen Ausschau zu halten (daher stammt der Bildschirmausschnitt unten).


    Der Grund/einer der Gründe kann bisweilen eine lokale CSP (Content-Security-Policy) sein, welche das Laden untersagt (in Abhängigkeit von aktivierten Add-ons):

    pasted-from-clipboard.png

    ^^^ die obigen Fehlermeldungen haben aber in diesem Fall lokale Ursachen bei meinem Testaufruf (nur ein Beispiel!)


    Serverseitiges Problem ist derzeit, dass .js/.css-Dateien nicht gefunden werden (Error 404). Im Log des Webservers sollten sich diese Fehler ebenfalls finden. Gegebenenfalls werden interne Rewrite-Direktiven nicht ausgeführt? Je nach verwendetem Webbrowser lässt sich temporär etwa die Detailtiefe des Logs erhöhen, sodass man einen Hinweis auf die Ursache bei Verwendung von internen Umleitungen bekommt.


    Wenn sich im Dashboard keine weiteren Themes installieren lassen, könnte das auf Probleme mit den Zugriffsrechten hindeuten.

    VServer IOPS Comparison Sheet: https://docs.google.com/spreadsheets/d/1w38zM0Bwbd4VdDCQoi1buo2I-zpwg8e0wVzFGSPh3iE/edit?usp=sharing

  • Ja, es gibt 19 Fehlermeldungen (Error 404). Die Dateien sind auf dem Server, deshalb

    gehe ich davon aus, dass es Probleme mit Zugriffsrechten gibt. Per Rechtsklick auf eine css-Datei kann

    ich die Zugriffsrechte ändern. Diese stehen momentan auf 644. Das ist ja eigentlich in Ordnung, oder?


    Interne Rewrite-Direktiven: Wo finde ich diese? Angelegt habe ich selbst keine.


    Merkwürdig finde ich, dass ich das Wordpress-Toolkit verwende und es trotzdem zu solchen Problemen kommen kann.

  • Die Lösung, die bei mir jetzt funktioniert hat:


    - alles noch mal identisch installiert

    - zwischen den Installationsschritten aber länger gewartet.

    - Das Theme war dann geladen.


    Eine andere Erklärung habe ich nicht.

  • Hallo, ich habe eine Fehlerursache gefunden; in /httpdocs läßt sich, auch bei WP-Neuinstallation, die Datei index.php nicht überschreiben, bei Überprüfen der WordPress-Integrität kommt Fehler:

    Aufgabe in Bearbeitung

    Warning: Unable to copy 'index.php' to current directory. Error: Couldn't extract WordPress archive. There was an error overwriting existing files. Downloading WordPress 5.8.1 (en_US)... md5 hash verified: 8847c2f02530f476b0eadff2030ceaa9


    Die aktuelle index.php (s.Anhang) hat in der zweiten Zeile eine Menge kryptischer Zeichen. Kann die Ursache ein Virus oder Malware sein?
    Viele Grüße
    Joachim

  • Die aktuelle index.php (s.Anhang) hat in der zweiten Zeile eine Menge kryptischer Zeichen. Kann die Ursache ein Virus oder Malware sein?

    Davon würde ich ausgehen. Nach Berichten aus dem Internet, welche man durch Suchen der ersten Zeichen dieser Zeile findet, werden seit einigen Tagen bisweilen mehrere PHP-Scripts damit manipuliert. Der Inhalt des (partiell) decodierten Scripts deutet nicht darauf hin, dass dies eine vom Nutzer gewünschte Erweiterung sein könnte, da es für die identische Manipulierung mehrerer PHP-Scripts in diesem Umfang und in derart kryptischer Form (da die Dekodierung Zeit kostet, würde kein WordPress-Modul-Autor derartige unsinnige "Klimmzüge" veranstalten!) schlechterdings keinen logischen Grund gibt außer sicherzustellen, dass dieser Code mit hoher Wahrscheinlichkeit ein- oder mehrmals ausgeführt wird.

    Zwecks Analyse würde ich eine Kopie aller Logs/Dateien anraten, gefolgt von umgehender Neuaufsetzung der Webpräsenz unter Verwendung aktueller Komponenten (WordPress, PHP, ...) und expliziter Kontrolle aller Zugriffsrechte.

    VServer IOPS Comparison Sheet: https://docs.google.com/spreadsheets/d/1w38zM0Bwbd4VdDCQoi1buo2I-zpwg8e0wVzFGSPh3iE/edit?usp=sharing

  • Habe mir mal den Spaß gemacht das zu dekodieren.


    Total abgedreht. Variablen Namen in Unicode Entities, Strings mit einer Kombination aus Base64 und GZIP kodiert, statt die Variablen direkt zu nutzen wird das $GLOBALS array benutzt, PHP Funktionsnamen werden aus einem String Zeichen für Zeichen via Substrings zusammen gesetzt. (Siehe dazu unweird.php/unweird.txt)


    Da steckt definitiv eine Remote Execution Shell drin:


    https://github.com/perryflynn/…4bf7f00958ba4510a4d2a91dc


    Gleichzeitig macht das Script irgendwas mit Google Sitemaps. Vielleicht eine Call-Home Funktion?


    Dann wird da noch eine .htaccess Datei angelegt.


    Der komplette Diff:


    https://github.com/perryflynn/…799108868d5810e4...master


    Das einigermaßen decodierte Malware Script:


    https://github.com/perryflynn/…o/blob/master/malware.php

  • Code
    <FilesMatch "^(about.php|radio.php|index.php|content.php|lock360.php|admin.php|wp-login.php|wp-l0gin.php|wp-theme.php|wp-scripts.php|wp-editor.php)$">
        Order allow,deny
        Allow from all
    </FilesMatch>

    Das ist ein Ausschnitt aus der .htaccess die von der Malware geschrieben wird.


    lock360.php und wp-l0gin.php sieht schon verdächtig aus.