Resumo
Um atacante possuindo apenas privilégios mínimos de visualização na seção de configurações é capaz de alterar seu tipo de usuário para Administrador (ou para outro tipo com super-permissões).
Detalhes
Qualquer usuário, que seja de algum tipo de usuário que possua pelo menos permissão de visualização de configurações de tipos de usuário é capaz de alterar o seu próprio nível para tornar-se administrador. Um exemplo de tipo de usuário com permissionamento reduzido seria:
PoC
Para exploração dessa vulnerabilidade, consideremos o tipo de usuário Non-perm (que possui, unica e exclusivamente, a permissão especificada na imagem na seção de Detalhes acima):
Consideremos, também, que exista o usuário sem privilégios cuja matrícula seja pwnuser (repare o tipo de usuário):
Podemos verificar o baixo permissionamento do usuário pwnuser ao logarmos na dashboard (note o cookie de sessão utilizado):
Após isso, podemos realizar uma requisição POST para o arquivo ieducar/intranet/educar_usuario_cad.php especificando o parâmetro nivel_usuario_ para o ID de algum tipo de usuário específico (no nosso caso, o tipo de usuário Administrador possui ID 1):
Dessa forma, o usuário pwnuser torna-se do tipo Administrador, obtendo todos os privilégios (note que o cookie de sessão permaneceu inalterado, provando que continuamos com o mesmo usuário):
Impacto
Qualquer usuário é capaz de tornar-se administrador, o que pode levar à roubo de contas, alteração de tarefas administrativas, etc.
Mitigação
A falha ocorre no arquivo localizado em ieducar/intranet/educar_usuario_cad.php na linha 446, que não realiza as verificações sobre o nível de permissionamento atual do usuário para realizar alterações. O método Editar da classe clsCadastro verifica se o usuário tem permissão para realizar a edição:
Observando o método canChange, é possível concluir que a alteração só acontece em três cenários:
- Se o usuário que estiver realizando a alteração for admin
- Se o usuário que estiver sendo alterado não existir
- Se o usuário que estiver sendo alterado NÃO for admin
Portanto, é necessário que uma validação mais robusta seja implementada, garantindo que o usuário não possa alterar seu nível, exceto se possuir a permissão de fato.
0xbhsu Reporter
Resumo
Um atacante possuindo apenas privilégios mínimos de visualização na seção de configurações é capaz de alterar seu tipo de usuário para Administrador (ou para outro tipo com super-permissões).
Detalhes
Qualquer usuário, que seja de algum tipo de usuário que possua pelo menos permissão de visualização de configurações de tipos de usuário é capaz de alterar o seu próprio nível para tornar-se administrador. Um exemplo de tipo de usuário com permissionamento reduzido seria:
PoC
Para exploração dessa vulnerabilidade, consideremos o tipo de usuário Non-perm (que possui, unica e exclusivamente, a permissão especificada na imagem na seção de Detalhes acima):
Consideremos, também, que exista o usuário sem privilégios cuja matrícula seja pwnuser (repare o tipo de usuário):
Podemos verificar o baixo permissionamento do usuário pwnuser ao logarmos na dashboard (note o cookie de sessão utilizado):
Após isso, podemos realizar uma requisição POST para o arquivo ieducar/intranet/educar_usuario_cad.php especificando o parâmetro nivel_usuario_ para o ID de algum tipo de usuário específico (no nosso caso, o tipo de usuário Administrador possui ID 1):
Dessa forma, o usuário pwnuser torna-se do tipo Administrador, obtendo todos os privilégios (note que o cookie de sessão permaneceu inalterado, provando que continuamos com o mesmo usuário):
Impacto
Qualquer usuário é capaz de tornar-se administrador, o que pode levar à roubo de contas, alteração de tarefas administrativas, etc.
Mitigação
A falha ocorre no arquivo localizado em ieducar/intranet/educar_usuario_cad.php na linha 446, que não realiza as verificações sobre o nível de permissionamento atual do usuário para realizar alterações. O método Editar da classe clsCadastro verifica se o usuário tem permissão para realizar a edição:
Observando o método canChange, é possível concluir que a alteração só acontece em três cenários:
Portanto, é necessário que uma validação mais robusta seja implementada, garantindo que o usuário não possa alterar seu nível, exceto se possuir a permissão de fato.