|
10.09.2026 14:53 Uhr |
Mehrere frei verfügbare Softwarekomponenten für die Anbindung an die elektronische Patientenakte wiesen im Frühjahr 2026 Sicherheitslücken in zentralen Schutzmechanismen auf. Betroffen waren drei unabhängig voneinander entwickelte Open-Source-Implementierungen: der ePA3-Service von fbeta, Ovivas epa4all-client sowie epa4all von Med United (service health erx).
Die Fehler betrafen den sogenannten VAU-Kanal – also die Verbindung zur vertrauenswürdigen Ausführungsumgebung (VAU). Dabei handelt es sich um eine zusätzliche kryptografische Schicht, die Gesundheitsdaten zwischen ePA-Client und Aktensystem absichern soll.
Die Schwachstellen reichten von unvollständigen Prüfungen der Serveridentität über Probleme bei kryptografischen Zählern bis hin zu deaktivierten TLS-Zertifikatsprüfungen. Nach Responsible-Disclosure-Meldungen durch die Sicherheitsforscher von Machine Spirits wurden alle Lücken behoben; Hinweise auf eine tatsächliche Ausnutzung liegen nicht vor. In der Praxis dürfte der Kreis potenziell Betroffener zudem sehr klein gewesen sein: fbeta zählte zum Zeitpunkt des Fundes nur einen produktiven DiGA-Kunden mit sehr seltenen ePA-Exporten, Med United verweist auf wenige Supportkunden außerhalb des DiGA-Bereichs, und Oviva schützte die Verbindungsstrecken mit zusätzlichen TLS- und VPN-Tunneln.
Die Gematik weist darauf hin, dass ihre Bibliothek lib-vau / lib-vau-csharp ausschließlich für Testzwecke entwickelt worden sei. Sie sei ausdrücklich als nicht produktionsgeeignet gekennzeichnet gewesen; zudem habe die Dokumentation darauf hingewiesen, dass Zertifikate nicht geprüft werden. Für produktiv eingesetzte Software seien die jeweiligen Hersteller verantwortlich.
Die Sicherheitsforscher teilen diese Einordnung mit Blick auf die unmittelbare technische Verantwortung. Zugleich wirft der Fall die weitergehende Frage auf, welche Rolle sicherheitskritischer Beispielcode in einem komplexen Ökosystem spielt – gerade dann, wenn sich mehrere unabhängige Hersteller an ähnlichen Stellen vertun.
Wie die Sicherheitslücken entdeckt wurden und welche Lehren sich daraus ziehen lassen, erklärt Dr. Simon Weber, der unter anderem an der Heinrich-Heine-Universität in Düsseldorf studierte, im Gespräch mit heise online. Weber fand die Lücken gemeinsam mit dem Sicherheitsforscher und Diplom-Informatiker Volker Schönefeld bei Machine Spirits.
Wir schauen uns deshalb auch Open-Source-Komponenten an, die in üblichen Pentests leicht unter dem Radar bleiben. Angefangen hatten wir mit dem Gematik-Authenticator, den ich noch aus dem Krankenhausumfeld kannte. Darüber sind wir auf weitere Referenzimplementierungen der Gematik gestoßen – darunter lib-vau.
Die VAU war dann besonders naheliegend, weil sie genau für den Fall gedacht ist, dass die äußere TLS-Verschlüsselung an einem Proxy oder Load Balancer endet: Sie soll die Gesundheitsdaten trotzdem Ende zu Ende absichern. Wir haben deshalb das Angriffsszenario nachgebaut, vor dem sie schützen soll – ein Angreifer sitzt auf diesem Übertragungsweg – und geprüft, ob die Implementierungen dann tatsächlich sicher reagieren.
Bei DiGA wäre das der Weg zwischen dem Backend der DiGA und dem Aktensystem. Bei einer Krankenkassen-App wäre es entsprechend die Strecke zwischen dem ePA-Frontend und dem Aktensystem. Die VAU soll gerade für den Fall schützen, dass die äußere TLS-Schicht an einer Stelle nicht mehr durchgängig greift.
Zweitens ging es um die Verschlüsselung der einzelnen Nachrichten. Jede Nachricht muss eindeutig verschlüsselt werden. Das war nicht in allen Fällen zuverlässig sichergestellt. Wenn kryptografische Werte wiederverwendet werden, kann das die Verschlüsselung schwächen.
Und drittens haben wir bei den geprüften Implementierungen festgestellt, dass die TLS-Authentifizierung deaktiviert war. Nicht TLS insgesamt, das ist wichtig. Die Verbindung war weiterhin verschlüsselt. Aber die Prüfung, ob man wirklich mit dem richtigen Gegenüber spricht, war deaktiviert. Damit hatte man in diesen Fällen keine zusätzliche Schutzschicht mehr, die Fehler im VAU-Kanal abfangen könnte.