VAU-Signature-Verification-Bypass

Beschreibung

var ecdsa = Signature.getInstance("SHA256withECDSA", BouncyCastleProvider.PROVIDER_NAME);
ecdsa.initVerify(certs.cert());
ecdsa.update(signedPublicKeys.signedPubKeys());

var signatureDer = ECDSA.transcodeSignatureToDER(signedPublicKeys.signatureEs256());
ecdsa.verify(signatureDer);

// fällt durch zu:
return true;

return sig.verify(derSignature);

Auswirkung

• Ein Angreifer im selben Netzwerk wie der ePA-Client (etwa im lokalen Klinik-Netzwerk, in dem der ePA-Konnektor steht) ersetzt im VAU-Handshake die ECDH- und Kyber-Public-Keys durch eigene. Der Client leitet Session-Keys aus den Angreifer-Schlüsseln ab und gewährt damit vollen Klartext-Zugriff auf den ePA-Verkehr: Dokumenten-Writes, Dokumenten-Reads und Autorisierungsflüsse.
• Während eines Testlaufs erfasste ein einzelner Relay das echte Zertifikat und die OCSP-Antwort des Upstream-Servers, präsentierte sie zusammen mit angreiferkontrollierten VAU-Schlüsseln, deren Signatur nicht verifizierte, und schloss den M1-M4-Handshake ab; anschließend las er die Einwilligungsentscheidungen einer Betroffenen, modifizierte eine zweite Antwort und schleuste einen dritten Patientendatensatz über den einen gekaperten Kanal ein.

Abhilfe

Aktualisieren Sie epa4all-client auf 1.2.1 oder höher. Der Fix liest den booleschen Rückgabewert von Signature.verify() und gibt false zurück, wenn die Signatur nicht passt, anstatt ihn zu verwerfen. Ergänzen Sie einen Unit-Test, der prüft, dass isTrusted() bei einer ungültigen Signatur false zurückgibt; zum Zeitpunkt der Offenlegung umgingen die Handshake-Tests die Signaturprüfung mit einer permissiven s -> true-Lambda, sodass das Verwerfen nie ausgeführt wurde.

Checkliste für Betreiber

• epa4all-client auf 1.2.1 oder höher aktualisieren.

  Jede veröffentlichte Version bis einschließlich 1.2.0 ist betroffen. Der Fix ist Pull Request #34: das Signature.verify()-Ergebnis lesen und im Fehlerfall abbrechen.

• Eigene Forks auf verworfene verify()-Aufrufe durchsuchen.

  Jeder verify(...)-Aufruf, dessen boolescher Rückgabewert nicht gelesen wird, entspricht keiner Prüfung. Suchen Sie nach Signature.verify, .verify( auf JWS-/JWT-Verifiern und Ähnlichem über Ihre VAU- und IDP-Pfade hinweg.

• Einen Negativtest für den Trust-Validator ergänzen.

  Prüfen Sie, dass isTrusted() bei einer strukturell gültigen, aber falschen Signatur false zurückgibt. Tests, die das Vertrauen mit einer s -> true-Lambda stubben, führen den echten Validator nie aus und bestehen gegen den verwundbaren Code.

• Mit selbstsigniertem Gegenpart testen.

  Bauen Sie einen lokalen VAU-Gegenpart, der angreiferkontrollierte öffentliche Schlüssel mit einer nicht passenden Signatur zurückgibt. Der Client muss den Handshake ablehnen.

Bewertung im Detail

Referenzen

• CVE-2026-44900 (NVD)
• GHSA-g8r3-5hwf-qp96 (Oviva)
• Oviva epa4all-client PR #34 (Fix)
• Oviva-epa4all-client-Repository
• 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