XSS2Shell: Eine Pre-Auth-Angriffskette kann WordPress in ein Einfallstor zum Server verwandeln

XSS2Shell nutzt eine Pre-Auth-Angriffskette in WordPress über DOM-Clobbering und REST API, um Root-Zugriff zu ermöglichen.

XSS2Shell: Eine Pre-Auth-Angriffskette kann WordPress in ein Einfallstor zum Server verwandeln
Schwachstellen

Illustration mit KI erzeugt

Von der Login-Seite zum DOM-Clobbering

Forscher von Pwn haben kürzlich XSS2Shell beschrieben – eine kritische Angriffskette, die auf der WordPress-Anmeldeseite beginnt und keine vorherige Authentifizierung erfordert.

Der Angriff verwendet einen nicht existierenden Benutzernamen, der in der Fehlermeldung ausgegeben wird. Der erste von PHP über strip_tags() angewendete Filter erkennt Elemente mit einem Leerzeichen zwischen dem Zeichen < und dem Namen nicht als gültige Tags:

< area id=ajaxurl>

Das anschließende wp_kses_post() interpretiert die Zeichenfolge hingegen als gültiges HTML-Element und macht sie zu aktivem Inhalt im DOM.

Das Attribut id="ajaxurl" ermöglicht anschließend ein DOM-Clobbering: Der Browser stellt das Element als Eigenschaft window.ajaxurl bereit und verändert dadurch das erwartete Verhalten der Seitenskripte.

Der Missbrauch von user-profile.js und der REST API

Die Login-Seite lädt außerdem user-profile.js, das für die Verwaltung von Passwortzurücksetzungen verwendet wird. Das Skript kann eine manipulierte Schaltfläche zum Zurücksetzen automatisch erkennen und auslösen – ohne dass der Administrator ausdrücklich klicken muss.

Anschließend nutzt die Angriffskette eine JSONP-Antwort der REST API aus. Der Parameter callback akzeptiert Punkte, sodass sich Eigenschaftsketten zwischen Browserfenstern durchlaufen lassen. Die Forscher verwendeten eine erstmals 2022 veröffentlichte Technik, um in der aktiven Sitzung eines authentifizierten Administrators einen Click-Event aus einem anderen Fenster auszulösen.

Der Browser wird zu einer WordPress-Seite für die Genehmigung von Application Passwords geleitet. Die Cookies und der Nonce der Administratorsitzung ermöglichen es, die Genehmigungsschaltfläche automatisch auszulösen.

Das Ergebnis ist ein gültiges Application Password für das Administratorkonto.

Von der Zugangsdaten zur möglichen Codeausführung

WordPress akzeptiert das Application Password über HTTP-Basic-Authentifizierung an der REST API. Die CORS-Konfiguration spiegelt den Ursprung der Anfrage und erlaubt die Header Authorization und Content-Type. Dadurch werden authentifizierte Cross-Origin-API-Aufrufe möglich.

Bei Single-Site-Installationen verfügen Administratoren normalerweise über die Capability unfiltered_html. Dadurch kann beliebiges JavaScript in veröffentlichten Inhalten verbleiben.

Der Angreifer kann eine Seite mit JavaScript-Code veröffentlichen, sie zum Laden eines Plugins verwenden und so beliebigen PHP-Code ausführen. Im Proof of Concept bestätigte eine JSON-Antwort die Ausführung unter der Identität des Webserver-Benutzers.

Zu den potenziellen Auswirkungen gehören:

  • Kompromittierung der Administratorsitzung;
  • betrügerische Ausstellung von Application Passwords;
  • Veröffentlichung von JavaScript-Inhalten;
  • Installation bösartiger Plugins;
  • Remote Code Execution;
  • mögliche vollständige Übernahme des Servers.

Der Proof of Concept hinterließ keine Persistenz: Die Forscher widerriefen die Zugangsdaten, löschten die Seite und entfernten das Plugin-Verzeichnis.

Was Administratoren überprüfen sollten

Es wurden keine CVE-Kennungen und keine betroffenen oder korrigierten Versionsnummern für WordPress, PHP, Browser oder die beteiligten Komponenten genannt.

Administratoren sollten:

  1. WordPress auf die vom Anbieter bereitgestellten korrigierten Versionen aktualisieren;
  2. Sicherheitsupdates für WordPress, PHP und installierte Komponenten einspielen;
  3. verdächtige oder nicht benötigte Application Passwords widerrufen;
  4. veröffentlichte Seiten, Plugins, Plugin-Verzeichnisse und REST-API-Logs überprüfen;
  5. nach ungewöhnlichen Anfragen an Endpunkte zur Genehmigung von Application Passwords suchen;
  6. JSONP-Datenverkehr und Cross-Origin-Aufrufe mit dem Header Authorization überwachen;
  7. Administratorrechte reduzieren und die Verwendung von unfiltered_html nach Möglichkeit einschränken.

Die betroffenen Versionen sind nicht bekannt. Das Ausbleiben beobachtbarer Anomalien reicht daher nicht aus, um eine Kompromittierung auszuschließen.

Sicherheitsdossiers

Auch interessant

Quellen

Dieser Artikel ist eine eigenständige Aufbereitung auf Basis der folgenden Quellen.

Zurück zur Startseite

Aktuelle Cybersecurity-News

Alle Cybersecurity-News →