laliea/cve-2021-46398Une preuve de concept pour l'exploitation de la faille CVE-2021-46398
Dans ce dépôt, vous trouverez une preuve de concept de l'exploitation de la faille CVE-2021-46398 via un docker compose, ainsi qu'une analyse des impacts de cette faille sur les systèmes d'information.
# Exploit Title: FileBrowser 2.17.2 - Cross Site Request Forgery (CSRF) to Remote Code Execution (RCE)
# Date: 05/02/2022
# Exploit Author: FEBIN MON SAJI
# Vendor Homepage: https://filebrowser.org/
# Software Link: https://github.com/filebrowser/filebrowser
# Version:
FileBrowser <= 2.17.2
# Tested on: Ubuntu 20.04
# CVE : CVE-2021-46398
Selon le site web de FileBrowser, FileBrowser est un logiciel populaire de type "créez votre propre cloud" que vous pouvez installer sur un serveur, le diriger vers un chemin et ensuite accéder à vos fichiers via une belle interface web développée en langage Go, avec de nombreuses fonctionnalités. C'est un peu comme Google Drive, sauf que chacun peut posséder et héberger sa propre instance.
Les administrateurs de FileBrowser peuvent créer plusieurs utilisateurs, même un autre utilisateur privilégié administrateur, et donner accès à n'importe quel répertoire qu'il souhaite. La création d'utilisateur est gérée par un endpoint . L'endpoint accepte les entrées au format pour créer des utilisateurs, mais ne vérifie pas l'en-tête dont la valeur devrait être , mais accepte ; et c'est là que réside la vulnérabilité. De plus, l'en-tête n'est pas validé et aucun token anti- n'est implémenté. Par conséquent, un attaquant peut facilement exploiter cette vulnérabilité pour créer un utilisateur backdoor avec des privilèges administrateur et un accès au répertoire personnel ou à tout répertoire auquel l'attaquant veut accéder, simplement en envoyant une URL de page web malveillante à l'administrateur légitime et accéder à l'ensemble du système de fichiers du serveur (plus d'explications sur ce processus dans la section démonstration).
/api/usersContent-Typeapplication/jsontext/plainOriginDe plus, un administrateur peut exécuter des commandes sur le système, donc cette vulnérabilité mène à une RCE.
Voici un diagramme de séquence qui résume le processus d'attaque (Alice étant le pirate et Bob l'administrateur et hôte de l'instance FileBrowser) :
sequenceDiagram
Alice (hacker) ->> Alice (hacker): *Maliciously creates the malicious HTML page*
Alice (hacker) ->> Bob (admin): Here is a cool page! You must check that bro!
Bob (admin) ->> Alice (hacker): Thanks dude, let's open that!
Bob (admin) ->> Bob (admin): *Opens the page thinking it's something cool*
Bob (admin) -->> FileBrowser: *Sends a request to create a user without knowing it*
FileBrowser -->> FileBrowser: *Creates a new admin privileged user as requested*
Alice (hacker) ->> FileBrowser: Eheheh Bob is so dumb! *Connect to FileBrowser with the backdoor user*
FileBrowser ->> Alice (hacker): *Accept Alice connection with the new user created*
Alice (hacker) ->> FileBrowser: *Request shell access to FileBrowser with the appropriate button then makes sytem calls on Bob's computer*Le but de cette démonstration est de mettre en place une mini-architecture composée de deux/trois machines :
C'est une architecture vraiment simplifiée dont le but est de mettre en évidence l'aspect technique de la faille.
Pour cette expérience, vous aurez seulement besoin de docker.
Dans cette configuration, la machine cible est basée sur une image FileBrowser v2.17.2 (qui est vulnérable à cette faille), dans laquelle le seul compte FileBrowser est le compte administrateur qui a admin/admin comme identifiant/mot de passe.
Lancement de la machine cible :
mkdir srv && docker compose up
Du côté de l'attaquant, la page web malveillante nous permettra d'exécuter l'appel API FileBrowser et de créer notre utilisateur backdoor depuis l'ordinateur de l'administrateur.
Un exemple d'une telle page est fourni dans ce dépôt sous le nom index.html. Il s'agit d'une simple page HTML avec un formulaire caché qui effectue une requête POST vers l'endpoint /api/users de FileBrowser avec la charge utile dans le nom de l'entrée. Cette charge utile crée un utilisateur privilégié administrateur dont l'identifiant est "oui" et le mot de passe "oui", et est déclenchée lorsque le bouton est cliqué.
Nous aurions évidemment pu créer une page plus jolie et plus attrayante que celle-ci et cacher l'envoi de la requête HTTP dans un autre élément du site web, c'est juste pour que vous puissiez voir l'aspect technique de l'exploitation de la faille. Rappelez-vous que le but de cette page web malveillante est d'être ouverte par l'administrateur de FileBrowser sans qu'il ne soupçonne rien !
Du côté de l'administrateur, nous faisons tranquillement des trucs d'admin sur FileBrowser. Allez sur 127.0.0.1:8080 et connectez-vous avec les identifiants administrateur admin/admin.
Ensuite, nous recevons la page web malveillante par quelque moyen que ce soit, comme dans un email de phishing, et effectuons l'action qui déclenche l'exploit. Ouvrez la page web index.html et cliquez sur le bouton ; cela lance la charge utile.
Maintenant, retour du côté de l'attaquant, nous avons maintenant un utilisateur backdoor avec privilèges administrateur sur le serveur FileBrowser.
Ouvrez votre navigateur web préféré en navigation privée pour vous assurer que vous n'utilisez aucun des moyens d'authentification de l'administrateur. Allez sur localhost:8080 et connectez-vous avec les identifiants de l'utilisateur backdoor oui/oui.
Félicitations ! Vous avez maintenant accès au système de fichiers du serveur FileBrowser et donc à tous les fichiers des utilisateurs du serveur !
Et parce que FileBrowser est une excellente plateforme avec de nombreuses fonctionnalités, vous pouvez lancer une instance de terminal en appuyant sur le bouton "toggle shell"... essayez de taper whoami, et faites ce que vous voulez en tant que root :)
Pour permettre à l'utilisateur backdoor d'utiliser des commandes shell, celles-ci doivent être explicitement déclarées dans la charge utile. Voir
index.htmlpour ajouter les vôtres !
La faille a été corrigée à partir de la version v2.18.0. Les informations à ce sujet sont disponibles sur leur GitHub. Le correctif n'a pas été très coûteux à déployer car il n'a nécessité que la modification de 6 lignes de code dans un seul fichier de programme. Étant donné que la vulnérabilité provenait de l'échec de l'analyse (cf. description de la faille), il suffisait de s'assurer que toute requête était analysée au format application/json avant d'être traitée pour autre chose.
Ce travail a été réalisé dans le cadre du cours de Sécurité des Systèmes d'Information donné en dernière année de la spécialisation Ingénierie des Systèmes d'Information à Grenoble INP - Ensimag, UGA.