fbeta ePA3-Service-OpenSource
TLS-Zertifikatsprüfung universell deaktiviert
Jede HTTPS-Verbindung zum ePA-Aktensystem und zum Konnektor in fbetas ePA3-Service setzt verify=False, unbedingt über alle Umgebungen hinweg. Ein netzwerkpositionierter Angreifer kann das TLS des Clients mit einem beliebigen Zertifikat terminieren; auf der Konnektor-Session legt der Client zusätzlich seine mTLS-Smartcard-Credentials demjenigen vor, der antwortet.
Beschreibung
verify=False taucht an fünf Stellen in VAUProtokoll.py auf (Zeilen 99, 202, 271, 431, 581) und einmal auf Session-Ebene in Konnektor.py:44. Ein Quellkommentar erklärt die ursprüngliche Absicht (eine Verbindung zu einem selbstsignierten Entwicklungsendpunkt), doch keine Bedingung wurde je ergänzt, die die Lockerung gegen die Umgebung absichert:
VAUProtokoll.py:98 (Intentionskommentar)
# Um ein VAU-Kanal zu https://epa-as-2.dev.epa4all.de/ aufzubauen muss verify auf False gesetzt werden, da es sich um ein self-signed Zertifikat handeltDie Bibliothek unterstützt EPA_ENVIRONMENT = "PROD" (constants.py:48-52) ohne bedingte TLS-Prüfung; verify=False gilt überall, in jeder Umgebung. IDP-Verbindungen verwenden ein blankes requests.get(), das standardmäßig verify=True setzt; die Lockerung betrifft also gezielt die ePA- und Konnektor-Pfade.
Konnektor.py:44 (Lockerung auf Session-Ebene)
self.session.verify = FalseAuf der Konnektor-Session authentifiziert sich der Client per mTLS (self.session.cert = (self.cert, self.key)), prüft jedoch die Identität des Konnektors nicht. Ein Angreifer, der den Konnektor imitiert, erhält das mTLS-Zertifikat des Clients und sammelt anschließend die Smartcard-Operationen ein. Auf der Seite des ePA-Aktensystems ist dieses Finding der Transport-Layer-Enabler für den fbeta: VAU-Server-Authentifizierungs-Bypass durch zirkuläres Zertifikatsvertrauen; zusammen verbleibt keine Schicht Server-Authentifizierung auf dem Kanal, der Patientendaten trägt.
Auswirkung
- Jeder netzwerkpositionierte Angreifer (ARP-Spoofing, DNS-Poisoning, Rogue-AP, BGP-Hijack) kann die TLS-Verbindung des Clients zum ePA-Aktensystem mit einem beliebigen Zertifikat terminieren und so den gesamten ePA-Verkehr abfangen. TI-as-a-Service-Deployments routen ePA-Verkehr per TLS über das öffentliche Internet, genau das Bedrohungsmodell, das
verify=Trueadressiert. - Auf der Konnektor-Verbindung legt der Client seine mTLS-Smartcard-Credentials demjenigen vor, der antwortet. Ein Angreifer, der den Konnektor imitiert, sammelt diese Credentials und die anschließenden Smartcard-Operationen ein.
- In Kombination mit dem fbeta: VAU-Server-Authentifizierungs-Bypass durch zirkuläres Zertifikatsvertrauen entfernt dieses Finding die letzte verbleibende Schicht der Server-Authentifizierung. Eine einzige MITM-Position liest und modifiziert dann den gesamten inneren ePA-Verkehr.
Abhilfe
Aktualisieren Sie fbeta ePA3-Service-OpenSource auf 1.3.0 oder höher. Der Fix entfernt alle verify=False-Stellen und ersetzt sie durch passende CA-Bundles für die TI-Endpunkte, reaktiviert die Konnektor-Server-Prüfung mit einem Truststore, der das Konnektor-CA-Zertifikat enthält, und macht die TLS-Prüfung unbedingt, statt sie über EPA_ENVIRONMENT zu gaten. Für die Entwicklung gegen selbstsignierte Zertifikate ist die Entwicklungs-CA im Truststore zu hinterlegen, statt die Prüfung zu deaktivieren.
Checkliste für Betreiber
Auf fbeta ePA3-Service-OpenSource 1.3.0 oder höher aktualisieren.
Alle Versionen vor 1.3.0 sind betroffen. Der Fix liegt in Pull Request #9.
Das TI-PKI-Bundle mit dem Deployment ausliefern.
TI-PKI-Root-Zertifikate liegen nicht im Standard-Truststore des Systems. Beziehen Sie sie aus dem TI-Root-CA-Bundle des gemSpec_PKI und pinnen Sie sie für jede ePA- und Konnektor-Session.
Den eigenen Fork nach verify=False durchsuchen.
Führen Sie
grep -RIn 'verify=False\|session.verify\s*=\s*False' .gegen Ihr Deployment dieser Bibliothek oder einen Fork aus. Jeder Treffer auf einem produktiven Codepfad ist eine potenzielle Regression; Entwicklungspfade gehören explizit hinter ein Nicht-Produktions-Flag, nicht in den Standardpfad.Konnektor-Identität validieren, nicht nur die eigene.
mTLS ist beidseitig; eine einseitige Konfiguration leakt Credentials. Die Konnektor-Session muss per
verify=gegen einen CA-Store geprüft werden, der das Konnektor-Zertifikat enthält.
Bewertung im Detail
Referenzen
So können wir helfen
Wer wir sind
Die Sicherheitsforscher hinter diesem Sicherheitshinweis.
Dr. rer. nat. Simon Weber
Senior Pentester & MedSec-Forscher
Ich evaluiere Ihr SaMD mit derselben branchenprägenden Sicherheitsexpertise, die ich dem BAK MV für die Überarbeitung des B3S-Standards beigetragen habe.
- Promotion über Krankenhaus-Cybersicherheit
- Kritische Schwachstellen in Krankenhaussystemen gefunden
- Alumni der THB MedSec-Forschungsgruppe
- gematik Security Hero
Dipl.-Inf. Volker Schönefeld
Senior Application Security Expert
Als ehemaliger CTO und Entwickler, der zum Pentester wurde, arbeite ich mit Ihrem Team zusammen, um Schwachstellen aufzudecken und Lösungen zu finden, die zu Ihrer Architektur passen.
- 20+ Jahre als CTO, 50+ Mio. App-Downloads
- Architektur und Absicherung großer IoT-Flotten
- Certified Web Exploitation Specialist
- gematik Security Hero
Penetrationstest gesucht?
Machine Spirits ist spezialisiert auf Sicherheitsbewertungen für Medizinprodukte und Gesundheits-IT. Von MDR-Penetrationstests bis C5-Cloud-Compliance helfen wir MedTech-Unternehmen, regulatorische Anforderungen zu erfüllen.