m3m0o/portabilis-ieducar-user-type-privilege-escalationProof of Concept für die Ausnutzung der in CVE-2025-11554 beschriebenen Schwachstelle, die die Möglichkeit einer Privilegienausweitung durch beliebige Anfragen an den Endpunkt zur Änderung von Benutzertypen in der Software i-Educar betrifft.
Proof of Concept für die Ausnutzung der in CVE-2025-11554 beschriebenen Schwachstelle, die die Möglichkeit einer Privilegienerweiterung bei beliebigen Anfragen an Benutzertyp-Endpunkte in der Software i-Educar betrifft.
Benutzer ohne die erforderlichen Berechtigungen zum Ändern von Benutzertypen können die Berechtigungen registrierter Benutzertypen durch eine beliebige Anfrage an den für diese Aktion zuständigen Endpunkt ändern. Dies ermöglicht es Benutzern mit niedrigen Privilegien, ihre Privilegien zu erweitern, indem sie dem Benutzertyp, dem sie zugeordnet sind, maximale Berechtigungen gewähren, wodurch alle Bereiche der Anwendung kompromittiert werden.
Um die Schwachstelle zu demonstrieren, simulieren wir einen Angriffspfad, der in einem realen Ausnutzungsszenario verwendet werden könnte. Zunächst haben wir den Benutzer Usuário sem Privilégios, der dem Benutzertyp Baixíssimo zugeordnet ist.
Der Benutzertyp Baixíssimo hat keine zugeordneten Privilegien und ist der niedrigsten Zugriffsebene, Biblioteca, zugewiesen, die die Stufe 8 hat.
Für die Zwecke dieser Demonstration können wir sehen, dass die Berechtigungen zum Bearbeiten von Benutzertypen für diese Rolle deaktiviert sind, was bedeutet, dass Benutzer, die ihr zugeordnet sind, Benutzertypen nicht anzeigen, erstellen/bearbeiten oder löschen können sollten.
Nach der Anmeldung als Usuário sem Privilégios können wir bestätigen, dass keine Berechtigungen zugewiesen sind, da ihm keine Bereiche zur Verfügung stehen.
Der erste Schritt im Prozess der Privilegienerweiterung besteht darin, den zugewiesenen Benutzertyp des Benutzers zu identifizieren. In verschiedenen Antworten auf Anfragen, die gerenderte HTML-Dokumente von der Anwendung zurückgeben, finden sich diese Informationen in der Variablen dataLayer, die sich im ersten script-Element des Dokuments befindet. Wir können diese Informationen überprüfen, indem wir beispielsweise auf die Startseite der Anwendung zugreifen. In dieser Demonstration wird Burp Suite für die Analyse und Manipulation von Anfragen verwendet.
Nachdem der mit dem aktuellen Benutzer verbundene Benutzertyp identifiziert wurde, besteht der nächste Schritt darin, seine in der Datenbank gespeicherte Kennung zu bestimmen. Dazu sollte der Endpunkt /usuarios/tipos/<cod_tipo_usuario> verwendet werden. Da Benutzertyp-Kennungen numerisch und fortlaufend sind, ist es möglich, alle gespeicherten Benutzertypen aufzuzählen, bis der mit dem aktuellen Benutzer verbundene gefunden wird.
Der Benutzertyp mit der Kennung 1 ist beispielsweise standardmäßig der administrative Benutzertyp Administrador.
In der Antwort der Anwendung können wir die mit dem Benutzertyp verbundenen Berechtigungen im Objekt processes sehen. Jeder spezifische Bereich wird durch eine eindeutige numerische Kennung identifiziert, und die Zugriffsebene des Benutzertyps auf diesen Bereich wird durch die Zahlen 0, 1, 2, oder 3 bestimmt:
Wir können beobachten, dass der administrative Benutzertyp für alle Bereiche die Zugriffsebene 3 hat.
Wenn wir den Benutzertyp mit der Kennung 2 anfordern, sehen wir, dass er dem mit dem aktuellen Benutzer verbundenen Benutzertyp entspricht. Dieser Benutzertyp hat für alle Bereiche eine Zugriffsebene von 0.
Mit all dem im Hinterkopf können wir mit der Privilegienerweiterung fortfahren. Dazu muss eine POST-Anfrage an denselben Endpunkt gesendet werden, die die Benutzertyp-Kennung enthält, die der Kennung des mit dem aktuellen Benutzer verbundenen Benutzertyps entspricht. Der Anfragetext sollte die Parameter _method, name, level, description, und processes enthalten. Nicht alle erforderlichen Werte sind sofort verständlich, aber da es sich um ein Open-Source-Projekt handelt, könnte die korrekte Struktur der Anfrage leicht durch Code-Review oder manuelle Tests auf einer lokalen Instanz herausgefunden werden.
In der folgenden Anfrage ändern wir die Zugriffsebene für alle Bereiche auf maximalen Zugriff (3) und ändern den Benutzertyp von Biblioteca auf Poli-institucional (level-Parameter auf Wert 1 gesetzt). Dies bedeutet, dass der Benutzer Zugriff auf alle registrierten Institutionen erhält, nicht nur auf die, die bei seiner Erstellung mit ihm verbunden war.
Danach können wir nach dem Neuladen der Startseite bestätigen, dass der zuvor privilegienlose Benutzer nun über alle verfügbaren Privilegien im Kontext der Anwendung verfügt, die willkürlich gewährt wurden.
Die Routen für die verwundbaren Endpunkte finden sich in der Datei routes/web.php.
Die verwundbaren Methoden, die von diesen Routen verwendet werden, finden sich in der Datei app/Http/Controllers/AccessLevelController.php. Diese Methoden führen keine Berechtigungsprüfung des anfragenden Benutzers durch, bevor sie die angeforderten Aktionen an Benutzertypen ausführen.
Diese Software wird als Schulverwaltungslösung in verschiedenen öffentlichen Institutionen eingesetzt. Jede Instanz enthält potenziell verschiedene Arten sensibler Informationen über registrierte Benutzer und Schüler, wie Identifikationsdokumente und medizinische Aufzeichnungen (medizinische Zustände). In einem Szenario, in dem ein bösartiger Benutzer mit niedrigen Privilegien oder ein vom Angreifer kontrolliertes Konto diese Schwachstelle ausnutzt, wären die Vertraulichkeit, Integrität und Verfügbarkeit dieser Aufzeichnungen gefährdet. Eine schnelle Sicherheitsbewertung des Projekts würde diese Schwachstelle aufdecken.
