[English]Aktuell werden einige Betreiber von WordPress-Seiten auf dem falschen Fuß erwischt. Die betreffenden WordPress-Instanzen zeigen eine Warnung, dass die Seite verschlüsselt ist. Es wird ein Lösegeld von 0,1 Bitcoin zur Entschlüsselung gefordert. Die WordPress-Instanz ist aber nicht verschlüsselt, sondern die Meldung wird über ein kompromittiertes Plugin angezeigt.
Anzeige
Benjamin Martin berichtete letzten Freitag (15.11.2021), dass man eine Reihe von Webseiten gefunden habe, die eine Ransomware-Infektion vorgaukeln und eine Lösegeldforderung von 0,1 Bitcoin zur Entschlüsselung fordern.
Google liefert bei einer Suche nach "FOR RESTORE SEND 0.1 BITCOIN" eine Reihe Treffer (aktuell über 400). Ich habe mal einige ausgewiesene Webseiten aufgerufen und bekam die obige Meldung zu sehen.
SITE ENCRYPTED FOR RESTORE SEND 0.1 BITCOIN: 3BkiGYFh6QtjtNCPNNjGwszoqqCka2SDEc (create file on site /unlock.txt with transaction key inside)
Die Forderung beläuft sich auf ca. 6.000 US-Dollar zur Entschlüsselung der Webseite. Gleichzeitig läuft auf der Seite vorgeblich ein Timer ab. Da dürfte manchem Website-Betreiber das Herz in die Hose rutschen. Aber an dieser Stelle ist keine Panik angebracht und der Forderung sollte man nicht nachkommen. Ein Betroffener hatte den Sicherheitsanbieter Sucuri mit der Bereinigung seiner WordPress-Installation beauftragt. Als die Spezialisten sich das Ganze ansahen, stellten sie fest, dass die WordPress-Instanz nicht verschlüsselt war.
./wp-content/plugins/directorist/directorist-base.php
Bei der Analyse fanden die Forscher heraus, dass die Dateistruktur für das angegebene BitCoin-Konto auf die obige php-Datei zeigt. Das ist aber eine Datei des WordPress Plugin directorist. Da versucht also jemand über eine Sicherheitslücke im betreffenden Plugin die WordPress-Seitenbetreiber aufs Glatteis zu locken.
Die Bereinigung dieser Infektion bestand in diesem Fall darin, das genannte Plugin aus dem Verzeichnis wp-content/plugins zu entfernen. Problem war aber, dass anschließend alle Seiten und Beiträge eine 404 Not Found-Antwort lieferten. Die Schadfunktion hatte die WordPress-Datenbank nach allen Posts und Seiten durchforstet und deren Publishing-Status auf "Null" gesetzt. Das lässt sich aber mit dem SQL-Befehl:
UPDATE `wp_posts` SET `post_status` = 'publish' WHERE `post_status` = 'null';
rückgängig machen. Dort muss dann lediglich noch kontrolliert werden, ob nicht Beiträge drunter waren, deren Post-Status manuell vom Autor geändert worden sind. Unklar ist, ob der Angriff noch "in Entwicklung ist", bei dem das Verschlüsselungsmodul noch nicht funktionierte. Wer betroffen ist, ist als mit einem blauen Auge davon gekommen. Weitere Details finden sich bei Sucuri im Blog.
Das Plugin direcorist wurde vor 2 Tagen auf die Version 7.0.6.2 aktualisiert, so dass die obige Schwachstelle nicht mehr ausgenutzt werden kann. An dieser Stelle aber der Hinweis, dass WordPress-Administratoren die Zahl der Plugins begrenzen und diese aktuell halten sollten. Und es empfiehlt sich ein regelmäßiges Backup der WordPress-Installation und der Datenbank, um bei einer Infektion schnell den alten Zustand zurücksetzen zu können.
2015
> … Und es empfiehlt sich ein regelmäßiges Backup der WordPress-Installation und der Datenbank, um bei einer Infektion schnell den alten Zustand zurücksetzen zu können.
Das regelmäßige Backup ist einerseits völlig richtig, andererseits nutzt der alte Zustand alleine wenig, wenn die Leute den dann inklusive der Lücke wieder einspielen oder vom Hosting einspielen lassen und nötige Updates nicht direkt vornehmen bzw. nicht auf Plugins oder Theme verzichten, wenn es noch keine Updates für die Lücken gibt. Für viele wäre das wohl selbstverständlich, aber eben nicht für alle, gerade in der WordPress Zielgruppe.
Schön, dass Du den Hinweis gleich gefunden und in der FB-Gruppe bei Dir verlinkt hast. Da werden Dir sicher auch einige Kunden dankbar sein.
Mit der >ganz allgemeinenBackup Management<. Dazu gehören – wenn es bestenfalls überhaupt gemacht wird – eine gewisse Planregelmäßigkeit, die ständige Aktualität der Ressourcen nach jedem WP Core Update und für die Änderungen ein Backup Journal. Letzteres ist wichtig, damit man weiß, was wan zuletzt geändert wurde. Das hat dann höchste Tragweite mit unangenehmen Konsequenzrisiken, wenn sich zwischenzeitlich die Rechtsprechung geändert hat. Hat man keine Kontrolle über die inhaltlichen Änderungen, dann befindet man sich sofort in der Abmahnfalle. Daher ist es sinnvoll seinem Kunden diese Sicherheit monetär anzubieten.
Mir ist bereits regelmäßig auch eine "http" Verbindung zu "*cloudproxy . sucuri . net"(…so ähnlich) aufgestoßen bei Aufruf der Seite "borncity . com/blog/" – geht das nicht auch anders…
Inhalt der Paket-Daten noch nicht angesehen.
Bewusst wird es nicht eingesetzt – k.A. wo das her kommt. Die URL gehört vermutlich zur Sucuri-Firewall – hatte ich mal verwendet und deren Virenscanner – ich setze aber aktuell eine andere Firewall ein. Auf so etwas werde ich nicht verzichten, dann kann ich den Blog auch gleich einstellen und komme einem Hack zuvor.
Später [Nachtrag]
Das Laden des Blog funktioniert auch ohne den zustande kommenden Zugriff auf den(*) Server. Sind auch nur an die 3kb.
Andererseits hast Du in diesem Beitrag ja selber auf sucuri.net Blog verwiesen – ändert aber nichts an der generellen Verbindung bei Blog-Aufruf…egal – Geschichte…
[WARUM, DARUM…]
Die HTTP-Verbindung ist Teil der aktivierten "OSCP" Online-Zertifikat Überprüfung einer(Deiner) Website – in meinem "derzeit" verwendeten Browser, bei Seiten-Aufruf!
Der Starfield Server(ocsp.starfieldtech.com) liegt im WHOIS angegebenen iP-Bereich (192.124.249.0 – 192.124.249.255) von "*.sucuri.net" und wird hier nur als *.sucuri.net Zugriff angezeigt bei der Whois-Domain-Auflösung.
———————————————–
Letztendlich das gleiche wie bei der aktivierten Zertifikatsüberprüfung von Windows eigenen Browsern, da findet es aber durch "svchost.exe" auch über http statt(zumindest bei Win7).
Weil ich davon angefangen habe hat es mir wohl doch keine Ruhe gelassen – kommt Zeit, kommt plötzlich die Erleuchtung, habe fertig. ;-)