sarpantkeltiek/cve-2024-37010Exploit pour la CVE-2024-37010 : accéder au stockage externe d'un autre utilisateur et mouvement latéral
Exploit pour la CVE-2024-37010 : accéder au stockage externe d'un autre utilisateur & mouvement latéral :
https://www.cert.ssi.gouv.fr/avis/CERTFR-2024-AVI-0753/
https://owncloud.com/security-advisories/insecure-direct-object-reference-in-external-storage
Owncloud transforme un serveur en un cloud pour stocker des fichiers, à l'instar de Google Drive. Cela permet par exemple aux entreprises de fournir un cloud à leurs employés, sans qu'il soit géré par un tiers.
Si les administrateurs l'ont configuré de cette manière, les utilisateurs peuvent également connecter des stockages externes, tels que d'autres clouds, FTP ou Google Drive, afin de centraliser les fichiers sur un seul cloud et ainsi faciliter la vie des utilisateurs.
Une fois notre stockage externe créé, nous pouvons mettre à jour ce formulaire pour modifier, par exemple, le champ « Nom du dossier ». Lorsque le formulaire est mis à jour, une requête est envoyée avec l'intégralité du formulaire au format JSON. Dans ce formulaire, le champ « ID », étant un entier, est l'identifiant de notre stockage externe, généré par le serveur lors de la création du stockage.
Imaginons qu'un autre utilisateur d'Owncloud, par exemple l'administrateur, possède également un stockage externe, avec l'ID « 18 ».
Maintenant, rejouons la requête de mise à jour du formulaire en tant qu'utilisateur « normal_user », sans droits particuliers, mais en changeant l'ID en 18, le stockage externe de l'administrateur.
![[images/req.png]](images/req.png)
Une fois la requête envoyée, le serveur rencontre une erreur 404 (4) et nous indique qu'il n'a trouvé aucun stockage avec l'ID que nous avons spécifié (5).
Cependant, lorsque nous nous connectons au compte administrateur, voici ce que nous voyons :
![[pwned_article.png]](images/pwned_article.png)
Le stockage de l'administrateur a été mis à jour.
Si nous nous reconnectons en tant que « normal_user », nous pouvons constater que nous avons désormais accès à « storage_pwned », le stockage de l'administrateur.
![[access.png]](images/access.png)
L'utilisateur A est parvenu à mettre à jour le stockage de l'utilisateur B et à récupérer les droits d'accès à celui-ci. Rappelons que l'utilisateur A ne doit PAS modifier l'hôte lors de la requête de mise à jour, afin de ne pas casser la configuration de l'utilisateur B et de pouvoir ensuite accéder aux fichiers de ce dernier.
Voici le code utilisé pour mettre à jour le stockage externe.
![[Pasted image 20241016114714.png]](images/2.png)
Tout d'abord, on constate qu'il n'y a aucune vérification des droits de l'utilisateur qui vient d'effectuer la requête. Le code ne vérifie pas que le stockage appartient à l'utilisateur qui fait la requête. Cela explique pourquoi « normal_user » a pu mettre à jour le stockage de l'administrateur.
Deuxièmement, on constate qu'à chaque mise à jour, le code ajoute l'utilisateur qui vient d'effectuer la requête aux utilisateurs autorisés à se connecter au stockage, ce qui explique pourquoi « normal_user » s'est vu magiquement accorder l'accès au stockage de l'administrateur après la mise à jour.
Dans cet exemple, nous avons vu comment il était possible pour un utilisateur d'obtenir un accès complet au stockage externe d'un autre utilisateur et ainsi d'accéder à ses fichiers personnels. Cela en fait déjà une vulnérabilité assez critique.
À ce stade, comme vous pouvez le constater, cet IDOR (Insecure Direct Object Reference) est déjà une vulnérabilité majeure. Mais essayons de continuer à l'exploiter pour augmenter l'impact qu'il pourrait avoir.
Pour ce faire, comprenons le processus d'authentification effectué par le serveur Owncloud pour les stockages externes afin de récupérer les fichiers. Pour les systèmes d'authentification de base utilisant un simple couple identifiant/mot de passe, le serveur cloud va simplement
![[Pasted image 20241017162909.png]](images/20241017162909.png)
Imaginons maintenant qu'un attaquant parvienne à mettre à jour cette configuration en changeant l'hôte vers une adresse qu'il contrôle. Cela signifie que le serveur Owncloud enverra désormais les identifiants à cette nouvelle adresse, contrôlée par l'attaquant.
![[Pasted image 20241017163143.png]](images/20241017163143.png)
C'est exactement ce que nous pouvons faire grâce à notre vulnérabilité.
Lorsque nous rejouons la requête de mise à jour en spécifiant l'ID du stockage d'un autre utilisateur, il suffit de changer l'hôte en spécifiant, par exemple, notre collaborateur Burp.
![[Pasted image 20241017163326.png]](images/20241017163326.png)
Ainsi, lorsque l'utilisateur se reconnecte, le serveur Owncloud tente de s'authentifier auprès de notre collaborateur en lui envoyant les identifiants de l'utilisateur.
![[Pasted image 20241017163644.png]](images/20241017163644.png)
Magiquement, le collaborateur reçoit la requête d'authentification du serveur Owncloud avec les identifiants encodés en Base64.
![[Pasted image 20241017163945.png]](images/20241017163945.png)
Nous venons donc de récupérer les identifiants en clair du stockage externe de l'administrateur.
Pour l'authentification sur un stockage externe, vous pouvez utiliser vos propres identifiants Owncloud pour vous connecter, si vous utilisez le même mot de passe, par exemple. Lors d'une demande de mise à jour de stockage externe, vous pouvez spécifier « password::sessioncredentials » dans le champ « authMechanism ».
Le serveur Owncloud enregistrera alors nos identifiants en clair lors de la prochaine connexion, et les transférera à notre stockage externe pour l'authentification.
Vous voyez donc où cela mène...
Cela signifie qu'un attaquant peut également activer ce mécanisme pour le stockage externe d'un autre utilisateur et ainsi transférer les identifiants en clair de la session Owncloud de la victime vers un hôte qu'il contrôle, comme nous venons de le faire.
CVE-2024-37010 permet donc à un attaquant disposant d'un compte sur un serveur Owncloud :
