Beiträge von b3317133

    Plugins wie WP Statistics nutzen nicht das Access Log des Servers (ein Zugriff darauf wäre technisch oft auch gar nicht möglich) sondern eigene Mechanismen und die WordPress Datenbank. Je nach Besucherfrequenz können solche Plugins zu einer relativ hohen Auslastung des Servers durch WordPress führen. Beim zusätzlichen Einsatz von sog. Cache Plugins verfälscht sich ggf. diese Statistik, da das Statistik Plugin je nach Trackingmechanismus möglicherweise nicht aufgerufen wird.

    Oft wird ausserhalb von WordPress Piwik/Matomo z.B. auf einer eigenen Subdomain installiert und per JavaScript eingebunden. Ob/wie welche Art Zustimmung wg. DSGVO nötig ist, sagt Dir am besten ein entspr. Anwalt.

    Vermutlich betrachtest Du das allgemeine Access Log des Servers, wo jeder Zugriff erscheint. Du könntest in dem Fall mit geeigneter Software im heruntergeladenen Log Deine IP (oder den anonymisierten Rest davon) herausfiltern um sonstige Zugriffe zu sehen. Genereller Ansprechpartner für dieses Log wäre Dein Hostinganbieter.

    Wurde kürzlich die PHP Version geändert? Welche PHP Version wird jetzt verwendet?

    Welche Plugins werden verwendet? Irgendein relativ altes dabei? Falls Du da einen Verdacht hast, benenne den Ordnernamen des Plugins per FTP z.B. [FONT=Courier New]/wp-content/plugins/das-ganz-alte-plugin/[/FONT] temporär um, das deaktiviert das Plugin, dann sollte der Login wieder funktionieren.

    Wann genau erscheint diese Meldung? Bei richtigen Logindaten? Bei falschen erschien sie soeben nicht...

    Bei Fragen/Hilfe zu Darstellungsproblemen oder Ursachen von CSS-Fehlern usw. deaktiviere alle Minify-, Cache-, Optimier-Plugins, derzeit mind. aktiv: Merge + Minify + Refresh

    Derzeit kann man nicht wirklich zuordnen, woher bzw. aus welchen Dateien die Warnungen stammen, alles ist in [FONT=Courier New]/wp-content/mmr/...[/FONT] zusammengefasst.

    Evtl. hilft erstmal das Plugin Enable jQuery Migrate Helper weiter, mehr dazu z.B. in diesem Blogbeitrag Probleme nach Update auf WordPress 5.5 und mögliche Lösungen bei wordpress.org

    Das Theme erzeugt eine darauf hindeutende Fehlermeldung und ist vermutlich nicht mit WordPres 5.5.x kompatibel:

    Code
    Uncaught TypeError: $(...).live is not a function ...

    Ich habe das alles nicht programmiert, sondern nur übernommen ...


    In dem Fall am besten die Person ansprechen, die das eingerichtet hat, das dürfte vom Zeitaufwand her die beste Lösung sein.

    Tipp bei Fragen/Hilfe zu Darstellungsproblemen, deaktiviere oder entferne alle Minify-, Cache-, Optimier-Plugins, derzeit mind. aktiv: Hummingbird

    Dabei auch darauf achten, dass in [FONT=Courier New].htaccess[/FONT] nichts von diesen Plugins zurückbleibt.

    Leere dann Deinen Browser-Cache und teste erneut.

    Diese [FONT=Courier New]/media/...[/FONT] Pfade kommen vermutlich vom Hummingbird Plugin.

    Ergänzung: Laufen sonst irgendwelche Schutzmechanismen für Medien o.ä.?

    Wie genau wurde die Seite gespeichert? Über das Menü "Seite speichern unter.." in Firefox? In dem Fall wäre das nur eine HTML-Seite, die man nicht direkt weiterbearbeiten kann, eher nur Textteile per Copy&Paste rauskopieren o.ä..

    Evtl. kann Strato weiterhelfen wenn dort ggf. noch ein Backup der Datenbank exisitiert, das ist allerdings relativ technisch, würde daher empfehlen, zeitnah den Strato Support anzurufen und das erstmal dort zu hinterfragen.

    Einige Tipps und Hinweise:

    • Blog als Startseite
    • aktuelle Startseite als Menüpunkt
    • mind. 5-8 fertige Beiträge schreiben vor dem Launch
    • regelmässig weitere Beiträge schreiben, 1x pro Woche minimum
    • Beitragslinks mit passenden Hashtags (z.B. grosse Städtenamen) mit Bild (Rechte beachten!) und Textauszug bei Twitter posten
    • ebenso in Facebookgruppen wo es ums Thema Einkaufen, Schnäppchen o.ä. geht
    • ebenso regelmässig Bilder aus euerem Markt bei instagram mit eurerer Seite in der Accountbeschreibung
    • euere Zielgruppe sind vermutlich eher Supermarktmitarbeiter als Kunden
    • eigene Domain ausserhalb von wordpress.com sichern, bei 0815 Hostern wenige EUR Aufwand
    • ggf. direkt von Anfang an selbst unter der eigenen Domain hosten
    • später von wordpress.com wegzumigrieren erzeugt Kosten für Weiterleitung
    • Rechtslage beachten, derzeit "Like", Tracking usw. nicht nicht DSGVO konform

    .. und nach diesem Code .. wurde die wp-config.php als lesbare thing.png in das Verzeichnis wp-content/uploads/ kopiert. .


    Dieser Code ist auskommentiert, das wird im Verlauf des Threads mehrfach angesprochen.

    .. wenn du in dem Verzeichnis wp-content/uploads/ eine thing.png findest .


    Wenn der Code nicht auskommentiert wäre, wäre thing.png durch Deaktivieren des Plugins wieder entfernt worden.

    Mit dem Schadcode konnte man beliebigen PHP-Code auf den Server laden und ausführen, die ganze Installation und alle daraus via PHP erreichbaren Ordner und Datenbanken usw. sind wie bereits beschrieben als kompromitiert zu betrachten. Ebenfalls dass ggf. noch weiterer Schadcode vorhanden ist und schon länger vorhanden war. Ebenfalls, dass für das weitere Vorgehen generell alle Verzeichnisse gelöscht werden müssen.

    Autoptimize 2.7.6 .. BBPress 2.5 .. Media Library Assistant 2.81


    Für alle diese Plugins sind seit mind. 3 Wochen Aktualisierungen verfügbar, ob sie auf den gehackten Websites genutzt wurden, ist nicht bekannt.

    Viele Angriffe erfolgen (teil)automatisiert, dabei geht auch vieles schief und vieles wird mehrfach gemacht. Beispielsweise wenn die Installation durch einen bereits vorhandenen anderen Trojaner erfolgt und die Steuerung oder Rückmeldung nicht klappt. Oder der Angreifer hatte verschiedene Versionen des Trojaners mit unterschiedlichen $_POST Variablen und hat erst eine unpassende erwischt, die sein sonstwo gehostetes Admintool o.ä. nicht ansprechen konnte, oder es waren unterschiedliche Versionen mit ganz anderen Funktionen, oder der Angreifer hat die als thing.png kopierte wp-config.php zum Download gesucht, aber übersehen, dass der entspr. Codeblock, der die Kopie erstellt, auskommentiert war oder umgekehrt, also nach erfolgreichem Download den Codeblock auskommentiert und das Plugin neu installiert oder was auch immer.

    Etwas mehr würde möglicherweise aus einem Server access.log hervorgehen, falls sich doch noch eines findet.

    Die 178.er IP hat Tage zuvor mehrfach versucht, ins Dash zu kommen. Dann hat es erstmals geklappt.


    Das ursprüngliche Einfallstor ist demnach noch unbekannt, oder war das Admin Kennwort "erratbar" und/oder wurde anderswo gleich/ähnlich verwendet?

    Wie es generell weitergeht siehe Link in #2, genau lesen und Punkt für Punkt alles abarbeiten...

    Der Screenshot besagt, dass

    • innerhalb einer Sekunde das Plugin installiert und eine ähnlich klingende Datei in die Mediathek geladen wurde, dann 5 Sekunden später die Datei in der Mediathek wieder gelöscht wurde (protokolliert Vaultpress ggf. so einen "Plugin via Upload" Vorgang? Nutze das selbst nicht)
    • dann ca. 20 Sekunden später das Plugin aktiviert wurde
    • und dann ca. 1.5 Minuten später offenbar ein Login stattfand (ggf. um Benutzer/Passwort Logging zu testen?)


    Woher das Plugin kam, geht daraus nicht hervor.

    Dein Hostinganbieter könnte Zugriffslogs (mit ggf. anonymisierten IPs) haben, frage zeitnah dort nach Server access logs und sichere die.

    Aus dem Screenshot geht nicht hervor, wie genau der Schadcode auf den Server kam.

    Aus Server access logs könnte man ggf. weitere Rückschlüsse ziehen.

    Es kann durchaus sein, dass noch weiterer Schadcode vorhanden ist und schon länger vorhanden war, der z.B. im Hintergrund aktiv wird, wenn sich ein Admin anmeldet o.ä. oder der ähnlich wie der gezeigte Schadcode einfach generell auf entspr.[FONT=Courier New] $_POST[/FONT] Variablen o.ä. wartet.

    Ein Trojaner kommt selten alleine...

    Danke für die Aufklärung, also die erste Verständnisvermutung.

    Interessant/hilfreich wäre, was noch vor dem im Screenshot gezeigten Ablauf passiert ist, dafür sollte man zeitnah access.log u.ä. Zugriffslogs im Hosting sichern.

    Bearbeitet: In der Datei [FONT=Courier New]/~6cb001a[/FONT] wurden "nur" Benutzer/Passwörter protokolliert, dort dürfte vermutlich eher kein sonstiger Schadcode gewesen sein.

    Mit diesem Schadcode konnte man beliebigen PHP-Code auch an Vaultpress usw. vorbei auf den Server laden und ausführen, die ganze Installation und alle daraus via PHP erreichbaren Ordner und Datenbanken usw. sind daher als kompromitiert zu betrachten.

    Noch eine Frage: Wurden die letzten beiden Funktionen im Schadcode, die [FONT=Courier New]wp-config.php[/FONT] zum Download als [FONT=Courier New]thing.png[/FONT] bereitstellen von euch auskommentiert oder war das so?

    Das Ausblenden in der Pluginliste lag übrigens nicht an einem Unterstrich sondern am [FONT=Courier New]wpmm__filter_plugins[/FONT] Filter im Code.

    Oben schreibst Du, da wäre ein "Unterstrich am Ende". Wo genau ist der Unterstrich? Wie ist die exakte Ordner-/Dateistruktur des Schadcodes?

    Wenn man nicht ermittelt, woher der Angreifer die zur Installation des Schadcodes genutzten Admin-Account Zugangsdaten hat, sind weitere Massnahmen erstmal relativ sinnlos.

    Kannst Du den Schadcode posten, z.B. bei pastebin.com o.ä.?

    Tipp am Rande: Mehrere "Sicherheits"-Plugins parallel sollten nicht dauerhaft laufen, die stehen sich meist gegenseitig im Weg...

    .. ein Plugin namens wp-meta-manager.php_ installiert worden. .. Darin enthalten ist eine Datei/wp-meta-manager.php. mit Schadcode ..


    Zum Verständnis, also eine Ordnerstruktur so wie diese?

    Code
    /wp-content/plugins/wp-meta-manager.php_/wp-meta-manager.php


    Sind noch weitere Dateien in diesem Ordner?

    Oder ist es nur eine Datei mit Unterstrich am Ende so wie diese?

    Code
    /wp-content/plugins/wp-meta-manager.php_


    Die wäre dann eigentlich nicht ausführbar.

    ... Das Plugin wurde laut Aktivitätenprotokoll über Admin-Accounts installiert, ..


    Dann sollte man zeitnah ermitteln, wie der Angreifer an die Admin-Account Zugangsdaten gekommen ist, um die eigentliche Lücke zu finden.

    Das allgemeine weitere Vorgehen bei einem Hack ist z.B. hier beschrieben.