VAU-Server-Authentifizierungs-Bypass durch zirkuläres Zertifikatsvertrauen

Beschreibung

cert_endpoint = urljoin(self.AS_URL, f"/CertData.{cert_hash_hex}-{cdv}")
cert_data_response = self.https_session.get(
    cert_endpoint,
    verify=False,
    headers={"x-useragent": USER_AGENT},
)

self.vau_cert_validation(signed_vau_server_pub_keys)

pub_keys = cbor2.loads(signed_vau_server_pub_keys["signed_pub_keys"])

required_fields = ["cert", "ca", "rca_chain"]
if not all(field in cert_data for field in required_fields):
    logger.error("Missing required fields in CertData")
    return False

Auswirkung

• Ein netzwerkpositionierter Angreifer zwischen DiGA-Backend und ePA-Aktensystem fängt den VAU-Handshake ab, liefert eigene VAU-Public-Keys und ein selbstsigniertes Zertifikat aus und kontrolliert die resultierenden Session-Keys. Der gesamte innere HTTP-Verkehr (Medikationsdaten, Diagnoseberichte, Verordnungshistorie, Dokumenten-Reads und -Writes, Autorisierungstransaktionen) wird damit für den Angreifer lesbar und veränderbar.
• Weder Transport- noch Anwendungsschicht authentifizieren den Server. Die TLS-Prüfung ist in der Bibliothek deaktiviert (siehe fbeta: TLS-Zertifikatsprüfung universell deaktiviert) und die VAU-Zertifikatsprüfung ist zirkulär; weder Transport- noch Anwendungsschicht authentifiziert den Server auf dem Patientendaten-Kanal.
• Ein MITM, der die Session-Keys hält, kann den gesamten inneren HTTP-Verkehr auf dem VAU-Kanal lesen und modifizieren. Während eines Testlaufs las ein einzelner Relay die Einwilligungsentscheidungen dreier Versicherter, modifizierte die Antworten und schleuste einen dritten Patientendatensatz ein, alles mit einem selbstsignierten Zertifikat ohne CA-Kette.

Abhilfe

Aktualisieren Sie fbeta ePA3-Service-OpenSource auf 1.3.0 oder höher. Der Fix setzt die Zertifikatsketten-Prüfung gegen den TI-PKI-Root um, liest den Rückgabewert von vau_cert_validation() aus und bricht bei Fehlschlag ab, und ergänzt die übrigen A_24624-01-Prüfungen (cert_hash-Integrität gegen SHA-256(cert_der), zeitliche Gültigkeit, OCSP sowie die Rollen-OID oid_epa_vau). TI-PKI-Root-Zertifikate liegen nicht im Standard-Truststore des Systems; sie müssen aus der veröffentlichten TI-PKI von gematik (gemSpec_PKI, Anhang TI-Root-CA) bezogen und explizit gepinnt werden.

Checkliste für Betreiber

• Auf fbeta ePA3-Service-OpenSource 1.3.0 oder höher aktualisieren.

  Alle Versionen vor 1.3.0 sind betroffen; zwischen 1.0.1 und dem Fix gibt es keine Zwischenreleases. Der Fix liegt in Pull Request #12.

• Prüfen, dass die Trust-Anchors tatsächlich ausgeliefert werden.

  Der Fix benötigt die TI-PKI-Root-Zertifikate zur Laufzeit. Stellen Sie sicher, dass Ihr Deployment sie aus dem TI-Root-CA-Bundle des gemSpec_PKI lädt und nicht aus dem Standard-Truststore des Systems, der sie nicht enthält.

• Eigene Aufrufer von vau_cert_validation() prüfen.

  Wenn Sie einen Fork oder einen abgeleiteten Wrapper dieser Bibliothek pflegen, prüfen Sie jede Aufrufstelle: Der boolesche Rückgabewert muss gelesen werden, und ein Fehlschlag muss den Handshake abbrechen. Ein verworfener Rückgabewert entspricht keiner Prüfung.

• Mit selbstsigniertem Gegenpart testen.

  Bauen Sie einen lokalen VAU-Gegenpart, der auf Message 2 mit angreiferkontrollierten öffentlichen Schlüsseln, selbstsigniertem cert und beliebigen signatureEs256-Bytes antwortet. Der Client muss den Handshake ablehnen. Falls nicht, ist der Validator nicht eingehängt.

Bewertung im Detail

Referenzen

• GHSA-q2jw-6c4w-86jc (fbeta)
• fbeta-ePA3-Service-OpenSource-PR #12 (Fix)
• fbeta-ePA3-Service-OpenSource-Repository
• gemSpec_Krypt A_24624-01 (Client-Prüfung der signierten öffentlichen Server-Schlüssel)
• Verwandt: Deaktivierte TLS-Zertifikatsprüfung
• Verwandter Upstream: Fehlende VAU-Server-Authentifizierung in gematik lib-vau
• Verwandt: ePA-VAU-Client-Sicherheit (Übersicht)

So können wir helfen

• MDR-Penetrationstests