m3m0o/portabilis-ieducar-user-type-privilege-escalationPrueba de concepto para la explotación de la vulnerabilidad descrita en CVE-2025-11554, que se refiere a la posibilidad de una escalada de privilegios mediante solicitudes arbitrarias al endpoint de cambio de tipos de usuario en el software i-Educar.
Prueba de concepto para la explotación de la vulnerabilidad descrita en CVE-2025-11554, que concierne a la posibilidad de una escalada de privilegios durante peticiones arbitrarias a los endpoints de tipos de usuario en el software i-Educar.
Los usuarios sin los privilegios necesarios para cambiar tipos de usuario pueden modificar los permisos de los tipos de usuario registrados mediante una petición arbitraria al endpoint responsable de esta acción. Esto permite a los usuarios con privilegios bajos escalar sus privilegios otorgando permisos máximos al tipo de usuario con el que están asociados, comprometiendo todas las secciones de la aplicación.
Para demostrar la vulnerabilidad, simularemos una ruta de ataque que podría utilizarse en un escenario de explotación real. Primero, tenemos al usuario Usuário sem Privilégios, que está asociado al tipo de usuario Baixíssimo.
El tipo de usuario Baixíssimo no tiene privilegios asociados y se le asigna el nivel de acceso más bajo, Biblioteca, que tiene el nivel 8.
Para los fines de esta demostración, podemos ver que los permisos para editar tipos de usuario están deshabilitados para este rol, lo que significa que los usuarios asociados a él no deberían poder ver, crear/editar ni eliminar tipos de usuario.
Al iniciar sesión como Usuário sem Privilégios, podemos confirmar que no se le asignan permisos, ya que no hay secciones disponibles para él.
El primer paso en el proceso de escalada de privilegios es identificar el tipo de usuario asignado al usuario. En varias respuestas a peticiones que devuelven documentos HTML renderizados de la aplicación, esta información se puede encontrar en la variable dataLayer, ubicada dentro del primer elemento script del documento. Podemos verificar esta información accediendo a la página de inicio de la aplicación, por ejemplo. En esta demostración, se utilizará Burp Suite para el análisis y la manipulación de peticiones.
Después de identificar el tipo de usuario asociado al usuario actual, el siguiente paso es determinar su identificador almacenado en la base de datos. Para lograrlo, se debe utilizar el endpoint /usuarios/tipos/<cod_tipo_usuario>. Dado que los identificadores de tipos de usuario son numéricos y secuenciales, es posible enumerar todos los tipos de usuario almacenados hasta encontrar el asociado al usuario actual.
El tipo de usuario identificado por 1, por ejemplo, es el tipo de usuario administrativo, Administrador, por defecto.
En la respuesta de la aplicación, podemos ver los permisos asociados al tipo de usuario en el objeto processes. Cada sección específica se identifica mediante un identificador numérico único, y el nivel de acceso del tipo de usuario a esa sección se determina por los números 0, 1, 2, o 3:
Podemos observar que el tipo de usuario administrativo tiene nivel de acceso 3 para todas las secciones.
Al solicitar el tipo de usuario con identificador 2, vemos que corresponde al tipo de usuario asociado al usuario actual. Este tipo de usuario tiene un nivel de acceso de 0 para todas las secciones.
Con todo esto en mente, podemos proceder con la escalada de privilegios. Para ello, se debe enviar una petición POST al mismo endpoint, que contenga el identificador del tipo de usuario correspondiente al identificador del tipo de usuario asociado al usuario actual. El cuerpo de la petición debe incluir los parámetros _method, name, level, description, y processes. No todos los valores requeridos son inmediatamente comprensibles, pero dado que este es un proyecto de código abierto, la estructura correcta de la petición podría descubrirse fácilmente mediante revisión de código o pruebas manuales en una instancia local.
En la petición siguiente, modificamos el nivel de acceso para todas las secciones al acceso máximo (3) y cambiamos el tipo de usuario de Biblioteca a Poli-institucional (parámetro level establecido al valor 1). Esto significa que el usuario obtendría acceso a todas las instituciones registradas, no solo a la asociada durante su creación.
Después de esto, al recargar la página de inicio, podemos confirmar que el usuario anteriormente sin privilegios ahora tiene todos los privilegios disponibles en el contexto de la aplicación, otorgados arbitrariamente.
Las rutas de los endpoints vulnerables se pueden encontrar en el archivo routes/web.php.
Los métodos vulnerables utilizados por estas rutas se pueden encontrar en el archivo app/Http/Controllers/AccessLevelController.php. Estos métodos no realizan una verificación de permisos sobre el usuario solicitante antes de ejecutar las acciones solicitadas sobre los tipos de usuario.
Este software se utiliza como solución de gestión escolar en diversas instituciones públicas. Cada instancia potencialmente contiene varios tipos de información sensible sobre usuarios y estudiantes registrados, como documentos de identificación y registros médicos (condiciones médicas). En un escenario donde un usuario malintencionado con privilegios bajos o una cuenta controlada por un atacante explote esta vulnerabilidad, la confidencialidad, integridad y disponibilidad de estos registros estarían en riesgo. Una evaluación de seguridad rápida del proyecto revelaría esta debilidad.
