VAU-Server-Authentifizierungs-Bypass

Beschreibung

public byte[] receiveMessage2(byte[] message2) {
    return vauStateMachine.receiveMessage2(message2);
}

VauPublicKeys transferredSignedServerPublicKeyList = signedPublicVauKeys.extractVauKeys();
checkCertificateExpired(transferredSignedServerPublicKeyList.getExp());

Auswirkung

• Ein netzwerkpositionierter Angreifer zwischen epa4all und dem ePA-Aktensystem fängt den VAU-Handshake ab, liefert selbstsignierte VAU-Public-Keys mit einem selbstsignierten Zertifikat aus, und der Client akzeptiert beides. Der Angreifer leitet dieselben K2-Sitzungsschlüssel ab wie der Client und kontrolliert den resultierenden verschlüsselten Kanal.
• Im produktiven Bereitstellungsmodell passt das Angreifermodell ins Praxisnetz. epa4all wird als On-Premise-Docker-Container (servicehealtherxgmbh/epa4all) ausgeliefert, der in einer Arztpraxis betrieben wird; der Container ist aus dem lokalen Netz erreichbar und baut die ausgehende Verbindung zum ePA-Backend auf.
• Ein MITM, der die Sitzungsschlüssel hält, kann den gesamten inneren HTTP-Verkehr auf dem VAU-Kanal lesen und verändern: Einwilligungsentscheidungen, Medikationsdaten, Dokument-Uploads, Autorisierungs-Token und Anspruchsabfragen. Während eines Testlaufs las ein einzelner Relay die Einwilligungsentscheidungen einer Betroffenen, tauschte auf einer zweiten Antwort Versicherten-ID und Entscheidungswerte aus und schleuste einen dritten Patientendatensatz vollständig ein, alles mit einem selbstsignierten Zertifikat ohne CA-Kette.

Abhilfe

Aktualisieren Sie auf einen Build vom 20.05.2026 oder später. Der Fix des Herstellers ergänzt Zertifikats- und Hostname-Prüfungen für lib-vau sowie einen Keystore auf Basis der Telematik-TSL, sodass die ES256-Signatur auf SignedPublicVauKeys gegen ein vertrauenswürdiges Zertifikat aus der TI-PKI geprüft wird. Für betroffene Builds existiert kein Workaround; ein Pinning auf Transportebene authentifiziert den VAU-Server nicht, und die parallele Schwachstelle med-united: TLS-Zertifikatsprüfung deaktiviert bedeutet, dass es ohnehin kein Transport-Pinning gibt, auf das man sich stützen könnte. Beide Fixes sind erforderlich.

Checkliste für Betreiber

• Auf den Build vom 20.05.2026 oder später aktualisieren.

  Alle 1.0.0-SNAPSHOT-Builds vor diesem Datum sind betroffen. Der Fix ergänzt den Telematik-TSL-Keystore und hängt die Signaturprüfung auf SignedPublicVauKeys clientseitig ein.

• Prüfen, dass die TI-PKI-Root-Anchors zur Laufzeit geladen werden.

  Der Standard-JVM-/System-Truststore enthält keine TI-PKI-Roots. Stellen Sie sicher, dass Ihr Deployment sie aus dem TI-Root-CA-Bundle des gemSpec_PKI bezieht und dass der Keystore vor dem ersten VAU-Handshake geladen ist.

• Diesen Fix mit dem TLS-Prüfungs-Fix kombinieren.

  Auch mit ergänzter VAU-Server-Authentifizierung muss im selben Build die TLS-Prüfung auf den ausgehenden Verbindungen wieder aktiviert werden. Die beiden Fixes sind unabhängig und beide erforderlich; siehe med-united: TLS-Zertifikatsprüfung deaktiviert.

• 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-vvh7-x6c7-46gh (med-united)
• med-united-epa4all-Repository
• gematik lib-vau (Referenz, eingebunden)
• gemSpec_Krypt A_24624-01 (Client-Prüfung der signierten öffentlichen Server-Schlüssel)
• Verwandt: Deaktivierte TLS-Zertifikatsprüfung
• Verwandter Upstream: VAU-Handshake führt nur 2 von 6 vorgeschriebenen Server-Schlüssel-Prüfungen aus
• Verwandt: ePA-VAU-Client-Sicherheit (Übersicht)

So können wir helfen

• MDR-Penetrationstests