Um schreiben oder kommentieren zu können, benötigen Sie ein Benutzerkonto.
Sie haben schon ein Benutzerkonto? Melden Sie sich hier an.
Jetzt anmeldenHier können Sie ein neues Benutzerkonto erstellen.
Neues Benutzerkonto erstellenWurde 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...
Dein Theme CSS färbt den Button derzeit weiss, damit ist er nicht sichtbar.
Ergänze z.B. folgendes unter Design > Customizer > Zusätzliches CSS
input[type="submit"].wpcf7-submit {
color: #777;
border-color: #ccc;
}
Oder schau mal wo Du in den Theme Einstellungen generell die Buttonfarbe umstellen kannst.
Das Plugin ist hier nur eine temporäre Lösung, lies die entspr. Hinweise und kontaktiere den Ersteller des Themes...
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:
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:
.. 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
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?
/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?
/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.
habe vorher aber [plain]https://linuxnews/wp-admin[/plain] eingegeben.
Dieser Link führt ins Nichts.
Deaktiviere mal alle Cache-, Minify- und sonstige Optimierungsplugins, derzeit mindestens aktiv: Cache Enabler. Das Plugin hat Dir ja schonmal einen Streich gespielt...
.. komme seitdem mit Chrome auf meiner Workstation nicht mehr ins Backend .. Ich gebe die URL für das Backend ein, lande aber immer im Frontend mit der URL [plain]http://linuxnews.de[/plain].
Welche URL genau gibst Du für das Backend ein?
Eigentlich sollte man nie auf [plain]http://linuxnews.de[/plain] landen, weil die WordPress Installation mit SSL, also [plain]https://[/plain] eingerichtet ist.
Lt. Seitenquelltext:
peaksandrosycheeks.com/event/mountainfilm-graz/
<body class="... postid-2513 ...">peaksandrosycheeks.com/event/27-bergfilmfestival
<body class="... postid-2439 ...">Normalerweise sollten Plugins beim Deaktivieren bzw. Deinstallieren solche Einträge selbst löschen, mehr dazu hier. Bei manchen Plugins kann man in den Einstellungen angeben, was mit welchen Einträgen in der Datenbank passieren soll.
Wenn man einen Pluginordner z.B. per FTP direkt löscht, können und werden solche Löschmechanismen von WordPress allerdings nicht laufen.
Viele Einträge in .htaccess oder der Datenbank kann man nach etwas Recherche problemlos manuell löschen, bei manchen Einträgen kann es Wechselwirkungen geben, wenn man z.B. nur Teile einer komplexeren Konstruktion "erwischt".
Erstelle am besten eine Fehlermeldung beim Plugin Support des Hummingbird Plugins, die lesen hier nicht mit.
..dass auch Autoren neue Veranstaltungen posten können und weiß nicht so genau, wo ich da ansetzen muss.
Vermutlich in der Zeile:
'capability_type' => 'page',
Mehr dazu siehe z.B. in der register_post_type() Dokumentation.