⚠️ Mögliche Auswirkung auf Patientensicherheit

Betroffene Einrichtungen

🏥 Krankenhaus🏨 Fachklinik🏃 Rehaklinik🏡 Pflegeheim🔬 Labor🏢 Ambulantes Zentrum

Bereich

IT-InfrastrukturNetzwerkCloud-DiensteKIS-SoftwareLIS / RIS / PACS
Beschreibung

Die JWT-Authentifizierungsmechanismen in WSO2 API Control Plane, API Manager, Traffic Manager und Universal Gateway akzeptieren Token, die mit nicht konfigurierten oder nicht vorgesehenen Algorithmen signiert wurden. Ein nicht authentifizierter, netzwerkseitiger Angreifer kann dadurch manipulierte JWT-Token erstellen, die fälschlicherweise als gültig akzeptiert werden, was zu unautorisiertem Zugriff – einschließlich der vollständigen Übernahme administrativer Konten – führt (CVSS 10.0). WSO2 API Manager und verwandte Komponenten werden in Gesundheitseinrichtungen häufig als zentrales API-Gateway eingesetzt, um klinische Systeme wie KIS, LIS oder PACS miteinander und mit externen Diensten zu verbinden, sodass eine Kompromittierung im Klinikumfeld den Zugriff auf sensible Patientendaten und kritische Systemfunktionen gefährden kann. Angesichts des maximalen CVSS-Scores und der Möglichkeit zur vollständigen Kontoübernahme ohne Authentifizierung ist sofortiges Handeln durch Konfigurationshärtung und Patch-Einsatz zwingend erforderlich.

Handlungsempfehlung

1 JWT-Algorithmus-Validierung in WSO2 API Manager, API Control Plane, Traffic Manager und Universal Gateway sofort auf ausschließlich zulässige Algorithmen (z. B. RS256) beschränken – in der Konfigurationsdatei (deployment.toml) den Parameter 'allowed_algorithms' explizit setzen und unsichere Algorithmen (insb. 'none' sowie symmetrische Algorithmen wie HS256, sofern nicht vorgesehen) deaktivieren; anschließend Neustart der betroffenen Dienste.

2. Hersteller-Sicherheitsadvisory von WSO2 umgehend prüfen und verfügbare Patches oder aktualisierte Produktversionen für alle betroffenen Komponenten (API Control Plane, API Manager, Traffic Manager, Universal Gateway) einspielen.

3. Bestehende JWT-Tokens und aktive Sitzungen für alle administrativen und privilegierten Konten sofort invalidieren und betroffene Zugangsdaten zurücksetzen, um mögliche Kompromittierungen durch bereits ausgenutzte Tokens zu beheben.

4. Zugriffsprotokolle (Access Logs) der betroffenen WSO2-Komponenten rückwirkend auf ungewöhnliche Authentifizierungsversuche mit abweichenden Algorithmen oder unautorisierte Zugriffe auf administrative Endpunkte untersuchen.

5. Netzwerkseitig den Zugriff auf die API-Management-Komponenten auf vertrauenswürdige Netzsegmente einschränken (z. B. über Firewall-Regeln oder WAF) und Multi-Faktor-Authentifizierung für administrative Zugänge erzwingen, bis ein vollständiger Patch eingespielt ist.

🔒

Weitere konkrete Handlungsschritte für Ihre IT-Abteilung
sind ISMShield AI Kunden vorbehalten.

Jetzt freischalten →
Regulatorische Einordnung

NIS2-Relevanz: •••    B3S: •••    ISG: ••ˆ    Meldepflicht DE: ja

🔒

Regulatorische Einordnung (NIS2, B3S, ISG, nDSG)
nur für ISMShield AI Kunden.

Details freischalten →