med-united epa4all VAU Authentication Bypass and MITM Analysis

Here is a summary of the key vulnerability information from the webpage screenshot: --- Vulnerability Overview Vulnerability Name: VAU Server Authentication Bypass Product: med-united epa4all Severity: High (CVSS 8.1) Disclosure Date: 2026-05-20 Remediation Date: 2026-05-20 Core Issue: epa4all integrates the gematik reference library as a Git submodule but lacks any validation at the top level. During the handshake, the client deserializes the server-sent , , and fields without utilizing them, allowing a network attacker to substitute their own keys, complete the handshake, and take over the session. Defect Details: Defect 1: Missing Wrapping directly delegates to the reference state machine without any application-layer validation. Defect 2: Reference State Machine Only Checks Expiry The internal only performs a time-validity comparison on the server’s signature public key and does not verify the cryptographic signature. Unimplemented A_24624-01 Check Items: > Note: The , , and fields are deserialized but not used for validation path checks. Combined with , this results in a lack of authentication. --- Impact Scope Attack Scenario: A network-positioned attacker intercepts the VAU handshake, returning a self-signed public key and certificate. The client accepts both, allowing the attacker to derive the same K2 session key and gain control of the encrypted channel. Deployment Environment: In production deployments, the attacker has reachability to the LAN; epa4all runs as an on-premise Docker container ( ), is accessible from the local network, and connects to the ePA backend. Data Risk: A Man-in-the-Middle (MITM) can read and modify all inner-layer HTTP traffic (VAU channel): patient consent decisions, medication data, document uploads, authorization tokens, benefit queries, etc. Testing revealed that a single roundtrip can replay patient decisions, swap insurance IDs and decision values, and inject a third patient record (without CA chain validation). --- Remediation Official Fix: Update to build versions from 2026-05-20 or later. The fix includes: Addition of certificate and hostname checks for (based on Telematik TSL) Addition of a keystore based on Telematik TSL Verification that the signature is signed by a certificate trusted by the TI PKI No workarounds are available for affected builds; a transport-layer fix alone is insufficient; must also be addressed. Defender Checklist: ✅ Update to 2026-05-20 or later build versions All 1.0.0-SNAPSHOT builds are affected. The fix adds a Telematik-TSL keystore and enables signature checking on the client side. ✅ Verify that the TI PKI Root Anchor is actually loaded at runtime The standard JVM system truststore does not contain the TI PKI root. Confirm that the deployment source is gemSpec_PKI’s TI Root CA bundle and that the keystore is loaded before the first VAU handshake. ✅ Use in conjunction with TLS Verification Fix Even with the addition of VAU server authentication, TLS verification on outbound connections must be re-enabled. The two fixes are independent and both are required; see . ✅ Test with Self-Signed Peers Set up a local VAU peer responding to Message 2 with an attacker-controlled public key, a self-signed , and arbitrary bytes. The client should reject the handshake—if it does not, the fix is not effective. --- References GHSA-vvh7-x6c7-46gh (med-united) med-united epa4all Repository gematik lib-vau (reference, vendored) gemSpec_Krypt A_24624-01 (Client verification of server’s signed public keys) Related: TLS Certificate Verification Disabled Related upstream: VAU Handshake Performs Only 2 of 6 Required Server-Key Checks Related: ePA-VAU Client Security overview --- > Note: The page does not provide complete POC code, only partial Java source code snippets to illustrate the defects.

Goal Reached Thanks to every supporter — we hit 100%!

med-united epa4all VAU Authentication Bypass and MITM Analysis