Ivanti Schwachstellen: Aktive Angriffe auf CSA stoppen

Einleitung

Seit dem 19. September 2024 warnt Ivanti offiziell vor aktiv ausgenutzten Schwachstellen in der Cloud Services Appliance (CSA). Das BSI stuft die Bedrohungslage mit Kritikalität 2 ein – und das zu Recht: Angreifer kombinieren zwei CVEs, um Authentifizierung zu umgehen und anschließend beliebigen Code auszuführen. Für Krankenhäuser und Kliniken, die Ivanti CSA im Einsatz haben, besteht dringender Handlungsbedarf. Dieser Artikel analysiert die Ivanti Schwachstellen Sicherheit, erklärt die technischen Zusammenhänge und gibt konkrete Empfehlungen für die Sofortmaßnahmen und die strukturelle Absicherung.

Was ist passiert: Die Schwachstellen im Überblick

Am 13. September 2024 veröffentlichte Ivanti erste Hinweise auf eine aktiv ausgenutzte Schwachstelle in der Cloud Services Appliance. Eine Woche später, am 19. September 2024, erweiterte das Unternehmen seine Warnung erheblich: Angreifer kombinieren seither zwei Schwachstellen zu einer gefährlichen Angriffskette.

CVE-2024-8963 – Path Traversal / Authentifizierungsumgehung (CVSS 9.4 – kritisch)

Diese Schwachstelle ermöglicht es nicht authentifizierten Angreifern aus dem Netzwerk, die Nutzer-Authentifizierung der CSA vollständig zu umgehen. Mit einem CVSS-Score von 9.4 in Version 3.0 wird sie vom Common Vulnerability Scoring System als kritisch eingestuft. Die Lücke liegt in der Art, wie die CSA bestimmte URL-Pfade verarbeitet – durch manipulierte Anfragen gelangt ein Angreifer an Ressourcen, die eigentlich eine Authentifizierung erfordern.

CVE-2024-8190 – Remote Code Execution (CVSS 7.2 – hoch)

Diese Schwachstelle allein erfordert bereits authentifizierten Zugriff mit Administratorrechten – was ihre Gefährlichkeit auf dem Papier zunächst begrenzt. In der Praxis jedoch ändert sich das Bild drastisch, sobald CVE-2024-8963 im Spiel ist.

Die Kombination: Ein kritischer Angriffspfad

Das eigentliche Risiko liegt in der Kombination beider Schwachstellen: Angreifer nutzen zuerst CVE-2024-8963, um die Authentifizierung zu überwinden, und erlangen damit die notwendigen Privilegien, um anschließend über CVE-2024-8190 beliebigen Code auf dem Zielsystem auszuführen. Der Angriff ist damit vollständig remote und ohne vorherige Anmeldedaten durchführbar – ein klassisches und besonders gefährliches Szenario.

Das BSI hat diese Kombination in seiner Cybersicherheitswarnung (2024-274385-1032) vom 20. September 2024 explizit dokumentiert und Organisationen dringend zum Handeln aufgefordert.

Warum Krankenhäuser besonders im Fokus stehen

Ivanti CSA ist eine Netzwerk-Gateway-Lösung, die häufig an der Schnittstelle zwischen internen Systemen und externem Zugriff eingesetzt wird – typischerweise für Remote-Access, VPN-Ersatz oder privilegierten Fernzugriff. In Krankenhäusern und Kliniken bedeutet das: Ein kompromittiertes CSA-System sitzt potenziell direkt vor klinischen Systemen, Krankenhausinformationssystemen (KIS), PACS oder Medizingeräte-Netzwerken.

Erhöhte Angriffsfläche durch externe Anbindungen

Gerade seit der Corona-Pandemie haben viele Häuser Remote-Access-Lösungen ausgebaut – für Home-Office-Verwaltung, Telemedizin und den Fernzugriff externer Dienstleister. Viele dieser Zugangswege laufen über Appliances wie die Ivanti CSA. Eine erfolgreiche Kompromittierung gibt Angreifern einen Brückenkopf ins Netzwerk.

Regulatorische Meldepflichten greifen sofort

Für Krankenhäuser der KRITIS-Kategorie (Schwellenwert: 30.000 vollstationäre Behandlungsfälle pro Jahr) gelten seit Inkrafttreten des NIS2UmsuCG verschärfte Meldepflichten nach §32 BSIG. Eine aktiv ausgenutzte Schwachstelle in einem exponierten System ist ein meldepflichtiger Vorfall. Die Fristen sind eng: Eine Erstmeldung beim BSI ist innerhalb von 24 Stunden nach Kenntnis eines erheblichen Sicherheitsvorfalls erforderlich.

Zusätzlich gelten für Krankenhäuser die Anforderungen nach §391 SGB V, der die IT-Sicherheit für Krankenhäuser spezifisch regelt. Seit der Verschärfung sind auch nicht-KRITIS-Häuser verpflichtet, nachweisbare Maßnahmen zur IT-Sicherheit umzusetzen. Ein ungepatchtes, extern erreichbares System mit bekannter kritischer Schwachstelle ist in diesem Kontext ein klares Audit-Risiko.

Technische Sofortmaßnahmen: Was jetzt zu tun ist

Die folgenden Maßnahmen sind nach Bekanntwerden der aktiven Ausnutzung priorisiert umzusetzen. Eine Risikobewertung ersetzt dies nicht – aber sie darf den Handlungsbeginn nicht verzögern.

1. Bestandsaufnahme und Expositionsprüfung

Identifizieren Sie sofort alle Ivanti CSA-Instanzen in Ihrer Infrastruktur:

  • Welche Versionen sind im Einsatz?
  • Sind die Systeme direkt aus dem Internet erreichbar?
  • Welche Netzwerksegmente liegen hinter der CSA?
  • Welche Systeme nutzen die CSA als Zugangspunkt?

Priorisieren Sie Instanzen, die direkt an Perimetern oder in DMZ-Segmenten betrieben werden.

2. Patch sofort einspielen

Ivanti hat Patches für die betroffenen Versionen bereitgestellt. Das Einspielen verfügbarer Sicherheitsupdates hat höchste Priorität. Beachten Sie dabei:

  • Prüfen Sie die Ivanti Security Advisory-Seite auf die aktuell empfohlene Patch-Version
  • Testen Sie im Staging-Umfeld, sofern zeitlich vertretbar – aber setzen Sie das nicht als Blocker für kritische Systeme
  • Dokumentieren Sie den Patch-Zeitpunkt für Compliance-Nachweise nach BSI Grundschutz und §391 SGB V

3. Netzwerkzugriff einschränken

Solange der Patch noch nicht eingespielt ist, sollten Sie den Zugriff auf die CSA-Administrationsoberfläche auf definierte, vertrauenswürdige IP-Adressen beschränken. Prüfen Sie zudem:

  • Ist der Verwaltungszugang von intern getrennt vom produktiven Nutzer-Traffic?
  • Gibt es Firewall-Regeln, die direkte Internetzugriffe auf Administrationspfade blockieren?
  • Sind IDS/IPS-Signaturen für CVE-2024-8963 und CVE-2024-8190 aktiv?

4. Indicators of Compromise prüfen

Bekannte Angriffsmuster für diese Schwachstellenkombination beinhalten:

  • Ungewöhnliche HTTP-Requests mit manipulierten Pfaden (Path Traversal-Muster)
  • Neue oder unbekannte Prozesse, die durch den CSA-Dienst gestartet wurden
  • Unerwartete ausgehende Verbindungen aus dem CSA-System
  • Unbekannte Benutzerkonten oder Änderungen an bestehenden Konten

Durchsuchen Sie Ihre SIEM-Logs auf entsprechende Indikatoren. Wenn Sie kein SIEM betreiben, prüfen Sie die Systemlogs der CSA-Appliance direkt.

5. Incident-Response-Plan aktivieren

Falls Indicators of Compromise identifiziert werden, ist der Incident-Response-Plan zu aktivieren. Isolieren Sie betroffene Systeme vom Netzwerk, sichern Sie forensische Beweise und prüfen Sie die Meldepflicht nach §32 BSIG. Für rechtliche Fragen zur Meldepflicht und Haftung wenden Sie sich an einen auf IT-Recht spezialisierten Anwalt.

Strukturelle Lehren für das ISMS

Der Fall Ivanti CSA ist kein Einzelereignis – er folgt einem bekannten Muster, das auch bei Pulse Secure, Citrix ADC und Fortinet FortiGate in den vergangenen Jahren zu beobachten war. Netzwerk-Gateways und Remote-Access-Appliances stehen bei Angreifern hoch im Kurs, weil sie:

  • direkt aus dem Internet erreichbar sind
  • privilegierte Zugangspunkte ins interne Netz darstellen
  • häufig seltener gepatcht werden als Serverbetriebssysteme
  • schwer in Standard-Monitoring-Konzepte integriert werden

Patch-Management als ISMS-Kernprozess

Nach BSI Grundschutz (OPS.1.1.3 – Patch- und Änderungsmanagement) ist ein funktionierender Patch-Prozess für alle IT-Systeme verpflichtend. Für Systeme mit Internetzugang und privilegiertem Netzwerkzugriff sollte der Patch-Zyklus verkürzt sein:

  • Kritische Schwachstellen (CVSS ≥ 9.0): Patch innerhalb von 24-72 Stunden oder Mitigationsmaßnahmen sofort
  • Hohe Schwachstellen (CVSS 7.0-8.9): Patch innerhalb von 7 Tagen
  • Mittel (CVSS 4.0-6.9): Patch im regulären Wartungsfenster

Diese Fristen sollten in Ihrer ISMS-Richtlinie für Vulnerability Management explizit definiert und regelmäßig auditiert werden.

Netzwerksegmentierung schützt im Angriffsfall

Hätten Angreifer die CSA erfolgreich kompromittiert, bestimmt die Netzwerksegmentierung, wie weit sie sich lateral bewegen können. Ein flaches Netzwerk ohne Segmentierung zwischen CSA, klinischen Systemen und Administrationsnetz ist ein kritisches Risiko.

Empfehlenswert ist eine Zonenarchitektur, die mindestens folgende Segmente trennt:

  • DMZ / Perimeter-Systeme (inkl. CSA)
  • Klinische Systeme (KIS, PACS, Medizingeräte)
  • Administrationsnetz
  • Nutzernetz (Arbeitsplätze)

Jede Kommunikation zwischen Zonen sollte explizit erlaubt und protokolliert sein.

Monitoring und Alerting für exponierte Systeme

Systeme mit direktem Internetzugang müssen in Ihrem SIEM besonders überwacht werden. Relevante Log-Quellen für die CSA:

  • Webserver-Access-Logs (Anomalie-Erkennung bei Path-Traversal-Mustern)
  • Authentifizierungslogs
  • Systemlogs für unbekannte Prozesse
  • Netzwerk-Flow-Daten für ausgehende Verbindungen

Wenn Sie noch kein vollständiges SIEM betreiben, prüfen Sie zumindest, ob kritische Systeme in ein zentrales Log-Management integriert sind. Für eine strukturierte Bewertung Ihrer aktuellen Sicherheitslage empfehlen wir das ISMShield-Assessment.

Checkliste: Ivanti CSA – Sofortmaßnahmen

# Maßnahme Priorität Status
1 Inventar: Alle Ivanti CSA-Instanzen identifiziert Kritisch ☐
2 Exposition geprüft: Internetzugang dokumentiert Kritisch ☐
3 Ivanti-Patch eingespielt (aktuelle Version) Kritisch ☐
4 Admin-Zugang auf vertrauenswürdige IPs eingeschränkt Hoch ☐
5 IDS/IPS-Signaturen für CVE-2024-8963 / -8190 aktiviert Hoch ☐
6 Logs auf Indicators of Compromise geprüft Hoch ☐
7 SIEM-Alerting für CSA-Anomalien konfiguriert Mittel ☐
8 Netzwerksegmentierung zwischen CSA und klinischen Systemen geprüft Mittel ☐
9 Meldepflicht nach §32 BSIG bewertet Hoch ☐
10 Vorfall dokumentiert (für ISMS-Audit) Mittel ☐
Kostenlose NIS2-Bestandsaufnahme starten →
Weitere Artikel im Wissensbereich