m3m0o/portabilis-ieducar-user-type-privilege-escalationPreuve de concept pour l'exploitation de la vulnérabilité décrite dans CVE-2025-11554, qui concerne la possibilité d'une élévation de privilèges via des requêtes arbitraires vers le point de terminaison de changement de types d'utilisateurs dans le logiciel i-Educar.
Preuve de concept pour l'exploitation de la vulnérabilité décrite dans CVE-2025-11554, qui concerne la possibilité d'une élévation de privilèges lors de requêtes arbitraires vers les points de terminaison de types d'utilisateurs dans le logiciel i-Educar.
Les utilisateurs ne disposant pas des privilèges nécessaires pour modifier les types d'utilisateurs peuvent modifier les permissions des types d'utilisateurs enregistrés via une requête arbitraire vers le point de terminaison responsable de cette action. Cela permet aux utilisateurs à faibles privilèges d'élever leurs privilèges en accordant des permissions maximales au type d'utilisateur auquel ils sont associés, compromettant ainsi toutes les sections de l'application.
Pour démontrer la vulnérabilité, nous allons simuler un chemin d'attaque qui pourrait être utilisé dans un scénario d'exploitation réel. Tout d'abord, nous avons l'utilisateur Usuário sem Privilégios, qui est associé au type d'utilisateur Baixíssimo.
Le type d'utilisateur Baixíssimo n'a aucun privilège associé et se voit attribuer le niveau d'accès le plus bas, Biblioteca, qui a le niveau 8.
Pour les besoins de cette démonstration, nous pouvons constater que les permissions de modification des types d'utilisateurs sont désactivées pour ce rôle, ce qui signifie que les utilisateurs qui y sont associés ne devraient pas pouvoir consulter, créer/modifier ou supprimer des types d'utilisateurs.
En nous connectant en tant que Usuário sem Privilégios, nous pouvons confirmer qu'aucune permission n'est attribuée, car aucune section ne lui est disponible.
La première étape du processus d'élévation de privilèges consiste à identifier le type d'utilisateur assigné à l'utilisateur. Dans diverses réponses aux requêtes qui renvoient des documents HTML rendus par l'application, cette information se trouve dans la variable dataLayer, située dans le premier élément script du document. Nous pouvons vérifier cette information en accédant à la page d'accueil de l'application, par exemple. Dans cette démonstration, Burp Suite sera utilisé pour l'analyse et la manipulation des requêtes.
Après avoir identifié le type d'utilisateur associé à l'utilisateur actuel, l'étape suivante consiste à déterminer son identifiant stocké dans la base de données. Pour ce faire, le point de terminaison /usuarios/tipos/<cod_tipo_usuario> doit être utilisé. Étant donné que les identifiants des types d'utilisateurs sont numériques et séquentiels, il est possible d'énumérer tous les types d'utilisateurs stockés jusqu'à ce que celui associé à l'utilisateur actuel soit trouvé.
Le type d'utilisateur identifié par 1, par exemple, est le type d'utilisateur administratif, Administrador, par défaut.
Dans la réponse de l'application, nous pouvons voir les permissions associées au type d'utilisateur dans l'objet processes. Chaque section spécifique est identifiée par un identifiant numérique unique, et le niveau d'accès du type d'utilisateur à cette section est déterminé par les nombres 0, 1, 2, ou 3 :
Nous pouvons observer que le type d'utilisateur administratif a un niveau d'accès 3 pour toutes les sections.
Lors de la requête du type d'utilisateur avec l'identifiant 2, nous constatons qu'il correspond au type d'utilisateur associé à l'utilisateur actuel. Ce type d'utilisateur a un niveau d'accès de 0 pour toutes les sections.
Avec tout cela à l'esprit, nous pouvons procéder à l'élévation de privilèges. Pour ce faire, une requête POST doit être envoyée au même point de terminaison, contenant l'identifiant du type d'utilisateur correspondant à l'identifiant du type d'utilisateur associé à l'utilisateur actuel. Le corps de la requête doit inclure les paramètres _method, name, level, description, et processes. Toutes les valeurs requises ne sont pas immédiatement compréhensibles, mais comme il s'agit d'un projet open-source, la structure correcte de la requête pourrait facilement être découverte par une revue de code ou des tests manuels sur une instance locale.
Dans la requête ci-dessous, nous modifions le niveau d'accès pour toutes les sections au niveau d'accès maximal (3) et changeons le type d'utilisateur de Biblioteca à Poli-institucional (paramètre level défini sur la valeur 1).** Cela signifie que l'utilisateur obtiendrait l'accès à toutes les institutions enregistrées, et pas seulement à celle qui lui est associée lors de sa création.
Après cela, en rechargeant la page d'accueil, nous pouvons confirmer que l'utilisateur auparavant sans privilèges dispose désormais de tous les privilèges disponibles dans le contexte de l'application, accordés arbitrairement.
Les routes des points de terminaison vulnérables se trouvent dans le fichier routes/web.php.
Les méthodes vulnérables utilisées par ces routes se trouvent dans le fichier app/Http/Controllers/AccessLevelController.php. Ces méthodes n'effectuent pas de vérification des permissions sur l'utilisateur demandeur avant d'exécuter les actions demandées sur les types d'utilisateurs.
Ce logiciel est utilisé comme solution de gestion scolaire dans diverses institutions publiques. Chaque instance contient potentiellement divers types d'informations sensibles sur les utilisateurs et les étudiants enregistrés, telles que des documents d'identification et des dossiers médicaux (conditions médicales). Dans un scénario où un utilisateur malveillant à faibles privilèges ou un compte contrôlé par un attaquant exploite cette vulnérabilité, la confidentialité, l'intégrité et la disponibilité de ces dossiers seraient menacées. Une évaluation rapide de la sécurité du projet révélerait cette faiblesse.
