WordPress zeigt gerade Plugin Updates erst ~24h nach Verfügbarkeit an. Falls das Update in der Plugin-Übersicht nicht zu sehen ist, manuell installieren:
In WordPress Plugins > Plugin hinzufügen > Plugin hochladen
zip auswählen und „Jetzt installieren“ klicken
Wir haben Uberspace vorab informiert (danke für die Zusammenarbeit!). Wer dort hostet, ist vor dem Exploit auch ohne Update geschützt. Trotzdem aktualiseren!
Hab ihr mal bei Wordpress nachgefragt ob man in solchen Fällen auch dieses 24h Ding umgehen kann? War schon echt verwundert das es da keinen Force-Update Knopf oder sowas gibt und musste in meinem Ngnix+php.ini erst mal erlauben das so große ZIP Files überhaupt hochgeladen werden können
Ja kann man, habe ich auch gemacht (allerdings erst beim Release weil ich die falsche Annahme hatte, dass das nur das auto-update Feature betrifft). Habe tatsächlich innerhalb weniger Stunden die Antwort bekommen, dass es freigeschaltet sei — war es aber nicht. Habe dann nicht noch mal nachgehakt weil zu dem Zeitpunkt schon über ein halber Tag rum war.
Bei mir wurde es nicht angezeigt bis ich WP von 6.9 auf 7.0 aktualisiert hatte. Danach lief das Podlove Update automatisch durch … fand ich auch komisch
Ich habe eben Hinweis von meinem Hoster bekommen, dass in zwei Podlove-Installationen unter wp-content/cache/podlove Malware liegt. Beide Installationen hatte ich innerhalb weniger Stunden nach Eriks Post hier neulich aktualisiert. Vermutlich war selbst das zu spät.
Hoster erkennen die Malware ggf. auch, wenn sie für den Angreifer nicht nützlich sind. Der Patch verhindert nicht das Herunterladen von Dateien ins System (das ist Sinn und Zweck des ganzen, Bilddateien die auf z.B. einem FTP liegen, in WordPress zu ziehen, verkleinern, etc.). Nur dass sie nicht ausführbar sind und damit für den Angreifer unnütz. Die Hoster erkennen und bemängeln die bösartige Datei dennoch.
Bin am überlegen, wie ich das ganze grundsätzlich besser hinbekomme. Ist knifflig.
Wie geht man am besten vor wenn man jetzt auch Malware auf dem System hat?
Ich habe alles aktualisiert, alle als Malware angezeigten Dateien gelöscht und trotzdem habe ich noch 2x von Wordfence eine Benachrichtigung bekommen dass wieder solche Dateien (ausführbare Dateien als Bilder getarnt) gefunden wurden.
Podlove aus dem Plugin Ordner entfernen und neu hochladen?
Die gute Nachricht ist, dass die als Malware gemeldeten Dateien unproblematisch sind, so lange sie Bilddatei-Endungen haben. Löschen hilft nicht, so lange die Angreiferskripte noch laufen. Die können wieder Dateien hinlegen (auch wenn sie mit dem Angriff insgesamt nicht durchkommen, die Datei liegt dann erstmal da rum).
Ich habe einen Patch fast so weit, der die URL-Manipulierung verhindert und damit das Einfallstor ganz schließt. Einen Moment Geduld bitte
Release 4.5.3 ist verfügbar, mit heißer Nadel gestrickt. Wie auch beim vorherigen Release: Wird erst nach einem Tag im Plugin-Update Interface erscheinen. So lange nur manuell zu installieren wie es schon oben im Startpost steht.
Danach noch einmal gemeldete Dateien löschen (oder das ganze Cache-Verzeichnis), danach sollte Ruhe sein. Bild-URLs sind jetzt signiert. D.h. nur URLs die vom Publisher erzeugt werden, sind auch gültig. Angreifer haben bisher existierende URLs genommen und angepasst, um ihre eigenen Dateien ins Cache-System zu mogeln. Das wird durch die Signatur nun abgewehrt.
Ich hab jetzt dasselbe Problem, wie einige andere hier, mein Hoster hat heute (24.07.) zwei Schad-Dateien gemeldet, obwohl ich 4.5.3 am Tag des WP-Releases eingespielt hatte.
Hoffe, dass es jetzt erst entdeckt wurde, aber zur Sicherheit noch die Frage:
Verstehe ich dich richtig, dass der Schadcode „nur“ Dateien ablegt, aber ich um meine Wordpress-Installation (wahrscheinlich) keine Angst haben muss? Oder sollte man zur Sicherheit den Flammenwerfer anlegen und alles neu machen?
Nur weil es bei mir die Datein in den Ordner waren, heisst das aber nicht unebdingt, dass es diese immer sind. Wenn ich @ericteubert richtig verstanden habe, sollte haendisch den wp-content/cache/podlove ordner loeschen die datein loeschen.
4.5.2 hat dafür gesorgt, dass die Dateien als z.B. shell_original.gif statt shell_original.php gespeichert werden. Heißt: Der Angreifer kann die Datei zwar ablegen, sie ist in der Regel aber für ihn unnütz, da von außen nicht ausführbar.
Um zu schauen ob ein Angriff aus irgendwelchen Gründen doch gelang: In der Regel sind das Downloadskripte für Web Shells, d.h. das lädt eine weitere PHP Datei ins Verzeichnis. Heißt: Schaut wann die shell_original.gif erstellt wurde und sucht nach PHP Dateien, die danach erstellt wurden. Die können irgendwo im WordPress-Verzeichnis liegen, nicht nur im Cache. Wenn man sowas findet, dann ist das System potenziell hinüber und es hilft nur der Flammenwerfer. Ist bis auf die shell_original.gif o.ä. im Cache-Verzeichnis nichts zu finden, sollte alles gut sein.
Erst 4.5.3 macht die Lücke ganz zu indem es Manipulation an Cache URLs grundsätzlich verhindert.