Privilege Escalation/Bypass through UsersController->actionImpersonateWithToken()

Beschreibung

### Zusammenfassung Ein Benutzer mit niedrigem Privileg (oder ein nicht authentifizierter Benutzer, dem eine freigegebene URL gesendet wurde) kann seine Privilegien für den Administrator erhöhen, indem er "UsersController->actionImpersonateWithToken" missbraucht. Betroffene Benutzer sollten auf Craft 4.17.6 und 5.9.12 aktualisieren, um das Problem zu beheben. ### Details Ich bin ein Sicherheitsforscher bei Anthropic. Ich verwende LLMs, um Schwachstellen in Open-Source-Software zu identifizieren, und habe einige Zeit damit verbracht, Craft CMS zu untersuchen. Ich glaube, ich habe einen ziemlich ernsten Bug gefunden. Während ein LLM diesen Fehler anfangs gefunden hat, habe ich ihn manuell validiert und diese E-Mail selbst geschrieben. Diese Sicherheitsanfälligkeit ermöglicht es jedem Benutzer mit niedrigen Privilegien, seine Privilegien zu erhöhen und ein Administrator zu werden, oder unter extremen Umständen unprivilegierte Benutzer, dasselbe zu tun. Daher betrifft diese Schwachstelle Craft Pro und Team mehr als Craft Solo. Insbesondere kann ein Angreifer, der ein gültiges "Vorschau-Token" besitzt, dann `&action=users/impersonate-with-token&userId=1&prevUserId=1` an die Vorschau-URL anhängen, um die Anforderung in den Imitations-Endpunkt zu entführen und sich als jeder Benutzer (einschließlich Admin) ohne Authentifizierung anzumelden. Das Erhalten des Vorschau-Tokens ist einfach, und alles, was ein Editor tun müsste, ist, einen einzelnen Artikel zu erstellen, auf "Vorschau" zu klicken und dann dieses Token wiederherzustellen. Nach meinem besten Verständnis des Codes passiert Folgendes: 1. Der Aktions-Re-Dispatch in `actionPreview()` übergibt `$skipSpecialHandling=true` zu `handleRequest()` und übergibt `$checkToken=false` zu `checkIfActionRequest()`, wodurch ein von einem Angreifer gesteuerter Aktionsabfrageparameter das Versandziel überschreiben kann. 2. Der `requireToken()`-Schutz auf `actionImpersonateWithToken()` überprüft nur einen booleschen (` hadToken`), der gesetzt wurde, als der Vorschau-Token ursprünglich aufgelöst wurde. Es wird nicht überprüft, ob das token für die imitation-aktion bestimmt war, und so erfüllt jedes gültige token von einer route die Überprüfung. 3. `actionImpersonateWithToken` ist in `$allowAnonymous` aufgeführt und führt keine Autorisierung über `requireToken()` aus, so dass keine vorherige Authentifizierung erforderlich ist. ### PoC Ich habe einen funktionierenden PoC, der die vollständige Admin-Übernahme des neuesten Craft CMS 5.9.10 erreicht. Spawne eine lokale Version von Craft. Dann möchten Sie sich anmelden und ein gültiges Setup erstellen: 1. Melden Sie sich unter http://host:18895/admin an. 2. Gehen Sie zu Einstellungen, Abschnitten, Neuem Abschnitt (Name: "Blog", Typ: "Channel") 3. Legen Sie unter Site Settings das URI Format auf blog/{slug} fest 4. Gehen Sie dann zu Entries, New Entry, Blog und geben Sie ihm einen Titel Als nächstes erhalten Sie ein Vorschau-Token 1. Öffnen Sie den gespeicherten Eintrag im Editor 2. Klicken Sie auf den Preview-Button 3. Ein Vorschaubereich öffnet sich mit dem in einem iframe 4 gerenderten Eintrag. Klicken Sie mit der rechten Maustaste in den Vorschaubereich und Inspect Element 5. Finde das Element; sein src enthält die tokenisierte URL: `http://host:18895/blog/title?x-craft-live-preview=...&token=XXXXXXXXXX` 6. Kopieren Sie den Wert `token=` Schließlich führen Sie den Exploit aus: 1. Öffnen Sie ein neues inkognito/privates Browserfenster 2. Navigieren Sie zu: `http://host:18895/?token=XXXXXXXX&action=users/impersonate-withtoken&userId=1& ..

Quellen & weiterführende Informationen

Hier werden ausschließlich tatsächlich zu dieser Schwachstelle gespeicherte Quellenbelege angezeigt.

Was ist zur Behebung zu tun?

Auf eine behobene Version aktualisieren: 4.17.6, 5.9.12.

Empfohlene Schritte

• Betroffene Systeme identifizieren: Pixel & Tonic Craft CMS.
• Exposition prüfen: Internet-Erreichbarkeit, Admin-Oberflächen, VPN, Mail- oder Webdienste.
• Update/Rollout auf behobene Version vorbereiten und priorisiert einspielen.
• Nacharbeiten dokumentieren: betroffene Assets, Maßnahme, Zeitpunkt, Restrestrisiko.

Übergangsmaßnahmen

• Zugriff auf betroffene Dienste auf vertrauenswürdige Netze einschränken.
• WAF/IDS/EDR-Regeln und Hersteller-IOCs aktivieren, sofern verfügbar.
• Nicht benötigte Funktionen, Plugins oder Dienste temporär deaktivieren.
• Administrative Zugänge besonders absichern: MFA, Passwortrotation, Session-Invalidierung.