HTTP Header Injection in VAU Inner Requests

Description

inner_request = "GET /epa/authz/v1/getNonce HTTP/1.1\r\n"
inner_request += f"Host: {self.host}\r\n"
inner_request += "Accept: application/json\r\n"
inner_request += "Content-Type: application/json\r\n"
inner_request += f"x-useragent: {USER_AGENT}\r\n"
inner_request += f"x-insurantid: {insurant_id}\r\n"
inner_request += "\r\n"
inner_request = inner_request.encode("utf-8")

insurant_id     : metadata['insurantId'], validated only as JSON-Schema string
USER_AGENT      : os.getenv('USER_AGENT'); poisons every request in the session
boundary_string : caller-provided in upload_document(); enables Content-Type breakout
self.host       : server host string in every request

Decrypted inner HTTP (REQUEST):
  GET /epa/authz/v1/getNonce HTTP/1.1
  Host: epa-as-2.dev.epa4all.de
  Accept: application/json
  Content-Type: application/json
  x-useragent: usrAgent/1.1.0
  x-insurantid: X000000000
  X-Injected: CRLF-header-injection-confirmed

CRLF in insurantId passed through to inner HTTP.
f-string interpolation, no sanitization.

Impact

• Cross-patient data exposure: injecting a second x-insurantid header with a different KVNR may cause the ePA server to return records for a different patient, depending on the server's header-precedence behaviour (first-wins vs. last-wins).
• Authorization bypass: an injected Authorization: Bearer <token> header could bypass the normal authentication flow on the ePA server's inner HTTP handler.
• Session-wide poisoning: a malicious USER_AGENT environment variable injects headers into every inner HTTP request for the session lifetime.
• Request smuggling: in send_authcode_sc(), the Content-Length header is computed from len(body_json) before any injection occurs, creating an HTTP-desync surface when injected data shifts the header/body boundary.
• If gematik: VAU Handshake Performs Only 2 of 6 Required Server-Key Checks or fbeta: VAU Server Authentication Bypass via Circular Certificate Trust is also unmitigated, a MITM owns the inner-VAU plaintext without DiGA-user privilege; the injected x-insurantid arrives by relay, not by authenticated request, and PR collapses to N.

Mitigation

Update fbeta ePA3-Service-OpenSource to 1.3.0 or later. The fix sanitises every caller-controlled value before interpolation (rejecting any string that contains \r or \n) and validates insurantId against the KVNR format ^[A-Z]\d{9}$ at the library boundary. The longer-term remediation in the PR replaces manual string assembly for inner HTTP requests with a library that provides header validation, correct Content-Length computation, and proper encoding.

Defender's Checklist

• Update to fbeta ePA3-Service-OpenSource 1.3.0 or later.

  All versions before 1.3.0 are affected. The fix lives in pull request #11.

• Validate KVNR at the DiGA boundary, not only in the library.

  The KVNR format ^[A-Z]\d{9}$ is strictly defined. Apply the regex at the earliest point the value crosses your trust boundary (form input, API request body), so an invalid KVNR fails before it can reach this library.

• Audit your environment variables.

  The USER_AGENT env var was a poisoning vector: a value containing CRLF poisoned every request for the session lifetime. If your deployment reads any other env vars into inner-HTTP headers, validate them at startup, not at use time.

• Don't hand-build HTTP.

  Where you control the code, replace manual inner_request += f"..." patterns with a library that produces a well-formed HTTP message. The bug here would not have been possible if header values had passed through any validation layer between the caller and the encryption step.

Severity Reasoning

References

• GHSA-j8jg-7fqf-4xx9 (fbeta)
• fbeta ePA3-Service-OpenSource PR #11 (fix)
• fbeta ePA3-Service-OpenSource Repository
• Related: Missing VAU Server Authentication in gematik lib-vau
• Related: VAU Server Authentication Bypass in fbeta
• Related: ePA-VAU Client Security overview

How We Can Help

• MDR Penetration Testing