SonicWall SSLVPN Sicherheitslücke: Sofortmaßnahmen für Kliniken
Einleitung
Ende Januar 2025 veröffentlichten Sicherheitsforscher von Rapid7 einen funktionsfähigen Proof-of-Concept-Exploit für eine kritische SonicWall SSLVPN Sicherheitslücke – und machten damit eine der gefährlichsten Angriffsvektoren des Jahres öffentlich zugänglich. Für Krankenhäuser und Kliniken, die SonicWall-Firewalls als Perimeterschutz oder für Remote-Access-Zugänge einsetzen, bedeutet dies: unmittelbarer Handlungsbedarf. Besonders brisant ist, dass der Exploit weder Zugangsdaten noch MFA-Token erfordert – eine existierende, authentifizierte Session reicht aus, um ins interne Netz einzudringen. Dieser Artikel erklärt die Schwachstelle, beschreibt die konkrete Angriffstechnik und gibt ISB sowie IT-Leitungen in Gesundheitseinrichtungen eine strukturierte Handlungsanleitung.
Was steckt hinter CVE-2024-53704?
Am 7. Januar 2025 veröffentlichte SonicWall ein Security Advisory zu mehreren Schwachstellen in SonicOS, dem Betriebssystem der SonicWall-Firewall-Produktlinie. Im Mittelpunkt steht CVE-2024-53704, eine Authentifizierungsumgehung in der SSLVPN-Komponente von SonicOS (CWE-287: Improper Authentication). Das Common Vulnerability Scoring System (CVSS) bewertet die Schwachstelle mit 8.2 – „hoch".
Das BSI stufte die Sicherheitsmitteilung mit Kritikalität 2 ein und veröffentlichte am 31. Januar 2025 eine offizielle Cybersicherheitswarnung (2025-213884-1032).
Die Schwachstelle selbst war mit dem SonicWall-Patch vom 7. Januar behebbar – der entscheidende Wendepunkt kam jedoch am 28. Januar 2025: Rapid7 publizierte technische Details und einen vollständigen Proof-of-Concept-Exploit. Damit wurde aus einer theoretisch ausnutzbaren Schwachstelle ein praktisch einsetzbares Angriffswerkzeug, das auch technisch weniger versierten Angreifern zur Verfügung steht.
Betroffene Systeme
Betroffen sind SonicWall-Firewalls der Gen 6 und Gen 7, die SonicOS in bestimmten Versionen betreiben und bei denen die SSLVPN-Funktion aktiv ist. Konkret sollten Administratoren die Versionsstände mit dem SonicWall-Advisory vom Januar 2025 abgleichen und prüfen, ob der Patch eingespielt wurde.
Wie der Angriff funktioniert – und warum MFA nicht schützt
Die technische Funktionsweise des Exploits ist aus Verteidigungssicht besonders alarmierend, weil sie mehrere klassische Schutzannahmen widerlegt.
Session Hijacking ohne Credentials
Ein nicht authentifizierter Angreifer kann eine bestehende, aktive SSLVPN-Client-Session kapern. Der Exploit manipuliert den Authentifizierungsvorgang so, dass er die Identität einer bereits eingeloggten Sitzung übernimmt. Für diesen Angriff benötigt der Angreifer:
- Keinen Benutzernamen
- Kein Passwort
- Keinen MFA-Token oder TOTP-Code
Der einzige Voraussetzung ist eine aktive, authentifizierte Session – die in einer Klinikumgebung mit Remote-Work-Zugängen für Ärzte, Pflegepersonal oder externe Dienstleister praktisch immer vorhanden ist.
MFA greift nicht
Dieser Punkt verdient besondere Aufmerksamkeit: Multi-Faktor-Authentifizierung, die für viele Einrichtungen inzwischen Standard ist und auch von der KBV-Richtlinie nach §75b SGB V sowie den B3S-Anforderungen für Krankenhäuser gefordert wird, bietet hier keinen Schutz. Der Angreifer übernimmt eine Session, die bereits vollständig authentifiziert ist – einschließlich aller MFA-Faktoren, die beim ursprünglichen Login verwendet wurden. Die Schutzfunktion von MFA wird technisch umgangen, ohne dass sie deaktiviert werden müsste.
Folgewirkungen im klinischen Netz
Hat ein Angreifer die SSLVPN-Session gekapert, erhält er Zugang zum internen Netzwerksegment, das der VPN-Tunnel freigibt. Je nach Netzwerkarchitektur bedeutet das:
- Zugang zu klinischen Informationssystemen (KIS, RIS, PACS)
- Erreichbarkeit von Medizingeräten im Netz
- Möglichkeit zur lateralen Bewegung in Richtung Domänencontroller oder Backup-Infrastruktur
- Ausgangspunkt für Ransomware-Deployment oder Datenexfiltration
Sofortmaßnahmen: Was jetzt zu tun ist
Die zeitliche Abfolge ist eindeutig: Der Patch existiert seit 7. Januar 2025, der öffentliche Exploit seit 28. Januar 2025. Einrichtungen, die noch nicht gepatcht haben, müssen davon ausgehen, dass der Exploit aktiv eingesetzt wird.
1. Sofortiger Patch – keine Ausnahmen
Spielen Sie das von SonicWall bereitgestellte Firmware-Update unverzüglich ein. Prüfen Sie alle SonicWall-Geräte in Ihrer Infrastruktur, inklusive:
- Perimeter-Firewalls
- Branch-Office-Firewalls
- Geräte, die von Dienstleistern oder IT-Partnern betrieben werden (Supply-Chain-Risiko)
Wenn ein sofortiger Patch aus Betriebsgründen nicht möglich ist: Deaktivieren Sie die SSLVPN-Funktion bis zur Einspielung des Updates. Ein temporär unterbrochener Remote-Zugang ist deutlich vorzuziehen gegenüber einem kompromittierten Netz.
2. SSLVPN-Funktion deaktivieren, falls Patch nicht sofort möglich
Sollte der Patch aus betrieblichen oder organisatorischen Gründen (z. B. geplantes Wartungsfenster) nicht sofort eingespielt werden können, sollte die SSLVPN-Komponente interim abgeschaltet werden. Dokumentieren Sie diese Entscheidung und die Begründung.
3. Aktive Sessions auswerten und beenden
Prüfen Sie alle aktuell aktiven SSLVPN-Sessions und beenden Sie diese. Analysieren Sie die Session-Logs auf Anomalien:
- Ungewöhnliche Quell-IP-Adressen
- Sessions außerhalb normaler Arbeitszeiten
- Mehrere gleichzeitige Sessions desselben Benutzerkontos
- Geografisch inkonsistente Login-Standorte
Falls ein SIEM-System vorhanden ist, sollten entsprechende Korrelationsregeln für SSLVPN-Session-Anomalien aktiviert oder erstellt werden.
4. Netzwerkzugang des VPN-Tunnels prüfen
Analysieren Sie, auf welche Netzwerksegmente der SSLVPN-Tunnel Zugang gewährt. In vielen Einrichtungen sind VPN-Zugänge historisch gewachsen und geben mehr Zugang als operativ notwendig. Schränken Sie den Netzwerkzugang nach dem Prinzip der minimalen Rechte (Least Privilege) ein:
- Segmentierung: VPN-Nutzer sollten nur in dedizierte, isolierte Segmente landen
- Kein direkter Zugang zu kritischen Systemen wie Domänencontrollern oder Backup-Servern ohne zusätzliche Kontrollen
- Netzwerksegmentierung gemäß B3S-Anforderungen für Krankenhäuser umsetzen
5. Lieferanten und externe Dienstleister einbeziehen
Fragen Sie bei Ihren IT-Dienstleistern und Managed-Service-Providern aktiv nach, ob deren SonicWall-Systeme – insbesondere solche, die Zugang zu Ihren Netzen haben – gepatcht sind. Die SonicWall SSLVPN Sicherheitslücke ist auch ein Supply-Chain-Risiko: Ein kompromittierter Dienstleister kann als Einfallstor in Ihre Einrichtung dienen.
Meldepflichten und regulatorischer Kontext
Für Krankenhäuser in Deutschland ist die regulatorische Einordnung eines solchen Vorfalls relevant – sowohl präventiv als auch im Schadensfall.
NIS2UmsuCG und BSIG
Seit dem Inkrafttreten des NIS2-Umsetzungs- und Cybersicherheitsstärkungsgesetzes (NIS2UmsuCG) gelten für viele Krankenhäuser verschärfte Anforderungen. Gemäß §30 BSIG sind angemessene technische und organisatorische Maßnahmen zum Risikomanagement vorgeschrieben – dazu gehört explizit das zeitnahe Einspielen von Sicherheitsupdates für kritische Systeme.
Kommt es zu einem Sicherheitsvorfall, der auf die ausgenutzte Schwachstelle zurückzuführen ist, greifen die Meldepflichten nach §32 BSIG: Erhebliche Sicherheitsvorfälle sind dem BSI zu melden. Die Fristen sind eng – eine Erstmeldung ist innerhalb von 24 Stunden vorgesehen.
§391 SGB V
Für Krankenhäuser, die unter die Regelung des §391 SGB V fallen, gilt: Die dort geforderten Informationssicherheitsmaßnahmen umfassen ein aktives Schwachstellenmanagement. Eine bekannte, öffentlich exploitierbare Schwachstelle auf einem produktiven System ist ein klares Versäumnis im Sinne dieser Anforderung. Das schließt auch Systeme ein, die von Dienstleistern betrieben werden.
DSGVO-Meldepflicht
Sofern durch eine Ausnutzung der Schwachstelle personenbezogene Daten – insbesondere Gesundheitsdaten – abgeflossen oder unrechtmäßig zugänglich geworden sind, besteht eine Meldepflicht gegenüber der zuständigen Datenschutzaufsichtsbehörde innerhalb von 72 Stunden gemäß Art. 33 DSGVO. Zusätzlich kann eine Benachrichtigungspflicht gegenüber Betroffenen nach Art. 34 DSGVO bestehen.
Hinweis: Für eine rechtlich verbindliche Einschätzung der Meldepflichten in Ihrem konkreten Fall wenden Sie sich an einen auf Datenschutz- und IT-Recht spezialisierten Anwalt.
Lehren für das ISMS: Was diese Schwachstelle zeigt
CVE-2024-53704 ist kein Einzelfall – sie steht exemplarisch für eine Klasse von Schwachstellen, die für Gesundheitseinrichtungen besonders gefährlich ist. Drei strukturelle Lehren lassen sich ziehen:
MFA allein ist kein Perimeterschutz
Die Annahme, dass MFA Remote-Zugänge vollständig absichert, ist technisch falsch. MFA schützt den Authentifizierungsvorgang – nicht die Session nach erfolgter Authentifizierung. Ergänzende Maßnahmen wie Session-Timeouts, kontinuierliches Session-Monitoring und Zero-Trust-Ansätze (kontinuierliche Verifikation, nicht nur beim Login) sind notwendig.
Patch-Management braucht klare SLAs
Das Zeitfenster zwischen Veröffentlichung des Patches (7. Januar) und des Exploits (28. Januar) betrug drei Wochen. Das ist ein enges, aber realistisches Zeitfenster für Patch-Deployment. Einrichtungen, die keine definierten Service Level Agreements (SLAs) für kritische Patches haben, sollten diese im Rahmen ihres ISMS nach ISO 27001 (Annex A.8.8: Management of technical vulnerabilities) oder BSI IT-Grundschutz (OPS.1.1.3: Patch- und Änderungsmanagement) etablieren. Empfehlung: CVSS ≥ 7.0 → Patch innerhalb von 72 Stunden auf produktiven Systemen.
Netzwerksegmentierung reduziert den Blast Radius
Hätte ein Angreifer die Session gekapert, aber nur Zugang zu einem strikt isolierten VPN-Segment ohne Querverbindungen erhalten, wären die Folgeschäden begrenzt geblieben. Die konsequente Netzwerksegmentierung – gefordert im B3S für Krankenhäuser und im BSI IT-Grundschutz – ist kein Nice-to-have, sondern eine der wirksamsten Maßnahmen zur Schadenbegrenzung.
Checkliste: Sofortmaßnahmen CVE-2024-53704
| Maßnahme | Priorität | Status |
|---|---|---|
| SonicOS-Version aller Firewalls inventarisieren | Kritisch | ☐ |
| Patch auf betroffenen Systemen einspielen | Kritisch | ☐ |
| SSLVPN temporär deaktivieren (falls Patch verzögert) | Kritisch | ☐ |
| Alle aktiven SSLVPN-Sessions beenden und analysieren | Hoch | ☐ |
| Session-Logs auf Anomalien prüfen | Hoch | ☐ |
| VPN-Netzwerkzugang auf minimale Segmente beschränken | Hoch | ☐ |
| Dienstleister/MSP zu Patch-Status befragen | Hoch | ☐ |
| Incident-Response-Prozess prüfen (Meldepflichten) | Mittel | ☐ |
| SIEM-Regeln für SSLVPN-Anomalien anpassen | Mittel | ☐ |
| Dokumentation und Nachweis der Maßnahmen | Mittel | ☐ |
Fazit
Die SonicWall SSLVPN Sicherheitslücke CVE-2024-53704 illustriert, wie schnell aus einer theoretischen Schwachstelle ein operativ einsetzbarer Exploit wird. Für Krankenhäuser und Kliniken