En cas d’incident de sécurité, notre Force d’intervention Rapide est disponible 24h/24 et 7j/7 
En début d’année 2024, dans le cadre de la préparation d’un CTF organisé par Formind, nous souhaitions utiliser une solution cloud nommée Owncloud dans le scénario d’attaque. Les joueurs devaient exploiter une CVE connue sur cette solution, publiée plusieurs mois auparavant. Cependant, pendant la phase de tests, nous avons découvert une nouvelle vulnérabilité permettant d’obtenir un accès aux fichiers des autres utilisateurs, de récupérer leurs mots de passe en clair, et d’effectuer une élévation de privilèges dans le but de prendre le contrôle de l’instance Owncloud.
Références:
– CVE-2024-37010
– https://www.cert.ssi.gouv.fr/avis/CERTFR-2024-AVI-0753/
– https://owncloud.com/security-advisories/insecure-direct-object-reference-in-external-storage/
Owncloud permet de transformer un serveur en une solution Cloud, permettant à ses utilisateurs d’y stocker leurs fichiers, photos, calendries, contacts, … Cette solution est souvent déployée par des entreprises afin de stocker leurs données de manière souveraine.
La plateforme permet également aux utilisateurs de centraliser leurs fichiers provenant des stockages externes, comme d’un FTP ou un compte Google Drive, vers celle-ci.
C’est sur cette fonctionnalité que nous avons découvert une vulnérabilité.
Une fois que nous avons créé notre stockage externe, il est possible de mettre à jour ce formulaire pour modifier, par exemple, le champ « Folder name ». Lors de la mise à jour, une requête est envoyée avec tout le formulaire au format JSON. Dans ce formulaire, le champ ‘ID’, étant un nombre entier, est l’identifiant de notre stockage externe, généré par le serveur lorsque nous avons créé le stockage.
Imaginons qu’un autre utilisateur sur Owncloud, par exemple l’administrateur, possède-lui aussi un stockage externe, avec pour ID « 18 ».
Maintenant, nous rejouons la requête de mise à jour du formulaire en tant qu’utilisateur « normal_user », n’ayant aucun droit particulier, mais changeons l’ID par 18, le stockage externe de l’administrateur.
Une fois la requête envoyée, le serveur rencontre une erreur 404 (4), et celui-ci nous indique qu’il n’a pas trouvé de stokage avec l’ID que nous avons indiqué (5).
Cependant, lorsque l’on se connecte au compte de l’admin, voici ce que nous observons :
Le stockage de l’administrateur a bien été mis à jour.
Si nous nous reconnectons en tant qu’utilisateur « normal_user », on peut effectivement constater que nous avons désormais accès au stockage « storage_pwned », le stockage de l’administrateur.
L’utilisateur A a réussi à mettre à jour le stockage de l’utilisateur B et à récupérer le droit d’accès à celui-ci. Nous 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 permettant de mettre à jour un stockage externe.
Tout d’abord, on peut remarquer 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 effectue la requête. Cela explique donc pourquoi « normal_user » a pu mettre à jour le stockage de l’administrateur.
Ensuite, on peut constater qu’à chaque mise à jour, le code ajoute l’utilisateur qui vient de faire la requête aux utilisateurs autorisés à se connecter au stockage, expliquant donc pourquoi « normal_user » a eu, comme par magie, le droit d’accéder au stockage de l’administrateur après la mise à jour.
Dans cet exemple, nous avons vu comment il était possible pour un utilisateur de récupérer l’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, vous l’aurez compris, cette IDOR (Insecure Direct Object Reference) est déjà une belle vulnérabilité. Mais essayons de continuer à l’exploiter pour augmenter l’impact qu’elle pourrait avoir.
Pour cela, comprenons le fonctionnement du processus d’authentification effectué par le serveur Owncloud pour le stockage externe afin de récupérer les fichiers. Pour les systèmes d’authentification basiques utilisant un simple couple identifiant/mot de passe, le serveur cloud va simplement les envoyer au serveur du stockage externe afin de s’authentifier et récupérer l’accès aux fichiers.
Maintenant, imaginons qu’un attaquant parvienne à mettre à jour cette configuration en changeant l’hôte par une adresse qu’il contrôle. Cela signifie que le serveur Owncloud va désormais envoyer les identifiants à cette nouvelle adresse, qui est contrôlée par l’attaquant.
C’est exactement ce que nous pouvons faire grâce à notre vulnérabilité.
Lorsque nous rejouons la requête de mise à jour en indiquant l’ID de stockage d’un autre utilisateur, il suffit de changer l’hôte en indiquant, par exemple, notre collaborator Burp.
Ainsi, lorsque l’utilisateur se reconnecte, le serveur Owncloud tente de s’authentifier auprès de notre collaborator en lui envoyant les identifiants de l’utilisateur.
Magie, le collaborator reçoit bien la requête d’authentification du serveur Owncloud avec les identifiants encodés en Base64.
Nous venons donc de récupérer les identifiants en clair du stockage externe de l’administrateur.
Il est possible, pour l’authentification sur un stockage externe, d’utiliser ses propres identifiants Owncloud pour se connecter, dans le cas où l’on utilise le même mot de passe, par exemple. Lors de la requête de mise à jour d’un stockage externe, on peut indiquer « password::sessioncredentials » dans le champ « authMechanism ».
Le serveur Owncloud va alors sauvegarder nos identifiants en clair lors de notre prochaine connexion pour les transférer vers notre stockage externe afin de s’y authentifier.
Vous le voyez donc sûrement venir…
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.
La CVE-2024-37010 permet donc à un attaquant ayant un compte sur un serveur Owncloud: