
Ein Proof of Concept für die Ausnutzung des CVE-2021-46398-Fehlers
In diesem Repository finden Sie einen Proof of Concept zur Ausnutzung des CVE-2021-46398-Fehlers mittels Docker Compose sowie eine Analyse der Auswirkungen dieses Fehlers auf Informationssysteme.
# 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
Laut der FileBrowser-Website ist FileBrowser eine beliebte Cloud-Software zum Selberbauen, die Sie auf einem Server installieren können, auf ein Verzeichnis verweisen und dann über eine schöne Weboberfläche auf Ihre Dateien zugreifen können. Sie wurde in der Sprache Go entwickelt und bietet viele Funktionen. Es ist ein bisschen wie Google Drive, nur dass jeder seine eigene Instanz besitzen und hosten kann.
FileBrowser-Administratoren können mehrere Benutzer erstellen, sogar einen weiteren Administrator-Benutzer mit erweiterten Rechten, und jedem Benutzer Zugriff auf beliebige Verzeichnisse gewähren. Die Benutzererstellung wird über einen Endpunkt abgewickelt. Der Endpunkt akzeptiert Eingaben im -Format zur Erstellung von Benutzern, überprüft jedoch nicht den --Header, der sein sollte, sondern akzeptiert auch ; und hier liegt die Schwachstelle. Außerdem wird der nicht validiert und es gibt auch keine Anti--Tokens. Daher kann ein Angreifer diese Schwachstelle leicht ausnutzen, um einen Hintertür-Benutzer mit Administratorrechten und Zugriff auf das Home-Verzeichnis oder ein beliebiges anderes Verzeichnis zu erstellen, indem er einfach eine schädliche Webseiten-URL an den legitimen Administrator sendet und so auf das gesamte Dateisystem des Servers zugreift (weitere Erläuterung dieses Prozesses im Demonstrationsabschnitt).
/api/usersContent-Typeapplication/jsontext/plainOriginDarüber hinaus kann ein Administrator Befehle auf dem System ausführen, sodass diese Schwachstelle zu einer RCE führt.
Hier ist ein Sequenzdiagramm, das den Angriffsprozess zusammenfasst (Alice ist der Hacker und Bob der Administrator und Host der FileBrowser-Instanz):
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*Ziel dieser Demonstration ist es, eine Mini-Architektur aus zwei/drei Maschinen aufzubauen:
Es ist eine wirklich vereinfachte Architektur, deren Ziel es ist, den technischen Aspekt des Fehlers hervorzuheben.
Für dieses Experiment benötigen Sie nur docker.
In diesem Setup basiert die Zielmaschine auf einem FileBrowser v2.17.2-Image (das für diesen Fehler anfällig ist), in dem das einzige FileBrowser-Konto das Administratorkonto mit admin/admin als Login/Passwort ist.
Starten der Zielmaschine:
mkdir srv && docker compose up
Auf der Angreiferseite ermöglicht uns die schädliche Webseite, den FileBrowser-API-Aufruf auszuführen und unseren Hintertür-Benutzer vom Computer des Administrators aus zu erstellen.
Ein Beispiel für eine solche Seite wird in diesem Repository unter dem Namen index.html bereitgestellt. Es ist eine einfache HTML-Seite mit einem versteckten Formular, das eine POST-Anfrage an den /api/users-Endpunkt von FileBrowser sendet, wobei die Nutzlast im Eingabefeld name steckt. Diese Nutzlast erstellt einen Administrator-Benutzer mit dem Login "oui" und dem Passwort "oui", und wird ausgelöst, wenn der Button geklickt wird.
Wir hätten natürlich eine schönere und attraktivere Seite als diese erstellen und das Senden der HTTP-Anfrage in einem anderen Element der Website verstecken können; es dient nur dazu, den technischen Aspekt der Ausnutzung des Fehlers zu zeigen. Denken Sie daran, dass das Ziel dieser schädlichen Webseite darin besteht, vom FileBrowser-Administrator geöffnet zu werden, ohne dass dieser etwas ahnt!
Auf der Administratorseite erledigen wir ruhig Verwaltungsaufgaben auf FileBrowser. Gehen Sie zu 127.0.0.1:8080 und melden Sie sich mit den Admin-Anmeldedaten admin/admin an.
Dann erhalten wir die schädliche Webseite auf irgendeinem Weg, zum Beispiel in einer Phishing-E-Mail, und führen die Aktion aus, die den Exploit auslöst. Öffnen Sie die index.html-Webseite und klicken Sie auf den Button; die Nutzlast wird gestartet.
Nun, zurück zur Angreiferseite: Wir haben jetzt einen Hintertür-Benutzer mit Administratorrechten auf dem FileBrowser-Server.
Öffnen Sie Ihren bevorzugten Webbrowser im privaten Modus, um sicherzustellen, dass Sie keine Authentifizierungsmittel des Administrators verwenden. Gehen Sie zu localhost:8080 und melden Sie sich mit den Anmeldedaten des Hintertür-Benutzers oui/oui an.
Glückwunsch! Sie haben jetzt Zugriff auf das Dateisystem des FileBrowser-Servers und somit auf alle Dateien der Server-Benutzer!
Und weil FileBrowser eine großartige Plattform mit vielen Funktionen ist, können Sie eine Terminal-Instanz starten, indem Sie den "toggle shell"-Button drücken... Versuchen Sie, whoami einzugeben, und machen Sie dann, was immer Sie als root möchten :)
Damit der Hintertür-Benutzer Shell-Befehle verwenden kann, müssen diese explizit in der Nutzlast deklariert werden. Sehen Sie sich
index.htmlan, um Ihre hinzuzufügen!
Der Fehler wurde ab Version v2.18.0 behoben. Die Informationen dazu sind auf ihrem GitHub verfügbar. Der Patch war nicht sehr aufwändig zu implementieren, da nur 6 Codezeilen in einer einzigen Programmdatei geändert werden mussten. Da die Schwachstelle aus dem Parsing-Fehler resultierte (vgl. Fehlerbeschreibung), reichte es aus, sicherzustellen, dass jede Anfrage in das Format application/json geparst wird, bevor sie für irgendetwas anderes verarbeitet wird.
Diese Arbeit wurde im Rahmen des Kurses zur Informationssystemsicherheit durchgeführt, der im letzten Jahr der Spezialisierung Informationssystemtechnik an der Grenoble INP - Ensimag, UGA, gehalten wird.