Sitzungspersistenz nach Aktivierung von 2FA

Überblick

Die Nagios-Fusion-Anwendung (Versionen 2024R1.2 und 2024R2) weist eine schwerwiegende Sicherheitslücke auf, bei der bestehende Sitzungen auch nach der Aktivierung der Zwei-Faktor-Authentifizierung (2FA) gültig bleiben. Konkret invalidiert die Anwendung beim Aktivieren von 2FA für ein Administratorkonto nicht alle aktiven Sitzungen, die vor der Aktivierung von 2FA eingerichtet wurden. Dadurch kann ein Angreifer oder ein unbefugter Benutzer mit Zugriff auf eine ältere Sitzung den 2FA-Mechanismus umgehen und unbefugte Aktionen ausführen.

Die folgenden Probleme wurden beobachtet:

Sitzungspersistenz: Vor der Aktivierung von 2FA erstellte Sitzungen bleiben gültig, ohne den zusätzlichen Authentifizierungsfaktor zu erfordern.

Unbefugte Rechteausweitung: Mit diesen alten Sitzungen können Angreifer kritische Kontodaten ändern oder administrative Aktionen ohne 2FA-Validierung durchführen.

Diese Schwachstelle entsteht durch das Fehlen einer Sitzungsinvalidierung während des 2FA-Aktivierungsprozesses, wodurch die Anwendung den zusätzlichen Sicherheitsmechanismus für ältere Sitzungen nicht durchsetzt.

Schweregrad

Schweregrad: Hoch
CWE: CWE-613 (primär); CWE-287 (sekundär)
CVSS-Score (v3.0): 7.3 Hoch
CVSS-Vektor: AV:A/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:N

Betroffene Komponenten

Authentifizierungs-Gateway / Sitzungsdienst: Logik zur Ausstellung, Validierung und Widerrufung von Sitzungen.
2FA-Registrierungs- und Richtlinien-Engine: Logik, die das Assurance-Level eines Kontos anhebt, ohne bestehende Token zu widerrufen.
Web-Frontend / API: Autorisierungsprüfungen, die dem Legacy-Sitzungszustand vertrauen.
Geräteverwaltung: Speicher für gemerkte Geräte / vertrauenswürdige Sitzungen (Cookies, Refresh-Tokens, serverseitige Sitzungen).

Betroffener Anbieter/Produkt

Produktname- Nagios Fusion
Betroffene Version: 2024R1.2 und 2024R2
Behobene Version: 2024R2.1

Zusammenfassung des Problems

Was passiert:

Der Benutzer aktiviert 2FA für sein Konto (TOTP/SMS/push/webauthn).
Der Server aktualisiert den MFA-/Assurance-Status des Benutzers, invalidiert jedoch bestehende Sitzungen nicht und fordert sie nicht erneut zur Authentifizierung auf.
Alle aktiven Sitzungen (einschließlich derer auf angreiferkontrollierten Clients) arbeiten weiterhin mit dem Pre-2FA-Kontext und umgehen so die beabsichtigte Kontrollanhebung.

Lücke in der Sicherheitslage: Die Aktivierung von 2FA ist eine Änderung der Sicherheitsgrenze. Wenn kein Sitzungs-Upgrade (erneute Authentifizierung + 2FA) erzwungen und keine Legacy-Sitzungen widerrufen werden, wird die Risikoreduzierung der Kontrolle zunichte gemacht.

Realistische Missbrauchsszenarien:

Ein Angreifer mit gestohlenem Sitzungs-Cookie behält nach der 2FA-Aktivierung Zugriff und kann Daten exfiltrieren oder Kontoeinstellungen ändern.
Ein gemeinsam genutzter Kiosk oder ein nicht verwaltetes Gerät behält eine aktive Sitzung, die die neue MFA-Anforderung umgeht.

Empfehlungen zur Schadensbegrenzung

Bei der 2FA-Registrierung oder einem Faktor-Reset alle bestehenden Sitzungen (Access- und Refresh-Tokens) auf allen Geräten widerrufen und eine erneute primäre Authentifizierung + 2FA verlangen.
Sitzungsgeheimnisse rotieren (z. B. Signaturschlüssel ändern oder die serverseitige Sitzungsversion erhöhen), um veraltete Token zu invalidieren.
maxAge und idleTimeout auf angemessene Werte setzen; langlebige Sitzungen reduzieren.

Offenlegungszeitplan

[04-01-2025]: Schwachstelle entdeckt
[04-01-2025]: An den Anbieter gemeldet
[10-01-2025]: Anbieter hat die Schwachstelle verifiziert
[23-07-2025]: Anbieter hat die Schwachstelle mit einem neuen Release behoben
[16-08-2025]: CVE beantragt
[23-10-2025]: CVE zugewiesen

📌 Dieses Repository dient ausschließlich der Meldung von Schwachstellen und der CVE-Referenz.

Session-Persistence-After-Enabling-2FA-CVE-2025-60425

Beliebteste