relatório cve-2024-42327
alvo: 10.129.231.176
Informacoes: Sei que meu alvo eh um servidor zabbix. Recebi uma conta de user padrão para logar no zabbix: user matthew passwd 96qzn0h2e1k3. Essa conta está com usuário padrão, sem grupos ou privilégios adicionais.
Como de costume, iniciamos com a enumeracao, vamos fazer um port scan usando o nmap.
A saída do nmap nos mostra que a porta padrão ssh e o apache2 também na porta padrão. Também temos portas 10051 e 10050 rodando algum serviço do zabbix.
Vamos acessar o zabbix colocando o ip na url do navegador e na porta http padrão, porta 80.
Essa é a tela de login do zabbix, vou logar com o user que recebi
No rodapé, encontrei a versão do zabbix:
Usando o pai dos burros, pesquisei se já tinha algum cve dessa versão do zabbix
Após um bom tempo de pesquisa, vi que essa versão é vulnerável ao CVE-2024-42327 que fala sobre uma exploração de injeção de SQL para obter dados do banco de dados e escalar privilégios e ao CVE-2024-36467 que fala que permite alterar o papel de usuário para superusuário abusando de controles de acesso ausentes.
https://nvd.nist.gov/vuln/detail/CVE-2024-36467
https://nvd.nist.gov/vuln/detail/CVE-2024-42327
Na documentação do zabbix tem ensinano como fazer solicitações HTTP para chamar a API.
https://www.zabbix.com/documentation/current/en/manual/api
Mandei a requisição chamando o appiinfo.version que ele nos ensina na documentação
o que nos retornou o seguinte:
{"jsonrpc":"2.0","result":"7.0.0","id":1}
Para o próximo teste mudei alguns parâmtros nessa resquest para mandar novamente
Em method, alterei de appinfo.version para user.login e adicionei os parâmetros username e password. Isso também vi na documentação do zabbix.
Nos retornou um token:
{"jsonrpc":"2.0","result":"9566174b00c9c3ca552abc1a52d670ba","id":1}
Depois de mais um tempo pesquisando, decidi ir no repositório do zabbix no github
https://github.com/zabbix/zabbix
Pesquisei sobre CUser e encontrei um arquivo CUser.php
Encontramos a função user.update:
public function update(array $users) {
$this->validateUpdate($users, $db_users);
self::updateForce($users, $db_users);
return ['userids' => array_column($users, 'userid')];
}
Não encontrei nenhuma verificação de autorização então decidi mudar minha função para uma função de superusuário, voltei lá na requisição e fiz os ajustes no payload
Me retornou um erro com uma mensagem de invalid params.
Dando mais uma longa analisada no código encontramos essa função
/**
* Additional check to exclude an opportunity to deactivate himself.
*
* @param array $users
* @param array $users[]['usrgrps'] (optional)
*
From this snippet, we understand that we cannot change our roles because our role is checked
from extracting our data from the API token, and verifying against the database if we are that user.
But following the code we see that usrgrps has no validation at all, and therefore can be abused
to add ourselves into multiple groups at once. As long as the group is not disabled and the group
allows GUI access we can abuse this to change our current role with the following command:
User ID 3 is matthew , User group 7 is the Zabbix administrators group and user group 13 is the
Internal group which both hold unrestrictive privileges. The response indicates that the change
was successful:
* @throws APIException
*/
private function checkHimself(array $users) {
foreach ($users as $user) {
if (bccomp($user['userid'], self::$userData['userid']) == 0) {
if (array_key_exists('roleid', $user) && $user['roleid'] !=
self::$userData['roleid']) {
self::exception(ZBX_API_ERROR_PARAMETERS, _('User cannot change
own role.'));
}
if (array_key_exists('usrgrps', $user)) {
$db_usrgrps = DB::select('usrgrp', [
'output' => ['gui_access', 'users_status'],
'usrgrpids' => zbx_objectValues($user['usrgrps'], 'usrgrpid')
]);
foreach ($db_usrgrps as $db_usrgrp) {
if ($db_usrgrp['gui_access'] == GROUP_GUI_ACCESS_DISABLED
|| $db_usrgrp['users_status'] ==
GROUP_STATUS_DISABLED) {
self::exception(ZBX_API_ERROR_PARAMETERS,
_('User cannot add himself to a disabled group or a
group with disabled GUI access.')
);
}
}
}
break;
}
}
}
De acordo com esse snippet, não podemos alterar nossas funções pq nossa função é verificada ao extrair nossos dados do token da API e verificar no banco de dados se somos esse usuário. Mas analisando o código, vemos que usrgrps não tem validação alguma e por conta dessa falta de validação, pode ser abusado para nos adicionar em vários grupos de uma vez. Não tem nenhuma verificação para impedir que um usuário adicione a si mesmo a grupos que não deveria ter acesso.
vamos tentar escalar privilégios pela falta dessa validação, editei o payload e mandei a request novamente
userid 3 refere-se ao id do user matthew usrgrps contém uma lista de IDS de grupo: 13 que é um grupo internet e 7 é o grupo zabbix administators. a nossa resposta do servidor confirma o sucesso da operação:
{"jsonrpc":"2.0","result":{"userids":["3"]},"id":1}
Agora podemos extrair os grupos de usuários do nosso usuário atual. Vamos modificar a request e mandar novamente.
Ao verificar a resposta, vemos que o usuário com ID 3 está nos grupos de administradores Interno e Zabbix.
{"jsonrpc":"2.0","result":[{"userid":"1","usrgrps":
[{"usrgrpid":"7","name":"Zabbix administrators"},
{"usrgrpid":"13","name":"Internal"}]},{"userid":"2","usrgrps":
[{"usrgrpid":"8","name":"Guests"}]},{"userid":"3","usrgrps":
[{"usrgrpid":"7","name":"Zabbix administrators"},
{"usrgrpid":"13","name":"Internal"}]}],"id":1}
Em um cenário em que um Grupo de Host válido foi atribuído ao grupo de administradores do Zabbix, eles poderão aproveitar a criação de itens para acionar a execução remota de código, o que será abordado no próximo CVE.
Analisando o código-fonte na classe CUser novamente, investigamos a função user.get na linha 68. A linha 108 contém uma verificação com o seguinte código: