Technische Studie der Schwachstelle CVE-2025-5548
In dieser Arbeit wird die Schwachstelle CVE-2025-5548 analysiert, die mit einem Stack-Pufferüberlauf in FreeFloat FTP Server v1.0 verbunden ist. Das Hauptziel des Labors ist zu verstehen, wie eine anfällige Anwendung auf manipulierte Eingaben reagiert und in einer kontrollierten Umgebung zu beobachten, wie ein Validierungsfehler letztendlich den Ausführungsfluss des Programms beeinflussen kann.
Die Entwicklung des Repositorys beschränkt sich nicht auf die Darstellung des Endergebnisses, sondern erfasst den gesamten Forschungsprozess: Vorbereitung der Umgebung, Auswahl der Werkzeuge, Beobachtung des Fehlers, Speicheranalyse und Validierung der tatsächlichen Auswirkungen der Schwachstelle.
Die Arbeit ist in zwei verschiedene Blöcke gegliedert.
In diesem Abschnitt wird erläutert, wie die Übungsumgebung aufgebaut wurde, welches Betriebssystem verwendet wurde, welche anfällige Anwendung vorliegt und welche Werkzeuge für die Analyse als notwendig erachtet wurden.
Der zweite Teil konzentriert sich auf den praktischen Teil. Hier wird der Prozess beschrieben, der zur Erkennung des Fehlers, zur Bestätigung der Speicherkorruption, zur Untersuchung der Registerüberschreibung und zur Überprüfung, wie die Schwachstelle ausgenutzt werden kann, geführt hat.
Die Übung wurde auf einer virtuellen Maschine mit Windows 11 Pro 25H2 (Build 26200.6584) durchgeführt. Die ausgewählte anfällige Software war FreeFloat FTP Server v1.0, eine ältere Anwendung, die sich für diese Art von Übungen eignet, da ihr viele der üblichen Schutzmechanismen aktueller Programme fehlen.
Das Netzwerk der virtuellen Maschine wurde im NAT-Modus konfiguriert, was den Internetzugang zum Installieren von Abhängigkeiten, Herunterladen von Werkzeugen und Aufrechterhalten der grundlegenden Konnektivität des Labors ermöglichte.
Um alle Phasen der Analyse abzudecken, war es notwendig, auf mehrere Hilfsprogramme zurückzugreifen. Einige wurden zur Vorbereitung der Umgebung verwendet, andere zur Überprüfung der Binärdatei und wieder andere zur Beobachtung des Verhaltens des Prozesses beim Auftreten des Fehlers.
Es wurde verwendet, um Repositorys herunterzuladen, bestimmte Ressourcen organisiert zu halten und die Verwaltung des während der Forschung verwendeten Materials zu erleichtern.
Es wurde als Unterstützung verwendet, um die Konnektivität zu überprüfen, den exponierten Dienst zu identifizieren und sicherzustellen, dass das Ziel auf dem erwarteten Port korrekt antwortet.
Es wurde installiert, um Bibliotheken, Header und Werkzeuge für Low-Level-Debugging- und Analyseaufgaben im Windows-System verfügbar zu haben.
Es wurde für schnelle Bearbeitungen, Überprüfung von Skripten und einfache Manipulation von Zeichenketten oder Testdaten verwendet.
Diente als komfortable Umgebung zum Schreiben von Skripten, Testen von Automatisierungen und Arbeiten mit Code in geordneterer Weise.
War besonders nützlich, wenn längere Skripte überprüft oder eine mit dem Bau von Payloads zusammenhängende Logik debuggt werden musste.
Es wurden zwei Versionen berücksichtigt:
War notwendig, um Ghidra auszuführen, da dieses Tool auf Java basiert.
Es wurde verwendet, um den Zustand des Programms während der Ausführung zu beobachten, Register zu überprüfen, Speicher zu untersuchen und den genauen Punkt zu analysieren, an dem der Fehler auftritt.
Es wurde in der Phase der statischen Analyse verwendet, um die Binärdatei zu überprüfen und Funktionen zu lokalisieren, die aus Sicherheitssicht verdächtig erschienen.
Es wurde als Unterstützung verwendet, um die interne Logik des anfälligen Programms zu dekompilieren und besser zu verstehen.
Dieses Plugin erleichterte Aufgaben wie die Erstellung von Mustern, die Berechnung des Offsets und die Identifizierung problematischer Zeichen in der Payload.
Die Hauptkomponente des Labors war FreeFloat FTP Server v1.0, der als Zielsystem innerhalb des Proof-of-Concept fungiert. Sein Interesse liegt darin, dass er eine klassische Stack-Überlauf-Schwachstelle aufweist, was ihn zu einem sehr geeigneten Fall für die Ausbildung in der Analyse macht.
Obwohl es bereits vorkonfigurierte virtuelle Maschinen für diese Art von Übungen gibt, wurde in diesem Fall darauf geachtet, die Umgebung zu dokumentieren und die verwendeten Werkzeuge zu begründen. Dies ermöglicht ein besseres Verständnis dafür, warum jede Anwendung Teil des Labors ist und welche Rolle sie während der Analyse spielt.
Der erste Schritt bestand darin, zu überprüfen, ob der FTP-Dienst erreichbar war und korrekt funktionierte. Nach Bestätigung der Konnektivität wurde die Binärdatei mit statischen Analysetools untersucht, um mögliche Schwachstellen im Zusammenhang mit der Zeichenkettenverwaltung zu lokalisieren.
Während dieser Überprüfung traten unsichere Funktionen wie strcpy und strcat auf, was den Verdacht verstärkte, dass der Dienst für übermäßig lange Eingaben anfällig sein könnte. Es wurden auch mehrere FTP-Protokollbefehle untersucht, die möglicherweise benutzergesteuerte Daten empfangen, und einer davon wurde als Hauptkandidat für die Tests ausgewählt.
Mit dieser Grundlage wurde der Prozess in einen Debugger geladen, um sein Verhalten während der Ausführung zu beobachten.
Die nächste Phase bestand darin, immer längere Zeichenketten zu senden, um zu überprüfen, ob das Programm nicht mehr korrekt reagierte. Dieses Verfahren ermöglichte es festzustellen, dass der Dienst ab einer bestimmten Größe ausfiel und letztendlich eine Veränderung im Speicher verursachte.
Dieses Verhalten bestätigte, dass es sich nicht um einen einfachen oberflächlichen Validierungsfehler handelte, sondern um eine echte Korruption, die den Prozessablauf beeinflusste.
Nachdem der Fehler ausgelöst wurde, war es notwendig, genau zu berechnen, wie viele Bytes benötigt wurden, um die Rücksprungadresse zu erreichen. Dazu wurde eine sich nicht wiederholende Sequenz verwendet, sodass der im EIP zum Zeitpunkt des Absturzes angezeigte Wert mit einer genauen Position innerhalb der gesendeten Eingabe in Verbindung gebracht werden konnte.
Dank dieses Verfahrens wurde der spezifische Offset ermittelt, der zum Überschreiben des Kontrollregisters erforderlich war.
Mit dem nun bekannten Offset wurde ein neuer Test vorbereitet, bei dem die Rücksprungadresse durch einen leicht erkennbaren Wert ersetzt wurde. Ziel war es zu überprüfen, ob das Programm eine kontrollierte Änderung von EIP erlaubt.
Der Test war erfolgreich, da der Debugger anzeigte, dass das Register genau den eingegebenen Wert enthielt. Dies zeigte, dass es möglich war, den Ausführungsfluss zu ändern und auf eine gewählte Adresse umzuleiten.
