Shopper: privilege escalation via improper Livewire admin component authorization

Beschreibung

## Zusammenfassung Drei Livewire-Administratorkomponenten in `shopper/framework` (letzter Master bei Commit `fcd0c59`, veröffentlicht als v2.8.0)-Gate-Zustand-mutierende Aktionen mit der schreibgeschützten `view users`-Berechtigung. Dies ist die gleiche Klasse wie das Problem Shopper in v2.8.0 / PR #511 / [GHSA-f946-9qp6-vgch] (https://github.com/shopperlabs/shopper/security/advisories/GHSA-f946-9qp6-vgch) - die PR hat die meisten Schreibaktionen von "view users" auf "access setting" verschoben, aber drei wurden verpasst (eine davon ist eine brandneue Datei, die vom Sicherheits-Commit selbst hinzugefügt wurde). Ein Mitarbeiterbenutzer, der nur `view users` + `access dashboard` (eine realistische "Support"- oder "Viewer"-Rolle pro Shoppers eigenem `PermissionsTableSeeder`) hat, kann: (1) sich selbst eskalieren, indem er eine Berechtigung für seine eigene Rolle erteilt; (2) ein brandneues Admin-Teammitglied mit einem gewählten Passwort und der `admin`-Rolle erstellen und sich dann als dieser Benutzer anmelden; (3) beliebige `permissions`-Zeilen löschen (RBAC DoS) oder - wenn `can be removed=true` - ganze Rollen löschen. CVSS 3.1: `AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H` = 8.8 (High). CWE-285 (unsachgemäße Autorisierung) + CWE-862 (fehlende Autorisierung). ## Anfällige Komponenten (Pfade relativ zu repo root) ### 1 `packages/admin/src/Livewire/Components/Settings/Team/Permissions.php` - `togglePermission(int $id)` in Zeile 28 ruft `$this->authorize('view users');` `removePermission(int $id)` in Zeile 55 ruft `$this->authorize('view users');` Die Berechtigungsleiste in `packages/admin/resources/views/livewire/components/settings/team/permissions.blade.php` Zeile 34 gibt die `id` jeder Berechtigung direkt in `wire:click` Handlern aus, so dass der Angreifer nicht einmal IDs erraten muss – die Seite selbst zählt sie auf. Nettoeffekt: Jeder Benutzer, der die Berechtigungskomponente einbinden kann (auf `view users` angezeigt), kann eine beliebige Berechtigungszeile für die gebundene `$role` gewähren. Durch die Gewährung von `access setting` für die eigene Rolle des Angreifers wird jede Aktion freigeschaltet, die PR #511 angeblich mit `->authorize('access setting')' gehärtet hat. Die Gewährung von `delete customers`, `edit orders`, `edit products`, `add brands` usw. ist eine direkte Eskalation der Datenmodifikation. ### 2) `packages/admin/src/Livewire/SlideOvers/CreateTeamMember.php` - `mount()` in Zeile 53 ruft `$this->authorize('view users'); `store()` in Zeile 122 ruft `$this->authorize('view users');` Diese Datei ist "neuer Dateimodus 100755" in Commit "fcd0c59" - sie wurde als Teil des Sicherheitsfixes erstellt und hat das gleiche falsch klassifizierte Gatter geerbt. `store()` erstellt einen `User` mit `email verified at = now()`, dem vom Angreifer gewählten Passwort und einer beliebigen `role id`. Der Optionsfilter `Radio::make('role id')` schließt `config('shopper.admin.roles.user')` aus, sodass die `admin`-Rolle wählbar ist. Loggen Sie sich aus, melden Sie sich als neues Konto → voller Administrator an. ### 3 `packages/admin/src/Livewire/Pages/Settings/Team/RolePermission.php` - `deleteAction` in den Zeilen 81-90: nur gated by `->visible($this->role->can be removed)`, ohne `->authorize()` Kette. Seitenebene `mount` (Zeile 52) erfordert nur `view users`. Für jede Rolle mit `can be removed = true`, a ..

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: 2.9.2.

Empfohlene Schritte

• Betroffene Systeme identifizieren: shopper/framework.
• 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.