m3m0o/portabilis-ieducar-user-type-privilege-escalationProva de conceito para exploração da vulnerabilidade descrita em CVE-2025-11554, que diz respeito à possibilidade de escalonamento de privilégios por meio de requisições arbitrárias ao endpoint de alteração de tipos de usuário no software i-Educar.
Prova de conceito para exploração da vulnerabilidade descrita em CVE-2025-11554, que diz respeito à possibilidade de escalação de privilégios durante requisições arbitrárias aos endpoints de tipos de usuário no software i-Educar.
Usuários sem os privilégios necessários para alterar tipos de usuário podem modificar as permissões de tipos de usuário registrados através de uma requisição arbitrária ao endpoint responsável por essa ação. Isso permite que usuários com baixos privilégios escalem seus privilégios concedendo permissões máximas ao tipo de usuário ao qual estão associados, comprometendo todas as seções da aplicação.
Para demonstrar a vulnerabilidade, simularemos um caminho de ataque que poderia ser usado em um cenário real de exploração. Primeiro, temos o usuário Usuário sem Privilégios, que está associado ao tipo de usuário Baixíssimo.
O tipo de usuário Baixíssimo não possui privilégios associados e recebe o nível de acesso mais baixo, Biblioteca, que possui o nível 8.
Para fins desta demonstração, podemos ver que as permissões para edição de tipos de usuário estão desabilitadas para este perfil, o que significa que usuários associados a ele não deveriam conseguir visualizar, criar/editar ou excluir tipos de usuário.
Ao fazer login como Usuário sem Privilégios, podemos confirmar que nenhuma permissão é atribuída, pois nenhuma seção está disponível para ele.
O primeiro passo no processo de escalação de privilégios é identificar o tipo de usuário atribuído ao usuário. Em várias respostas a requisições que retornam documentos HTML renderizados pela aplicação, essa informação pode ser encontrada na variável dataLayer, localizada dentro do primeiro elemento script do documento. Podemos verificar essa informação acessando a página inicial da aplicação, por exemplo. Nesta demonstração, o Burp Suite será usado para análise e manipulação de requisições.
Após identificar o tipo de usuário associado ao usuário atual, o próximo passo é determinar seu identificador armazenado no banco de dados. Para isso, o endpoint /usuarios/tipos/<cod_tipo_usuario> deve ser usado. Como os identificadores de tipos de usuário são numéricos e sequenciais, é possível enumerar todos os tipos de usuário armazenados até encontrar aquele associado ao usuário atual.
O tipo de usuário identificado por 1, por exemplo, é o tipo de usuário administrativo, Administrador, por padrão.
Na resposta da aplicação, podemos ver as permissões associadas ao tipo de usuário no objeto processes. Cada seção específica é identificada por um identificador numérico único, e o nível de acesso do tipo de usuário a essa seção é determinado pelos números 0, 1, 2, ou 3:
Podemos observar que o tipo de usuário administrativo possui nível de acesso 3 para todas as seções.
Ao solicitar o tipo de usuário com identificador 2, vemos que ele corresponde ao tipo de usuário associado ao usuário atual. Este tipo de usuário possui nível de acesso 0 para todas as seções.
Com tudo isso em mente, podemos prosseguir com a escalação de privilégios. Para isso, uma requisição POST deve ser enviada ao mesmo endpoint, contendo o identificador do tipo de usuário correspondente ao identificador do tipo de usuário associado ao usuário atual. O corpo da requisição deve incluir os parâmetros _method, name, level, description, e processes. Nem todos os valores obrigatórios são imediatamente compreensíveis, mas como este é um projeto de código aberto, a estrutura correta da requisição poderia ser facilmente descoberta através de revisão de código ou testes manuais em uma instância local.
Na requisição abaixo, modificamos o nível de acesso para todas as seções para acesso máximo (3) e alteramos o tipo de usuário de Biblioteca para Poli-institucional (parâmetro level definido com valor 1).** Isso significa que o usuário ganharia acesso a todas as instituições registradas, não apenas àquela associada durante sua criação.
Depois disso, ao recarregar a página inicial, podemos confirmar que o usuário anteriormente sem privilégios agora possui todos os privilégios disponíveis no contexto da aplicação, concedidos arbitrariamente.
As rotas para os endpoints vulneráveis podem ser encontradas no arquivo routes/web.php.
Os métodos vulneráveis usados por essas rotas podem ser encontrados no arquivo app/Http/Controllers/AccessLevelController.php. Esses métodos não realizam verificação de permissão do usuário solicitante antes de executar as ações solicitadas nos tipos de usuário.
Este software é usado como solução de gestão escolar em diversas instituições públicas. Cada instância potencialmente contém vários tipos de informações sensíveis sobre usuários e estudantes registrados, como documentos de identificação e prontuários médicos (condições médicas). Em um cenário onde um usuário malicioso com baixos privilégios ou uma conta controlada por atacante explore esta vulnerabilidade, a confidencialidade, integridade e disponibilidade desses registros estariam em risco. Uma avaliação de segurança rápida do projeto revelaria essa fraqueza.
