CVE-2025-2825/CVE-2025-31161

Einleitung

Dieses Dokument präsentiert die Untersuchung der Schwachstelle CVE-2025-2825, die den Serverteil von CrushFTP betrifft – eine kommerzielle Lösung für Dateiübertragung und -speicherung (FTP, SFTP, HTTP/S, S3-ähnliche Schnittstellen usw.).

Der Fehler wird als Authentication Bypass eingestuft, der es einem entfernten, nicht authentifizierten Angreifer ermöglicht, Administratorrechte zu erlangen. Eine erfolgreiche Ausnutzung gewährt Zugriff mit crushadmin-Privilegien, ermöglicht das Anzeigen und Ändern von Dateien, die Verwaltung von Benutzerkonten und die Durchführung administrativer Operationen über die Weboberfläche und die API von CrushFTP.

Gemeldete betroffene Versionen (laut öffentlichen Advisories und Forscherberichten):

• CrushFTP 10.0.0 – 10.8.3
• CrushFTP 11.0.0 – 11.3.0

⚠️ Hinweis: In einigen Veröffentlichungen gibt es Duplikate und Überschneidungen von CVE-IDs (z. B. CVE-2025-31161).

Ziel des Berichts

Schrittweise Analyse der Schwachstelle und Demonstration des vollständigen Untersuchungszyklus, einschließlich:

1. Sammlung und Analyse von Materialien – Systematisierung von Advisories, PoCs, technischen Analysen und Veröffentlichungen zu CVE-2025-2825; Formulierung des Wesens des Fehlers und seiner Auswirkungen.
2. Bestimmung von CPE und Bedingungen – Liste relevanter CPE/Versionen und Konfigurationen, unter denen die Schwachstelle reproduzierbar ist (Webschnittstellen, S3-kompatible Endpunkte usw.).
3. Entwicklung von PoC/Exploit – Erstellung eines reproduzierbaren PoC auf einer kontrollierten Testumgebung; Beschreibung der Architektur und Maßnahmen zur Schadensminimierung.
4. Methoden zur Massenüberprüfung – Drei Ansätze zur sicheren Suche nach verwundbaren Hosts:
   • aktiver Scan mit nuclei;
   • passiver nuclei (anhand von Versionen und indirekten Merkmalen ohne Ausnutzung);
   • eigenes Skript (Python/Go) zur kontrollierten Überprüfung.
5. Empfehlungen und Abhilfemaßnahmen – Praktische Tipps zur Erkennung, zum Patchen und zum Schutz von Instanzen.
6. Sichere Testpraxis – Checklisten für Tests nur in autorisierten Umgebungen.

Praktische Auswirkungen

Nach öffentlichen Berichten hat die Schwachstelle ein kritisches Risiko:

• Ausnutzung gewährt administrativen Zugriff auf die CrushFTP-Instanz.
• Folgen: Diebstahl/Änderung von Dateien, Erstellung/Löschung von Benutzern, Installation von Backdoors, Nutzung des Servers für weitere Angriffe.
• CVSS wird als kritisch bewertet (ca. 9,8).
• In der Community wurden PoCs und Anzeichen einer Ausnutzung „in freier Wildbahn“ dokumentiert.

Ziel-CPEs / Konfigurationen

Kritisch sind Instanzen mit folgenden Merkmalen:

• Produkt: CrushFTP (jede Edition mit Webschnittstelle).
• Versionen: 10.0.0 – 10.8.3, 11.0.0 – 11.3.0.
• Konfigurationen mit erhöhtem Risiko:
  • Öffentliche Web-Administrationsschnittstelle aktiviert (HTTP/S).
  • S3-kompatible API-Endpunkte aktiviert.
  • Keine zusätzlichen Schutzmaßnahmen (IP-Filterung, 2FA).
  • Fehlerhafte Proxy-/Load-Balancer-Konfigurationen, die interne Endpunkte von außen erreichbar machen.

Verständnis der Schwachstelle

CrushFTP implementiert die Unterstützung einer S3-ähnlichen API. Für die Authentifizierung wird der Header Authorization in folgender Form verwendet:

Authorization: AWS4-HMAC-SHA256 Credential=<AccessKey>/<Date>/<Region>/s3/aws4_request, SignedHeaders=<Headers>, Signature=<Signature>

Der Server extrahiert den AccessKey aus dem Credential-Feld und sollte die Signatur überprüfen. Im Code gab es jedoch einen Fehler bei der Handhabung des Flags lookup_user_pass.

• Verwundbarer Code (vereinfachter Ausschnitt):

// ServerSessionHTTP.java, Methode loginCheckHeaderAuth()
if (this.headerLookup.containsKey("AUTHORIZATION") &&
    this.headerLookup.getProperty("AUTHORIZATION").trim().startsWith("AWS4-HMAC")) {
    
    boolean lookup_user_pass = true;   // ← kritischer Fehler
    
    if (s3_username3.indexOf("~") >= 0) {
        user_pass = user_name.substring(user_name.indexOf("~") + 1);
        user_name = user_name.substring(0, user_name.indexOf("~"));
        lookup_user_pass = false;
    }
    
    if (this.thisSession.login_user_pass(
            lookup_user_pass,
            false,
            user_name,
            lookup_user_pass ? "" : user_pass)) {
        // Erfolgreiche Authentifizierung
    }
}

• Weitere Logik:

Das Flag lookup_user_pass wird direkt als anyPass übergeben:

if (anyPass && user.getProperty("username").equalsIgnoreCase(the_user)) {
    return user;  // Authentifizierung ohne Passwortprüfung
}

Somit:

• Wenn der Benutzername ohne das Zeichen ~ angegeben wird, bleibt das Flag true.

• Die Passwortüberprüfung wird nicht durchgeführt.

• Ein Angreifer kann sich authentifizieren, indem er nur einen vorhandenen Benutzernamen (z. B. crushadmin) angibt.

• Zusammen mit einem formal gültigen CrushAuth-Cookie und dem Parameter c2f kann so die Authentifizierung umgangen und administrativer Zugriff erlangt werden.

Behebung

In Version 11.3.1 und neuer haben die Entwickler:

• Den Parameter s3_auth_lookup_password_supported (standardmäßig false) hinzugefügt, der das verwundbare Szenario blockiert.
• Frühe Prüfungen des Benutzernamens auf ~ eingeführt.
• Die Logik der Flags getrennt, um die Vertauschung von lookup_user_pass → anyPass zu beseitigen.
• Empfehlung: CrushFTP sofort auf 11.3.1+ aktualisieren oder den Workaround mit deaktiviertem s3_auth_lookup_password_supported anwenden.

POC/Exploit

Die Ausnutzung von CVE-2025-2825 ist relativ einfach und erfordert keine aufwändige Vorbereitung. Der Angreifer muss lediglich eine speziell gestaltete HTTP-Anfrage senden, die zwei Schlüsselelemente enthält:

• Einen Authorization-Header im AWS-S3-Format, der einen korrekten, existierenden Benutzernamen enthält (Feld Credential mit AccessKey/Benutzername).
• Ein Cookie CrushAuth im erwarteten Format und den Parameter c2f in URL/Anfragekörper, deren Werte logisch zueinander passen (das Cookie-Format muss der vom Server erwarteten Struktur entsprechen).

Wenn der Server verwundbar ist (Version aus dem Bereich 10.0.0–10.8.3 oder 11.0.0–11.3.0 und kein korrigierender Patch angewendet), führt diese Kombination dazu, dass der Authentifizierungs-Handler den verwundbaren Pfad einschlägt, bei dem das Flag zur Passwortsuche (lookup_user_pass) als „jedes Passwort ist gültig“ interpretiert wird und der Benutzer allein anhand des Namens ohne Passwortprüfung authentifiziert wird.

Wichtiger Hinweis:

Die Ausnutzung dieser Schwachstelle erfordert in der Regel das Senden von zwei aufeinanderfolgenden Anfragen. Die erste, sogenannte „Warm-up“-Anfrage, startet den verwundbaren Authentifizierungsprozess auf dem Server. Charakteristisch dafür ist, dass man als Antwort einen Fehler 502 Bad Gateway oder einfach ein Timeout erhält. Unmittelbar danach wird die zweite, eigentliche Anfrage gesendet, die die nützliche Aktion ausführt (z. B. Benutzererstellung), während der Server sich noch im verwundbaren Zustand befindet.

GET /WebInterface/function/?command=getUserList&serverGroup=MainUsers&c2f=1111 HTTP/1.1
Host: target-server:8080
Cookie: CrushAuth=1743113839553_vD96EZ70ONL6xAd1DAJhXMZYMn1111
Authorization: AWS4-HMAC-SHA256 Credential=crushadmin/

Für den Test habe ich die kürzlich veröffentlichte HTB-Lab-Umgebung Soulmate verwendet, bei der genau die Ausnutzung von CrushFTP erforderlich ist.

Weiteres Vorgehen:

Dank dieser Schwachstelle kann mit dem Befehl setUserItem ein neuer Benutzer mit Administratorrechten hinzugefügt werden. Führen Sie dazu new_user.py aus.

python3 new_user.py --target_host http://ftp.soulmate.htb/ --port 80 --target_user crushadmin --new_user literide --password literide

Warum das funktioniert

1. Parsing des Authorization-Headers: Wenn der Server einen Autorisierungsheader im S3-ähnlichen Format (AWS4-HMAC…) sieht, extrahiert er aus dem Credential-Feld die Client-ID (AccessKey / Benutzername). In diesem Schritt erhält der Server eine Zeichenkette, die er als Benutzernamen betrachtet – diesen Identifikationswert verwendet er dann in der Authentifizierungslogik.

2. Das Flag lookup_user_pass und seine Rolle:

Im Code gibt es ein boolesches Flag lookup_user_pass, das angeben soll, woher das Passwort bei der Prüfung stammt:

• Im normalen Szenario hilft das Flag zu entscheiden: ob das in der Anfrage übermittelte Passwort verwendet oder das Passwort aus dem Benutzerspeicher abgerufen werden soll.

• Aufgrund eines Implementierungsfehlers wird dasselbe Flag jedoch weitergegeben und in der Prüffunktion anders interpretiert – als Signal, das die Passwortprüfung zu überspringen erlaubt (im Wesentlichen: „anyPass“).

3. Weitergabe des Flags entlang der Aufrufkette: Ungefährer Pfad: ServerSessionHTTP.loginCheckHeaderAuth() → Session.login_user_pass(...) → UserTools.ut.verify_user(...). Am Eingang bestimmt das Flag das Verhalten, und in verify_user führt es zu einer frühen Rückgabe des gefundenen Benutzerobjekts ohne Passwortvergleich, wenn der Name übereinstimmt. Dies ermöglicht die Umgehung der Authentifizierungsprüfung – der Server „erkennt“ den Benutzer am Namen und betrachtet ihn als authentifiziert.

4. Begleitende Elemente (Cookie / c2f): Öffentliche Analysen wiesen darauf hin, dass der Handler ein korrektes Format von Cookie/Parametern erwartet, um die Anfrage einer Sitzung/einem Kontext zuzuordnen. Der eigentliche Fehler liegt jedoch im logischen Fehler bei der Verarbeitung von lookup_user_pass; die anderen Elemente helfen der Anfrage lediglich, die Standardverarbeitungszweige zu durchlaufen.

Hauptursache

• Überladung der Flag-Bedeutung: Ein Flag, das entscheiden sollte „woher das Passwort nehmen“, wurde als „beliebiges Passwort erlauben“ verwendet. Diese Kombination mit dem vereinfachten Parsen von Credential führte dazu, dass das Vorhandensein eines korrekten Benutzernamens ausreichte, um die Benutzerdaten ohne Passwortprüfung zu erhalten.

Nuclei-Vorlage

• Passive Vorlage:

  Da die genaue Version von CrushFTP in den meisten Webservices nicht bestimmbar ist, prüft diese Vorlage lediglich, ob der Dienst CrushFTP verwendet.

  Am besten in Kombination mit der aktiven Vorlage verwenden.

• Aktive Vorlage:

  Die aktive Vorlage prüft, ob der Befehl getUserList möglich ist.

  

• Multithread-Skript

  Das Skript funktioniert ähnlich wie die aktive Vorlage, ist jedoch viel schneller und unterstützt die gleichzeitige Überprüfung mehrerer Hosts.

  root@kitploit:~

  python3 scan.py -t http://ftp.soulmate.htb/ -p 80 -u crushadmin
  

  

Empfehlungen zur Behebung und Schutz

Um die mit CVE-2025-31161 verbundenen Risiken zu mindern, werden folgende Schritte empfohlen:

1. Sofortige Aktualisierung:

   • Aktualisieren Sie alle CrushFTP-Instanzen auf Version 11.3.1 oder neuer. Dies ist die zuverlässigste Methode, um die Schwachstelle vollständig zu beheben.

2. Anwendung eines Workaround (falls ein Update nicht möglich ist):

   • Setzen Sie in der Serverkonfiguration den Parameter s3_auth_lookup_password_supported auf false. Dies deaktiviert die verwundbare Authentifizierungslogik, ohne das gesamte Produkt zu aktualisieren.

3. Risikokompensierende Maßnahmen:

   • Zugriff einschränken: Verwenden Sie Firewall oder Reverse Proxy (NGINX, Caddy), um den Zugriff auf die CrushFTP-Weboberfläche nur von vertrauenswürdigen IP-Adressen (z. B. aus dem Firmennetzwerk oder VPN) zu erlauben.
   • Log-Überwachung: Analysieren Sie regelmäßig die Zugriffslogs von CrushFTP auf verdächtige Anfragen, die AWS4-HMAC-SHA256 im Authorization-Header enthalten, insbesondere wenn Sie keine S3-Integration nutzen.
   • Web Application Firewall (WAF) einsetzen: Konfigurieren Sie eine WAF so, dass Anfragen blockiert werden, die anomale Authorization-Header an Endpunkte enthalten, die nicht für die S3-API vorgesehen sind.