Ivanti EPMM Sicherheitslücke: Zero-Day aktiv ausgenutzt
Mobilgeräte-Management-Systeme gehören zur kritischen IT-Infrastruktur eines Krankenhauses – und genau dort trifft die aktuelle Ivanti EPMM Sicherheitslücke mit besonderer Wucht. Am 13. Mai 2025 veröffentlichte Ivanti ein Advisory zu zwei aktiv ausgenutzten Zero-Day-Schwachstellen in seiner MDM-Lösung Endpoint Manager Mobile (EPMM), die vormals unter dem Namen MobileIron bekannt war. Das BSI stufte den Vorfall mit Kritikalität 3 ein und veröffentlichte am 13. Juni 2025 eine Cybersicherheitswarnung. Für Krankenhäuser und Kliniken, die EPMM zur Verwaltung mobiler Endgeräte einsetzen, besteht unmittelbarer Handlungsbedarf.
Was ist passiert: Zwei Schwachstellen, ein kritisches Zusammenspiel
Die Ivanti EPMM Sicherheitslücke basiert nicht auf einem einzelnen Fehler, sondern auf dem kombinierten Ausnutzen zweier Schwachstellen in Open-Source-Bibliotheken, die von EPMM intern genutzt werden. Das macht die Lage besonders heikel: Beide Lücken wurden durch Drittkomponenten eingebracht, die Ivanti selbst nicht unmittelbar kontrolliert. Die betreffenden Bibliotheks-Hersteller hatten zum Zeitpunkt des BSI-Berichts noch keine eigenen CVE-Kennungen vergeben – Ivanti hat die Nummern eigenständig publiziert.
CVE-2025-4427 betrifft eine fehlerhafte Authentifizierungslogik (CWE-288). Ein nicht authentifizierter Angreifer kann damit auf geschützte API-Ressourcen zugreifen, die eigentlich eine gültige Anmeldung erfordern. CVSS v3.0-Score: 5.3 (mittel). Für sich genommen bereits ein ernst zu nehmendes Problem – in Kombination mit der zweiten Lücke aber der Türöffner für vollständige Systemkompromittierung.
CVE-2025-4428 ermöglicht Remote Code Execution (RCE) durch externe, authentifizierte Angreifer (CWE-94). CVSS v3.0-Score: 7.2 (hoch). Diese Schwachstelle allein würde eine vorherige Authentifizierung voraussetzen – eine Hürde, die CVE-2025-4427 vollständig überbrückt.
Die Angriffskette im Überblick:
- Angreifer nutzt CVE-2025-4427, um den Authentifizierungsmechanismus zu umgehen
- Im Kontext eines scheinbar authentifizierten Nutzers wird CVE-2025-4428 ausgelöst
- Beliebiger Code wird auf dem EPMM-Server remote ausgeführt
- Vollständige Kontrolle über das MDM-System und potenziell alle verwalteten Endgeräte
Ivanti gibt an, eine „limitierte Anzahl an Angriffen" beobachtet zu haben. Diese Formulierung ist aus forensischer Sicht mit Vorsicht zu genießen: Sie sagt nichts darüber aus, wie viele Angriffe tatsächlich unentdeckt geblieben sind.
Warum Krankenhäuser besonders exponiert sind
EPMM, früher MobileIron, ist in vielen deutschen Krankenhäusern im Einsatz – nicht zuletzt weil MDM-Lösungen durch den digitalen Wandel und den Betrieb von Tablets, Smartphones und klinischen Wearables an Bedeutung gewonnen haben. Gleichzeitig sind MDM-Systeme strukturell privilegiert: Sie verwalten Zertifikate, E-Mail-Profile, VPN-Konfigurationen und können auf verwaltete Geräte remote zugreifen oder diese löschen.
Ein kompromittiertes EPMM-System gibt Angreifern potenziell Zugriff auf:
- Alle verwalteten mobilen Endgeräte im Netzwerk, inklusive Kliniktabletts und Ärztetelefone
- Zugangsdaten und Konfigurationsprofile, die auf den Geräten hinterlegt sind
- E-Mail- und Kalenderkonten von medizinischem Personal
- VPN-Zugangsdaten, die als Gateway ins Krankenhausinternetz dienen können
- Interne Netzwerksegmente, sofern keine konsequente Segmentierung umgesetzt ist
Krankenhäuser, die unter §391 SGB V als Betreiber kritischer Infrastruktur im Gesundheitswesen eingestuft sind oder unter das NIS2UmsuCG fallen, haben darüber hinaus spezifische Nachweis- und Meldepflichten, die bei einem Sicherheitsvorfall dieser Art unmittelbar greifen. Hinzu kommt die DSGVO-Relevanz: Werden Patientendaten auf verwalteten Geräten durch eine MDM-Kompromittierung zugänglich, liegt eine meldepflichtige Datenpanne im Sinne von Art. 33 DSGVO vor.
Sofortmaßnahmen: Was jetzt zu tun ist
Wenn Sie EPMM in Ihrer Einrichtung betreiben, gilt: Handeln Sie jetzt, nicht nach der nächsten Patchrunde. Die aktive Ausnutzung dieser Schwachstellen ist vom BSI bestätigt.
1. Patchstand prüfen und sofort aktualisieren
Ivanti hat Patches für die betroffenen Versionen bereitgestellt. Prüfen Sie umgehend, welche EPMM-Version in Ihrer Umgebung betrieben wird, und spielen Sie den Sicherheitspatch ein, sofern nicht bereits geschehen. Die Details zu betroffenen Versionen und Patches finden Sie im offiziellen Ivanti Security Advisory (IVAN25a/IVAN25b).
2. Zugriff auf die EPMM-Administrationsoberfläche einschränken
Ist die EPMM-Administrationsoberfläche aus dem Internet erreichbar? Falls ja: Schränken Sie den Zugriff sofort auf definierte IP-Adressen oder ein dediziertes Management-VLAN ein. Die EPMM-API sollte niemals ohne zusätzliche Absicherung aus dem Internet erreichbar sein.
3. Logfiles analysieren – Anzeichen für Kompromittierung suchen
Prüfen Sie die API-Zugriffslogs auf anomale, nicht authentifizierte Anfragen, die auf CVE-2025-4427 hindeuten könnten. Ivanti und das BSI empfehlen die Analyse der Serverprotokolle auf verdächtige Aktivitäten vor dem Patch-Datum.
Indikatoren, auf die Sie achten sollten:
- Unerwartete API-Calls ohne gültige Session-Token
- Zugriffe von unbekannten IP-Adressen auf die EPMM-API
- Ungewöhnliche Prozessaufrufe auf dem EPMM-Server (Hinweis auf RCE-Ausnutzung)
- Änderungen an MDM-Profilen oder Zertifikaten, die nicht dokumentiert sind
4. Netzwerksegmentierung überprüfen
MDM-Server sollten in einem dedizierten Segment betrieben werden, das keine direkte Verbindung zu klinischen Systemen, KIS oder PACS hat. Prüfen Sie, ob Ihr EPMM-Server lateral erreichbar ist und ob entsprechende Firewall-Regeln korrekt konfiguriert sind.
5. Incident-Response-Prozess aktivieren, falls Kompromittierung nicht ausgeschlossen
Können Sie eine Kompromittierung nicht sicher ausschließen, aktivieren Sie Ihren Incident-Response-Prozess. Isolieren Sie den EPMM-Server, sichern Sie Logs und eskalieren Sie intern an CISO und IT-Leitung.
Meldepflichten: Was bei einem Vorfall gilt
Für Krankenhäuser in Deutschland ist die regulatorische Dimension bei einem MDM-Sicherheitsvorfall nicht zu unterschätzen.
Nach §32 BSIG (in der Fassung durch das NIS2UmsuCG) sind wesentliche und wichtige Einrichtungen verpflichtet, erhebliche Sicherheitsvorfälle innerhalb von 24 Stunden mit einer Erstmeldung an das BSI zu übermitteln, gefolgt von einer detaillierten Folgemeldung binnen 72 Stunden. Krankenhäuser, die seit dem Inkrafttreten des NIS2UmsuCG als wesentliche Einrichtungen eingestuft sind, unterliegen dieser Pflicht.
Nach §391 SGB V müssen Krankenhäuser, die als KRITIS-Betreiber im Gesundheitswesen gelten, erhebliche IT-Sicherheitsvorfälle dem BSI melden. Die Schwelle für „erheblich" ist bei einer bestätigten Remote Code Execution auf einem MDM-Server in der Regel überschritten.
Nach Art. 33 DSGVO besteht eine Meldepflicht gegenüber der zuständigen Datenschutzaufsichtsbehörde binnen 72 Stunden, wenn durch den Vorfall personenbezogene Daten – insbesondere Gesundheitsdaten nach Art. 9 DSGVO – betroffen sein könnten.
Wichtiger Hinweis: Dieser Artikel stellt keine Rechtsberatung dar. Für eine verbindliche rechtliche Einschätzung Ihrer Meldepflichten im konkreten Einzelfall wenden Sie sich an einen auf IT-Recht und Datenschutz spezialisierten Anwalt.
Strukturelle Lehren: Supply Chain Risk im MDM-Bereich
Die Ivanti EPMM Sicherheitslücke ist kein Einzelfall – und sie offenbart ein systemisches Problem, das über diesen konkreten Vorfall hinausgeht: die mangelnde Transparenz über Open-Source-Abhängigkeiten in kommerzieller Software.
Beide Schwachstellen entstammen Drittbibliotheken. Das bedeutet: Selbst wenn Ihnen das BSI keine Warnung zu Ivanti EPMM schickt, können ähnliche Konstellationen in anderen Produkten Ihrer IT-Landschaft latent vorhanden sein. Für ein belastbares ISMS im Krankenhaus ergeben sich daraus mehrere strukturelle Anforderungen:
Software Bill of Materials (SBOM): Fordern Sie von kritischen IT-Lieferanten eine SBOM an, die alle verwendeten Drittkomponenten dokumentiert. ISO 27001 in Verbindung mit ISO 27036 (Lieferantensicherheit) sowie der B3S Krankenhaus sehen entsprechende Anforderungen an das Lieferantenmanagement vor.
Vulnerability Management mit SBOM-Abgleich: Ein reifes Schwachstellenmanagement beschränkt sich nicht auf CVE-Scans gegen Standardprodukte. Es berücksichtigt auch Abhängigkeiten in eingesetzten Lösungen. Tools wie Dependency-Track oder kommerzielle Lösungen können dabei unterstützen.
Patch-SLA für MDM-Systeme: MDM-Lösungen sollten in Ihrer Patch-Priorisierung als Tier-1-Systeme geführt werden. Ein Kompromiss auf dieser Ebene hat Auswirkungen auf alle verwalteten Endgeräte. Definieren Sie in Ihrer Security Policy explizite SLAs für sicherheitskritische Patches auf MDM-Infrastruktur – bei aktiv ausgenutzten Zero-Days sollte die Frist maximal 24–48 Stunden betragen.
Regelmäßige Überprüfung extern exponierter Systeme: Führen Sie mindestens quartalsweise ein Inventory aller Systeme durch, die aus dem Internet erreichbar sind oder als Proxy für externe Verbindungen fungieren. MDM-Systeme mit externer API-Erreichbarkeit sind ein wiederkehrendes Angriffsziel.
Checkliste: Sofortmaßnahmen bei Ivanti EPMM
| Maßnahme | Priorität | Status |
|---|---|---|
| EPMM-Version prüfen und Patch einspielen | Kritisch / sofort | ☐ |
| API-Zugriff auf vertrauenswürdige IPs beschränken | Kritisch / sofort | ☐ |
| API-Logs auf Anomalien analysieren (vor Patch-Datum) | Hoch / heute | ☐ |
| Netzwerksegmentierung EPMM-Server verifizieren | Hoch / heute | ☐ |
| EPMM extern erreichbar? Ggf. Zugang sperren | Kritisch / sofort | ☐ |
| Incident-Response-Prozess: Kompromittierung ausgeschlossen? | Hoch / heute | ☐ |
| BSI-Meldung prüfen (§32 BSIG / §391 SGB V) | Hoch / 24h | ☐ |
| Datenschutz-Folgenabschätzung / Art. 33 DSGVO prüfen | Hoch / 72h | ☐ |
| SBOM-Anforderung für zukünftige Lieferantenverträge prüfen | Mittel / nächste Woche | ☐ |
| Patch-SLA für MDM-Systeme in Security Policy aufnehmen | Mittel / nächste Woche | ☐ |
Wenn Sie eine strukturierte Bewertung Ihrer aktuellen Sicherheitslage benötigen, bietet das ISMShield Self-Assessment einen ersten Orientierungsrahmen speziell für Einrichtungen im Gesundheitswesen.