sarpantkeltiek/cve-2024-37010Exploit para o CVE-2024-37010: acesso ao armazenamento externo de outros usuários e movimentação lateral
Exploit para CVE-2024-37010: acesso ao armazenamento externo de outros usuários & movimento lateral:
https://www.cert.ssi.gouv.fr/avis/CERTFR-2024-AVI-0753/
https://owncloud.com/security-advisories/insecure-direct-object-reference-in-external-storage
O Owncloud transforma um servidor em uma nuvem para armazenar arquivos, como o Google Drive. Isso permite que empresas, por exemplo, ofereçam uma nuvem para funcionários, sem que ela seja gerenciada por terceiros.
Se os administradores configurarem dessa forma, os usuários também podem conectar armazenamentos externos, como outras nuvens, FTP ou Google Drive, para centralizar arquivos em uma única nuvem e, assim, facilitar a vida dos usuários.
Quando criamos nosso armazenamento externo, podemos atualizar esse formulário para alterar, por exemplo, o campo "Folder name". Quando o formulário é atualizado, uma requisição é enviada com o formulário inteiro em formato JSON. Nesse formulário, o campo 'ID', por ser um inteiro, é o identificador do nosso armazenamento externo, gerado pelo servidor quando criamos o armazenamento.
Vamos imaginar que outro usuário do Owncloud, por exemplo o administrador, também tenha armazenamento externo, com ID "18".
Agora, vamos reexecutar a requisição de atualização do formulário como usuário "normal_user", sem direitos especiais, mas alterar o ID para 18, o armazenamento externo do administrador.
![[images/req.png]](images/req.png)
Quando a requisição é enviada, o servidor encontra um erro 404 (4) e nos informa que não encontrou nenhum armazenamento com o ID que especificamos (5).
No entanto, quando nos conectamos à conta de administrador, é isso que vemos:
![[pwned_article.png]](images/pwned_article.png)
O armazenamento do administrador foi atualizado.
Se fizermos login novamente como "normal_user", podemos ver que agora temos acesso a "storage_pwned", o armazenamento do administrador.
![[access.png]](images/access.png)
O usuário A conseguiu atualizar o armazenamento do usuário B e recuperar direitos de acesso a ele. Lembramos que o usuário A NÃO deve alterar o host durante a requisição de atualização, para não quebrar a configuração do usuário B e então poder acessar os arquivos deste.
Aqui está o código usado para atualizar o armazenamento externo.
![[Pasted image 20241016114714.png]](images/2.png)
Primeiramente, podemos ver que não há verificação dos direitos do usuário que acabou de fazer a requisição. O código não verifica se o armazenamento pertence ao usuário que faz a requisição. Isso explica por que "normal_user" conseguiu atualizar o armazenamento do administrador.
Em segundo lugar, podemos ver que em cada atualização, o código adiciona o usuário que acabou de fazer a requisição aos usuários autorizados a se conectar ao armazenamento, explicando assim por que "normal_user" recebeu magicamente acesso ao armazenamento do administrador após a atualização.
Neste exemplo, vimos como foi possível para um usuário obter acesso total ao armazenamento externo de outro usuário e, assim, ter acesso aos seus arquivos pessoais. Isso já torna essa uma vulnerabilidade bastante crítica.
Nesta fase, como você pode ver, esse IDOR (Insecure Direct Object Reference) já é uma vulnerabilidade grave. Mas vamos tentar continuar explorando-o para aumentar o impacto que poderia ter.
Para isso, vamos entender o processo de autenticação realizado pelo servidor Owncloud para armazenamento externo, a fim de recuperar arquivos. Para sistemas de autenticação básicos que usam um simples par login/senha, o servidor de nuvem simplesmente
![[Pasted image 20241017162909.png]](images/20241017162909.png)
Agora, vamos imaginar que um atacante consiga atualizar essa configuração alterando o host para um endereço que ele controla. Isso significa que o servidor Owncloud passará a enviar credenciais para esse novo endereço, que é controlado pelo atacante.
![[Pasted image 20241017163143.png]](images/20241017163143.png)
Isso é exatamente o que podemos fazer graças à nossa vulnerabilidade.
Quando repetimos a requisição de atualização especificando o ID do armazenamento de outro usuário, tudo o que precisamos fazer é alterar o host, especificando, por exemplo, nosso colaborador Burp.
![[Pasted image 20241017163326.png]](images/20241017163326.png)
Dessa forma, quando o usuário se reconectar, o servidor Owncloud tentará se autenticar em nosso colaborador, enviando as credenciais do usuário.
![[Pasted image 20241017163644.png]](images/20241017163644.png)
Magicamente, o colaborador recebe a requisição de autenticação do servidor Owncloud com as credenciais codificadas em Base64.
![[Pasted image 20241017163945.png]](images/20241017163945.png)
Acabamos de recuperar as credenciais em texto claro do armazenamento externo do administrador.
Para autenticação em armazenamento externo, você pode usar suas próprias credenciais do Owncloud para fazer login, se usar a mesma senha, por exemplo. Ao solicitar uma atualização de armazenamento externo, você pode especificar "password::sessioncredentials" no campo "authMechanism".
O servidor Owncloud salvará então nossas credenciais em texto claro na próxima conexão e as transferirá para nosso dispositivo de armazenamento externo para autenticação.
Então você já deve estar imaginando...
Isso significa que um atacante também pode ativar esse mecanismo para o armazenamento externo de outro usuário e, assim, transferir as credenciais em texto claro da sessão Owncloud da vítima para um host que ele controla, como acabamos de fazer.
O CVE-2024-37010 permite, portanto, que um atacante com uma conta em um servidor Owncloud:
