CVE-2023-32707
Alta
| Produto | Splunk Enterprise < 9.0.5 (e Cloud correspondente) |
| Classe | Escalação de privilégios (capability edit_user) |
| Vetor | Rede · autenticado (usuário com edit_user) |
| Correção | Atualizar para 9.0.5 / 9.1.1 |
De acordo com o alerta publicado pela Splunk, a vulnerabilidade catalogada como CVE-2023-32707 viabiliza a escalação de privilégios no Splunk Enterprise. A descrição afirma que: Um usuário com privilégios baixos, que possui uma role com a capability edit_user atribuída, pode elevar seus privilégios para os de um usuário administrador através de uma requisição web maliciosamente elaborada.
Desta forma, de modo a compreender melhor a capability edit_user, realizamos uma leitura na documentação e identificamos a seguinte descrição:
Permite ao usuário criar, editar ou remover usuários. Uma role com a capability edit_user pode atribuir qualquer role a outros usuários. Para limitar essa capacidade, configure grantableRoles no arquivo authorize.conf. Por exemplo: grantableRoles = role1;role2;role3.
Em posse dessas informações, criamos uma ambiente de testes com as seguintes características:
- Um container Docker executando o Splunk Enterprise 9.0.4;
- Dois usuários:
admin — usuário padrão com a função admin;redway — usuário com as funções user-redway e user;
- A role
user-redway possui apenas a capability edit_user.
Análise
De acordo com o alerta, o problema ocorre porque a capability edit_user não respeita a configuração grantableRoles no arquivo de configuração authorize.conf, viabilizando que a escalação aconteça.
Nossa compreensão dessa declaração foi que, ao não respeitar a configuração grantableRoles, o usuário com a capability edit_user poderia adicionar uma role superior à sua própria.
Nossa primeira ideia foi adicionar a role admin ao nosso próprio usuário, ignorando a configuração grantableRoles.
Mas isso não funcionou; não poderia ser tão fácil (mas acabou sendo).
Como podemos ver na imagem anterior, a configuração grantableRoles estava funcionando como esperado.
Ainda de acordo com a documentação, mesmo que um usuário possua a capability edit_user, a configuração grantableRoles é projetada para restringir sua capacidade de adicionar uma role à sua própria conta de usuário ou de outro usuário, a menos que essa role esteja explicitamente listada na configuração grantableRoles.
Como podemos verificar na imagem abaixo, a configuração supracitada está definida como user-redway, o que significa que o usuário 'redway' só pode adicionar a role user-redway a outros usuários. Outro ponto importante que também podemos identificar na imagem, é que a role user-redway possui apenas a capability edit_user.
O próximo passo foi baixar a versão corrigida do Splunk (9.0.5) e começar a comparar os arquivos de configuração para identificar mudanças. Percebemos que nesta versão o arquivo authorize.conf recebeu uma nova capability, a 'edit_user_seed'.
Imediatamente fomos verificar a documentação para entender o que essa nova capability faz.
O arquivo user-seed.conf é usado para recuperar as credenciais do administrador criadas durante a instalação. No entanto, para que o arquivo seja consumido e a nova credencial seja criada, o arquivo passwd no diretório $SPLUNK_HOME/etc/ deve ser removido e o serviço Splunk reiniciado.
Ainda examinando as diferenças entre os arquivos de configuração de uma versão vulnerável e uma versão corrigida, observamos algumas alterações no arquivo 'restmap.conf', que é utilizado para configurar os recursos da API REST.
Isso reforçou nossas suspeitas de que a vulnerabilidade seria explorável ao fornecer requisições HTTP especialmente elaboradas, portanto, os requisitos para a exploração seriam menores.
Com isso em mente, voltamos a testar nosso usuário com a capacidade edit_user e vimos o que poderíamos fazer com ele. E percebemos que tal usuário não poderia listar as roles de outros usuários, exceto aqueles com a mesma role.
Analisando a solicitação e a resposta HTTP, conseguimos entender o motivo. Vemos uma solicitação REST para o recurso '/roles' e a resposta deixa claro que o usuário não tem permissão para listar as capabilities do usuário administrador. Para fazer isso, o usuário precisaria da capacidade 'edit_roles' no mínimo.
Isso ocorre porque as verificações das capabilities são validadas por recurso/caminho e métodos HTTP. Nesse caso, o caminho é '/roles/', e nosso usuário não tem direitos sob tal recurso.
É por isso também que não podemos adicionar nenhuma capacidade à role do nosso usuário.
No entanto, a capability edit_user nos da permissões sobre o recurso '/users/'. Então percebemos que poderíamos subverter essa restrição mencionada anteriormente e listar as capabilities do usuário administrador (ou de qualquer outro usuário), o que não temos direitos sob o caminho '/roles/'.
Neste ponto, conseguimos listar as capabilities do usuário administrador, mas ainda não conseguimos adicionar nenhuma capability à role do nosso usuário para escalar nossos privilégios.
Ao analisarmos a regra que a Splunk forneceu para monitorar tentativas de exploração dessa vulnerabilidade, percebemos que tal regra foi construída para monitorar alterações de senhas, e isso chamou nossa atenção.
Capabilities da role de baixo privilégio (user-redway) e os recursos que ela alcança.
Foi ai que percebemos que não precisamos adicionar nenhuma capability à role do nosso usuário, mas poderiamos assumir o controle da conta de administrador simplesmente alterando a senha do usuário administrador (ou qualquer outro usuário). Nesse caso a escalação de privilégios acontece através do sequestro da conta de administrador (account take over).
Um conta de usuário com a capability edit_user, pode assumir o controle da conta de administrador alterando a senha do usuário administrador!
Para alterar a senha do usuário administrador basta enviar uma solicitação POST da seguinte forma:
Requisição POST que redefine a senha do administrador usando a capability edit_user.
Criamos um PoC para assumir a conta de administrador, mas antes disso, ele realiza verificações adicionais para evitar acionar um alerta conforme sugerido pela Splunk para monitorar essa vulnerabilidade. O script está disponível aqui.
Mitigações e Soluções Alternativas
Um bom ponto de partida é verificar se algum usuário possui a capacidade edit_user atribuída a ele. Isso pode ser feito facilmente executando a seguinte consulta de pesquisa:
Em seguida, avalie se o usuário com a capacidade edit_user deve realmente tê-la. Se não, remova a capability da role desse usuário.
De acordo com o alerta do fornecedor, "Confirme que nenhuma função, exceto a função de administrador ou equivalente, tenha a capacidade edit_user atribuída a ela. Confirme que você não atribui a capacidade edit_user a uma função da qual outras funções herdam, nem atribui uma função com a capacidade a um usuário com baixos ou nenhum privilégio."
Por fim, faça a atualização para a versão mais recente sem vulnerabilidades o mais rápido possível.
Referências
