Unauthenticated activation email trigger with potential user enumeration

Beschreibung

Der Endpunkt `actionSendActivationEmail()` ist für nicht authentifizierte Benutzer zugänglich und erfordert keine Berechtigungsprüfung für ausstehende Benutzer. Ein Angreifer ohne vorherigen Zugriff kann Aktivierungs-E-Mails für ein anhängiges Benutzerkonto auslösen, indem er die Benutzer-ID kennt oder erraten kann. Wenn der Angreifer die E-Mail-Adresse des Zielbenutzers kontrolliert, kann er das Konto aktivieren und Zugriff auf das System erhalten. Die Schwachstelle besteht nicht darin, dass ein anonymer Zugriff existiert - es gibt einen legitimen Anwendungsfall dafür. Die Schwachstelle besteht darin, dass der Endpunkt beliebige "userId" -Parameter akzeptiert, ohne den Besitz zu überprüfen. Craft CMS ermöglicht die öffentliche Benutzerregistrierung. Wenn ein Benutzer sich registriert, aber seine Aktivierungs-E-Mail nicht erhält (Spam-Filter, Tippfehlerkorrektur usw.), benötigt er eine Möglichkeit, einen erneuten Versand anzufordern. Aus diesem Grund befindet sich "send-activetion-email" im "allowAnonymous"-Array - es ist eine absichtliche Self-Service-Funktionalität. ### Die Sicherheitslücke Der Endpunkt akzeptiert `userId` als Identifikator: ``php $userId = $this->request->getRequiredBodyParam('userId'); ``Dies ermöglicht es jedem Besucher, Aktivierungs-E-Mails für jeden anstehenden Benutzer auszulösen, nicht nur für seine eigene Registrierung. --- ## Hintergrund Wenn Administratoren neue Benutzerkonten in Craft CMS erstellen, werden Benutzer in einem „ausstehenden Zustand erstellt, bis sie ihr Konto über einen E-Mail-Link aktivieren. Die Funktion `actionSendActivationEmail()` sendet (oder sendet erneut) diese Aktivierungs-E-Mail. **Erwartetes Verhalten:** Anonyme Benutzer sollten nur Aktivierungs-E-Mails für ihre eigene Registrierung erneut senden können. **Tatsächliches Verhalten:** 1. Der Endpunkt ist in `allowAnonymous` aufgeführt - kein Login erforderlich (absichtlich für Self-Service). Für ausstehende Benutzer gibt es KEINE Eigentumsüberprüfung. Jeder nicht authentifizierte Besucher kann Aktivierungs-E-Mails für jeden anstehenden Benutzer per ID auslösen --- ## Angriffsszenarien ### Szenario 1: Gezielte Kontoübernahme **Voraussetzungen:** Der Angreifer kontrolliert die E-Mail des Zielbenutzers (kompromittierte E-Mails, freigegebenes Postfach, Typosquatting usw.) `` 1. Der Administrator erstellt ein Benutzerkonto für victim@company.com 2. Das Benutzerkonto befindet sich im PENDING-Zustand (hat noch nicht aktiviert). Der Angreifer hat victim@company.com kompromittiert (oder es ist ein Tippfehler der Angreifer-Domain). Angreifer entdecken Benutzer-ID (brute-force, GraphQL-Enumeration oder Insiderwissen) 5. Angreifer (nicht authentifiziert) Trigger: POST /actions/users/send-Activation-email 6. Aktivierungs-E-Mail an victim@company.com (angriffskontrolliert) 7. Angreifer klickt auf Aktivierungslink, setzt Passwort 8. Angreifer erhält Zugriff als dieser Benutzer mit vorab zugewiesenen Berechtigungen `` ### Szenario 2: User ID Brute-Force Enumeration `` 1. Angreifer iteriert durch Benutzer-IDs (1, 2, 3, ...) 2. Für jede ID ruft der Angreifer send-activity-email 3 auf. Antwort zeigt Benutzerstatus: - "Aktivierungs-E-Mail gesendet." = Ausstehender Benutzer existiert - "Benutzer nicht gefunden" = Kein Benutzer mit dieser ID - "Aktivierungs-E-Mails können nur an inaktive oder ausstehende Benutzer gesendet werden" = Aktiver Benutzer existiert 4. Der Angreifer erstellt eine Karte aller Benutzer-IDs und deren Status 5. Für jeden anstehenden Benutzer, dessen E-Mail ein Angreifer kontrolliert ..

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.0, 5.9.0.

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.