HTTP-Header-Injection in den inneren VAU-Requests

Beschreibung

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'], nur als JSON-Schema-String validiert
USER_AGENT      : os.getenv('USER_AGENT'); vergiftet jeden Request der Session
boundary_string : vom Aufrufer in upload_document() geliefert; Content-Type-Breakout
self.host       : Host-String des Servers in jedem 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.

Auswirkung

• Cross-Patient-Datenoffenlegung: Das Einschleusen eines zweiten x-insurantid-Headers mit einer anderen KVNR kann je nach Header-Vorrangs-Verhalten des ePA-Servers (first-wins vs. last-wins) dazu führen, dass Datensätze einer anderen Versicherten zurückgegeben werden.
• Autorisierungs-Bypass: Ein eingeschleuster Authorization: Bearer <token>-Header könnte den normalen Authentifizierungsfluss im inneren HTTP-Handler des ePA-Servers umgehen.
• Sitzungsweites Poisoning: Eine bösartige USER_AGENT-Umgebungsvariable schleust für die gesamte Sitzungslaufzeit Header in jeden inneren HTTP-Request ein.
• Request-Smuggling: In send_authcode_sc() wird der Content-Length-Header aus len(body_json) berechnet, bevor eine Injection greifen kann; wenn eingeschleuste Daten die Header-Body-Grenze verschieben, entsteht eine HTTP-Desync-Angriffsfläche.
• Wenn auch der gematik: VAU-Handshake führt nur 2 von 6 vorgeschriebenen Server-Schlüssel-Prüfungen aus oder fbeta: VAU-Server-Authentifizierungs-Bypass durch zirkuläres Zertifikatsvertrauen unmitigiert ist, kontrolliert ein MITM die innere VAU-Klartext-Ebene ohne DiGA-Nutzer-Privileg; der eingeschleuste x-insurantid kommt per Relay statt durch einen authentisierten Request, und PR sinkt auf N.

Abhilfe

Aktualisieren Sie fbeta ePA3-Service-OpenSource auf 1.3.0 oder höher. Der Fix bereinigt jeden vom Aufrufer kontrollierten Wert vor der Interpolation (jede Zeichenkette mit \r oder \n wird abgelehnt) und validiert insurantId an der Bibliotheksgrenze gegen das KVNR-Format ^[A-Z]\d{9}$. Die längerfristige Behebung im PR ersetzt die manuelle String-Zusammensetzung innerer HTTP-Requests durch eine Bibliothek, die Header-Validierung, korrekte Content-Length-Berechnung und passende Kodierung mitbringt.

Checkliste für Betreiber

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

  Alle Versionen vor 1.3.0 sind betroffen. Der Fix liegt in Pull Request #11.

• KVNR an der DiGA-Grenze validieren, nicht erst in der Bibliothek.

  Das KVNR-Format ^[A-Z]\d{9}$ ist strikt definiert. Wenden Sie die Regex am frühesten Punkt an, an dem der Wert Ihre Vertrauensgrenze überschreitet (Formulareingabe, API-Request-Body), damit eine ungültige KVNR scheitert, bevor sie diese Bibliothek erreicht.

• Umgebungsvariablen prüfen.

  Die USER_AGENT-Umgebungsvariable war ein Poisoning-Vektor: Ein Wert mit CRLF vergiftete jeden Request der Sitzungslaufzeit. Wenn Ihr Deployment weitere Umgebungsvariablen in innere HTTP-Header übernimmt, validieren Sie sie beim Start, nicht zum Zeitpunkt der Verwendung.

• Kein HTTP per Hand zusammenbauen.

  Wo Sie den Code selbst kontrollieren, ersetzen Sie manuelle inner_request += f"..."-Muster durch eine Bibliothek, die eine wohlgeformte HTTP-Nachricht produziert. Der Fehler hier wäre nicht möglich gewesen, wenn Header-Werte zwischen Aufrufer und Verschlüsselungsschritt eine Validierungsschicht durchlaufen hätten.

Bewertung im Detail

Referenzen

• GHSA-j8jg-7fqf-4xx9 (fbeta)
• fbeta-ePA3-Service-OpenSource-PR #11 (Fix)
• fbeta-ePA3-Service-OpenSource-Repository
• Verwandt: Fehlende VAU-Server-Authentifizierung in gematik lib-vau
• Verwandt: VAU-Server-Authentifizierungs-Bypass in fbeta
• Verwandt: ePA-VAU-Client-Sicherheit (Übersicht)

So können wir helfen

• MDR-Penetrationstests