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.
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.
- 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 duas funções 'user-redway' e 'user')
- A role 'user-redway' possui apenas a capability 'edit_user'.
A 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.
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:
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
- https://advisory.splunk.com/advisories/SVD-2023-0602
- https://docs.splunk.com/Documentation/Splunk/9.1.0/RESTREF/RESTaccess#authentication.2Fusers
- https://research.splunk.com/application/39e1c326-67d7-4c0d-8584-8056354f6593/
- https://dev.splunk.com/enterprise/docs/devtools/customrestendpoints