Collax Security Gateway: anonyme Pfad-Traversierung im Logout-Handler löscht den Zwei-Faktor-Token-Speicher

Ein unauthentifizierter Angreifer löscht über ein manipuliertes Logout-Cookie den appliance-weiten Zwei-Faktor-Token-Speicher und weitere von www-data schreibbare Dateien, mit einem einzigen GET-Request.

Advisory-ID: TP-2026-063
Produkt: Collax Security Gateway (deutsche UTM-, Firewall-, Mail- und SSL-VPN-Appliance; betrifft auch Collax Business Server und Groupware Suite)
Schwachstellentyp: Pfad-Traversierung (CWE-22)
CVE: pending (MITRE CNA-LR)
CVSS 3.1: 7.3 (Hoch) · CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:L/I:L/A:L
Hersteller-Advisory: Collax Release Notes CSG 7.2.48
Betroffene Versionen: 7.2.46 und früher
Behoben in: 7.2.48
Gemeldet: 01. September 2026

Zusammenfassung

Collax Security Gateway ist eine deutsche UTM-, Firewall- und Mail-Appliance. Der anonyme Logout-Endpunkt /.loggedOut (cgi-bin/logout-admin.cgi) liest das Request-Cookie 2FA_Auth und setzt dessen Wert ohne jede Prüfung in einen Dateipfad ein. Der Handler baut Mojo::File->new(sprintf('/var/lib/apache_2fa/state/%s', )) und ruft unlink() auf, sobald die Zieldatei kein gültiges JSON ist. Da der Endpunkt mit 'Require all granted' ausgeliefert wird, löscht ein unauthentifizierter Angreifer beliebige von www-data schreibbare Dateien, darunter den 2FA-Token-Speicher tokens.json. Die vorangehende Prüfung dient zusätzlich als Existenz- und JSON-Typ-Orakel für beliebige Pfade.

Ursache

logout-admin.cgi:50 baut den Pfad mit Mojo::File->new(sprintf('/var/lib/apache_2fa/state/%s', $q->cookie('2FA_Auth'))) direkt aus dem angreiferkontrollierten Cookie, ohne .. zu verwerfen, zu kanonisieren oder auf einen Basisnamen zu reduzieren.
logout-admin.cgi:58 ruft unlink($stateFile) auf, sobald die eingelesene Datei nicht als JSON dekodiert, sodass jedes Nicht-JSON-Ziel unterhalb des Traversal-Pfads entfernt wird.
Der Schreiber desselben Tokens (apache_2fa/auth:244) nutzt das sichere Mojo::File->child($key), das / und .. ablehnt, während der Logout-Handler mit ->new(sprintf) genau diese Prüfung weglässt.
Ein gültiges Token ist eine undurchsichtige 100-Zeichen-ID aus [A-Z0-9] und kann nie einen Pfadtrenner enthalten, sodass Traversal-Eingabe ausserhalb des Vertrags liegt.
Der Block wird anonym betreten, weil die Apache-Konfiguration 'Require all granted' plus SetEnv AuthContext apache setzt und damit den AuthContext-Guard bei logout-admin.cgi:40 ohne Login erfüllt.

Proof of Concept

Schematisch: ein einzelner GET-Request, kein Login, keine Interaktion.

GET /.loggedOut HTTP/1.1
Host: gw.example.com
Cookie: 2FA_Auth=<Traversal-Pfad auf eine www-data-schreibbare Nicht-JSON-Datei>

Der Traversal-Pfad im Cookie verlässt das 2FA-Zustandsverzeichnis. Zeigt er auf tokens.json, wird der appliance-weite 2FA-Speicher gelöscht; zeigt er auf eine Datei ausserhalb des www-data-Bereichs, verrät allein das An- oder Ausbleiben des Lösch-Cookies deren Existenz. Der Lösch- und der Orakel-Pfad wurden am 01.09.2026 als uid 33 (www-data) verifiziert.

Auswirkung

  • Anonymes Löschen des appliance-weiten 2FA-Speichers tokens.json, was alle TOTP-Secrets entfernt und eine globale Neu-Registrierung erzwingt.
  • Anonymes Löschen jeder weiteren von www-data schreibbaren Nicht-JSON-Datei unter /var/lib/apache_2fa/.
  • Unauthentifiziertes Existenz- und JSON-Typ-Orakel über beliebige Dateipfade, auch ausserhalb des schreibbaren Bereichs.
  • Keine Authentifizierung, keine Interaktion, ein GET-Request; erreichbar in der Standardkonfiguration.

Referenzen

Steckt so etwas in Ihrer Software?

Diese Schwachstelle hat unser Team im Rahmen seiner Arbeit gefunden. Lassen Sie Ihre Anwendungen von denselben Spezialisten prüfen, mit einem Penetrationstest von turingpoint.

Pentest anfragen