3 Arten von Directory-Traversal-Schwachstellen in C/C++

Directory-Traversal-Schwachstellen (auch als Path-Traversal-Schwachstellen bezeichnet) ermöglichen es Angreifern, auf Verzeichnisse zuzugreifen, für die sie keine Berechtigung haben. In diesem Beitrag erfahren Sie, wie Directory-Traversal-Schwachstellen auf Webservern mit C/C++ funktionieren und wie Sie sie verhindern können.

Für unser Security-Research-Team waren die C- und C++-Ökosysteme lange Zeit nicht im Fokus. Das änderte sich, als FossID zu Snyk kam. FossID war auf C/C++ spezialisiert. Dadurch konnten wir mehrere Projekte starten, um den allgemeinen Informationssicherheitsstatus dieser Programmiersprachen besser zu verstehen. Dabei entdeckten wir zahlreiche Schwachstellen mit hohem Schweregrad und freuen uns, unsere Erkenntnisse nun mit Ihnen zu teilen.

In diesem Beitrag konzentrieren wir uns auf die unsachgemäße Beschränkung eines Pfadnamens auf ein eingeschränktes Verzeichnis (CWE-22). Diese Schwachstelle tritt in vielen Varianten auf und wird laut den 25 gefährlichsten Softwareschwachstellen nach CWE auch 2022 weiterhin weit verbreitet und gefährlich sein. Wir untersuchen drei verschiedene Arten von Directory-Traversal-Schwachstellen und zeigen dazu anfällige Codebeispiele, Fehlerbehebungen und mögliche Auswirkungen.

Beliebiges Lesen von Dateien

Webserver stellen häufig statische Ressourcen wie HTML-, CSS- und JS-Dateien bereit. Diese Ressourcen befinden sich in der Regel in speziellen Ordnern (z. B. /static, /www oder /assets) im Dateisystem. Eine Schwachstelle, die das beliebige Lesen von Dateien ermöglicht, entsteht, wenn die Webanwendung den Pfad zur statischen Datei nicht korrekt bereinigt. Dadurch können Benutzer „../“-Pfadsegmente verwenden, um das vorgesehene Verzeichnis zu verlassen und schließlich beliebige Dateien auf dem Datenträger auszulesen.

Sehen wir uns direkt ein Beispiel für diese Schwachstelle an, die wir kürzlich entdeckt haben – im Crow-Webframework. Crow ist ein C++-Microframework zum Betreiben von Webdiensten.

Für dieses Beispiel erstellen wir eine einfache „Hello World“-Anwendung, die aus einer einzigen Datei main.cpp besteht:

1#define CROW_MAIN
2#include <crow_all.h>
3
4int main()
5{
6    crow::SimpleApp app;
7
8    CROW_ROUTE(app, "/")
9    ([]() {
10        return "Hello world!";
11    });
12
13    app.port(8000).run();
14    return 0;
15}

Zum Kompilieren des Beispiels verwenden wir Ubuntu: g++ -pthread -o server main.cpp. Anschließend können Sie den Server ausführen, indem Sie im Terminal ./server aufrufen.

Laut Dokumentation stellt Crow standardmäßig statische Dateien aus dem Ordner /static bereit, der sich am selben Speicherort wie die ausführbare Datei server befindet. Das lässt sich testen, indem Sie den Ordner /static und darin eine Textdatei erstellen: mkdir static && echo “test” > static/test.txt

Öffnen Sie nun ein weiteres Terminalfenster und führen Sie curl aus, um zu prüfen, ob es funktioniert:

curl http://localhost:8000/ gibt Hello world! als Antwort zurück.

curl http://localhost:8000/static/test.txt gibt test zurück – tatsächlich der Inhalt der Datei static/test.txt.

Um die Schwachstelle auszunutzen, können wir curl --path-as-is "http://localhost:8000/static/../../etc/passwd" ausführen. In der Antwort sehen wir den Inhalt der Datei /etc/passwd. Entscheidend ist hier das Flag --path-as-is. Es deaktiviert die Pfadnormalisierung in URLs. Das bedeutet, dass der Server genau die von uns angegebene URL empfängt – einschließlich der „../“-Segmente.

Auswirkungen auf die Sicherheit

Das Offenlegen beliebiger Dateien auf einem Produktionsserver ist in der Regel ein kritisches Problem: SSH-Schlüssel, verschiedene Zugangsdaten und der Quellcode des Servers können Angreifern ermöglichen, den Angriff auszuweiten und den Server oder vertrauliche Nutzerdaten zu übernehmen.

Dasselbe gilt für eingebettete Geräte, auf denen besonders häufig C++-Server zum Einsatz kommen. Diese Directory-Traversal-Schwachstelle tritt oft in WLAN-Routern auf, etwa von NETGEAR, Belkin, TP-Link und anderen Herstellern. Mögliche Folgen sind in diesem Fall der Diebstahl der Zugangsdaten zum Admin-Panel und die vollständige Übernahme des lokalen Netzwerks.

In manchen Fällen kann eine Directory-Traversal-Schwachstelle selbst dann gefährlich sein, wenn der anfällige Server lokal auf Ihrem Rechner läuft. Lokale Webserver werden häufig in hybriden Web- und Desktop-Anwendungen wie Electron verwendet. Weitere Informationen zu solchen Angriffsvektoren finden Sie in unserer Untersuchung zu anfälligen VS-Code-Plugins.

Abhilfe

Crow v0.3+4 hat diese Directory-Traversal-Schwachstelle behoben. Das Problem wurde über die Datei app.h eingeführt: Dort fügt der Code einfach einen Teil der URL an den Pfad des statischen Ordners an und ruft die Methode set_static_file_info auf, um die Datei bereitzustellen:

1res.set_static_file_info(CROW_STATIC_DIRECTORY + file_path_partial);

Die Lösung bestand darin, am Anfang der Methode set_static_file_info den Aufruf utility::sanitize_filename(path) hinzuzufügen. sanitize_filename ersetzt alle Vorkommen von „..“ durch „_“ und behebt so die Schwachstelle. Die Lösung ist nicht perfekt, da der Server dadurch keine Dateien bereitstellen kann, deren Name „..“ enthält. Das kommt jedoch vermutlich selten vor und dürfte keine größeren Probleme verursachen.

Beliebiges Schreiben von Dateien

Schwachstellen, die das beliebige Schreiben von Dateien ermöglichen, treten sehr häufig in Codebasen auf, in denen die Anwendung Datei-Uploads unterstützt. Die Ursache ähnelt dem vorherigen Fall, ist aber etwas weniger offensichtlich. Stellen Sie sich ein einfaches HTML-Formular für Datei-Uploads vor:

1<form method=”post”>
2<input type="file" name="avatar">
3<input type="submit" value="submit">
4</form>

Wählen wir eine Textdatei namens „test.txt“ mit dem Inhalt „test“ aus. Der Browser erstellt dann eine HTTP-Anfrage, die etwa so aussieht:

1POST /upload HTTP/1.1
2Host: localhost:8000
3Content-Length: 150
4Content-Type: multipart/form-data; boundary=----xxx
5Connection: close
6
7------xxx
8Content-Disposition: form-data; name="file"; filename="test.txt"
9Content-Type: text/plain
10
11test
12
13------xxx--

Wenn Sie den Anfrageinhalt genauer untersuchen, sehen Sie, dass er mehr als nur den Dateiinhalt enthält. Dazu gehört ein Feld für den Dateinamen, das „../“-Segmente enthalten kann und vom Server korrekt verarbeitet werden muss.

Als Beispiel verwenden wir eine kürzlich entdeckte Schwachstelle, die das beliebige Schreiben von Dateien ermöglicht, im sehr beliebten Embedded-Webserver-Framework Mongoose.

Das Datei-Upload-Beispiel aus dem Mongoose-Repository ermöglicht es Benutzern, Dateien in Teilen hochzuladen. Das ist praktisch, wenn das Gerät, auf dem der Server läuft, nur über wenig RAM verfügt. Sie können das Beispiel erstellen und ausführen, indem Sie das Repository klonen und im Beispielordner den Befehl make ausführen. Der Server lauscht sofort auf Port 8000 und legt /tmp als Zielordner für hochgeladene Dateien fest (wie in Zeile 13 angegeben der Datei main.c.)

Nun können wir mit curl Dateien hochladen. Der Befehl curl -X POST --data-binary "test" http://localhost:8000/upload?offset=0&name=test.txt erstellt auf dem Server eine Datei /tmp/test.txt mit dem Text „test“.

Um die Schwachstelle auszunutzen, können wir direkt vor dem Abfrageparameter name „../“-Pfadsegmente einfügen: curl -X POST --data-binary "pwned" http://localhost:8000/upload?offset=0&name=../malicious-file. Der Exploit erstellt daraufhin die Datei malicious-file im Stammverzeichnis des Dateisystems.

Auswirkungen auf die Sicherheit

Schwachstellen, die das beliebige Schreiben von Dateien ermöglichen, lassen sich nicht so einfach ausnutzen wie solche, die beliebiges Lesen erlauben. In vielen Fällen können sie jedoch trotzdem zur Remote-Code-Ausführung (RCE) führen. Eine RCE ist oft möglich, weil Angreifer wichtige Systemdateien wie /etc/init.d/ oder sogar die ausführbaren Serverdateien überschreiben können.

Abhilfe

Wie im vorherigen Beispiel hat Mongoose die Schwachstelle behoben, indem „..“ aus dem vom Benutzer angegebenen Dateinamen entfernt wird. Die Korrektur ist in Version 7.6 enthalten.

Generell empfehlen wir, keine von Benutzern angegebenen Dateinamen zu verwenden. Nutzen Sie stattdessen zufällige Zeichenfolgen, Zeitstempel oder MD5-Hashes. Das eignet sich oft für Anwendungen mit Datei-Upload-Funktion und hilft, viele weitere Schwachstellen wie XSS zu vermeiden.

Zip Slip

Die dritte Art von Directory-Traversal-Schwachstelle, die wir heute behandeln, ist Zip Slip. Wie der Name schon andeutet, geht es dabei um Schwachstellen in der Logik zur Archivextraktion. Diese Art ist dem beliebigen Schreiben von Dateien sehr ähnlich, hat aber eine kleinere Angriffsfläche, da die Logik zur Archivextraktion nicht so häufig vorkommt.

Zur Veranschaulichung der Zip-Slip-Schwachstelle verwenden wir die anfällige Version 6.1.4 von JUCE, einem Open-Source- und plattformübergreifenden C++-Anwendungsframework.

1#include <juce_core/juce_core.h>
2
3int main()
4{
5    juce::File file("archive.zip");
6    juce::ZipFile zipFile(file);
7    zipFile.uncompressTo(juce::File("data"));
8    return 0;
9}

Diese einfache Anwendung verwendet die JUCE-API, um archive.zip in den Ordner data zu entpacken.

Um zu sehen, wie es funktioniert, können wir ein Beispielarchiv mit einer Datei test.txt erstellen:

1echo test > test.txt && zip archive.zip test.zip
2  adding: test.zip (stored 0%)

Wenn wir unsere Beispielanwendung kompilieren und ausführen, wird der Ordner data erstellt und die Datei test.txt darin abgelegt. Was aber, wenn wir ein Archiv mit einer Datei erstellen, die sich in der Dateihierarchie eine Ebene höher befindet?

1echo bad > ../bad.txt && zip archive.zip ../bad.txt

In diesem Fall liegt die Datei bad.txt nach der Ausführung unseres Programms außerhalb des Zielordners data. Wie Sie sehen, sind die Sicherheitsrisiken bei Zip Slip genau dieselben wie beim beliebigen Schreiben von Dateien.

Es gibt weitere Varianten von Zip Slip, etwa das Entpacken von Symlinks. Weitere Informationen zu diesem Thema finden Sie in unserem Forschungspapier.

Abhilfe

Die gezeigte Schwachstelle wurde in Version 6.1.5 des JUCE-Frameworks behoben – zusammen mit einer weiteren Variante: Zip Slip über Symlinks. JUCE behob die Schwachstelle, indem geprüft wird, ob der vollständig aufgelöste Dateipfad innerhalb des Zielverzeichnisses liegt.

Allgemeine Empfehlungen zur Behebung

Bei der Untersuchung dieser Schwachstellenklasse hat das Snyk Security Research-Team zahlreiche Codebeispiele mit verschiedenen Dateisystem- und Pfadoperationen geprüft. Dabei haben wir eine allgemeine Faustregel gefunden, mit der Sie sich vor Directory-Traversal-Schwachstellen schützen können.

Wenn Sie auf vom Benutzer angegebene Dateipfade verzichten können, tun Sie es!

Diese Regel gilt für viele Anwendungsfälle, in denen Dateien hochgeladen oder Archive entpackt werden.

Wenn Sie jedoch vom Benutzer angegebene Dateipfade verwenden müssen, empfehlen wir Ihnen die folgende Logik (implementiert mit std):

1// #include <iostream>
2// #include <string>
3// #include <filesystem>
4// #include <algorithm>
5
6    // This is the path to your static files folder.
7    std::string base_path("/tmp/path_to_the_content_root_directory/");
8    // User input – possibly contains "../" path segments.
9    std::string user_input("user_provided_path");
10
11    // The "canonical" method resolves ".", ".." and symlinks.
12    std::filesystem::path base_resolved_path(
13        std::filesystem::canonical(base_path));
14    // The "weakly_canonical" method does the same as "canonical" but not requires
15    // the file to exist.
16    std::filesystem::path requested_file_path(
17        std::filesystem::weakly_canonical(base_resolved_path / user_input));
18
19    // Using "equal" we can check if "requested_file_path" starts
20    // with base_resolved_path. Because we previously canonicalized both paths
21    // they can't contain any ".." segments, so this check is sufficient.
22    if (std::equal(
23            base_resolved_path.begin(),
24            base_resolved_path.end(),
25            requested_file_path.begin())) {
26        std::cout << "It is safe to work with the file: " << requested_file_path << "\n";
27    } else {
28        std::cout << "Not safe! We have to throw an exception here.\n";
29    }

Der obige Code erfordert mindestens C++17, lässt sich aber auch mit boost implementieren. Falls weder std noch boost in Ihrer Umgebung verfügbar sind, reicht es ebenfalls aus, „..“ durch leere Zeichenfolgen zu ersetzen und anschließend mehrere aufeinanderfolgende „/“-Zeichen zu einem einzelnen zusammenzufassen.

Wenn Ihre Anwendung plattformübergreifend ist und auch unter Windows läuft, sollten Sie außerdem die Trennzeichen für Verzeichnisse normalisieren. Windows akzeptiert meist sowohl Schrägstriche („/“) als auch umgekehrte Schrägstriche („\“) als Verzeichnistrenner. Das bedeutet, dass die Nutzlast „..\“ mit „../“ gleichbedeutend ist und ebenfalls für einen Directory-Traversal-Angriff verwendet werden kann. Am einfachsten stellen Sie sicher, dass Ihr Code unter Windows sicher ist, indem Sie vor der Verarbeitung von Pfaden „/“ durch „\“ ersetzen.

Fazit und wichtigste Erkenntnisse

Wenn Fachleute für Informationssicherheit an C- und C++-Schwachstellen denken, konzentrieren sie sich häufig auf Low-Level-Probleme wie verschiedene Arten von Speicherbeschädigung. Diese haben zwar große Auswirkungen auf das Ökosystem, dennoch sollten wir auch den Anwendungskontext berücksichtigen und neben Low-Level- auch High-Level-Schwachstellen verhindern. Zu Beginn unserer Untersuchung gingen wir davon aus, dass C/C++-Webentwickler gängigen Web-Sicherheitsproblemen zu wenig Aufmerksamkeit schenken. Tatsächlich konnten wir zahlreiche Directory-Traversal-Schwachstellen aufdecken:

• CVE-2022-25299: Beliebiges Schreiben von Dateien in Mongoose – einem Embedded-Webserver.

• CVE-2022-25297: Beliebiges Schreiben von Dateien in Drogon – einem HTTP-Anwendungsframework auf Basis von C++14/17.

• CVE-2021-23520, CVE-2021-23521: Zip Slip in JUCE – einem plattformübergreifenden Open-Source-C++-Anwendungsframework.

• CVE-2021-23514: Path Traversal in Crow – einem C++-Microframework.

• CVE-2022-25298: Path Traversal in Webcc – einem schlanken C++-HTTP-Client und -Server.

Diese Liste wächst weiter. Wir werden sie aktualisieren, sobald Mitwirkende ihre Fehlerbehebungen veröffentlichen.

Bleiben Sie sicher!