IDP-Discovery-Document-Signature-Bypass

Beschreibung

private OidcDiscoveryResponse parseFromJwt(String jwt) {
    try {
        var payload = JWSObject.parse(jwt).getPayload();
        return JsonCodec.readBytes(payload.toBytes(), OidcDiscoveryResponse.class);
    } catch (ParseException e) {
        throw new AuthorizationException("Failed to parse JWT", e);
    }
}

// Note: The challenge contains the URL to the keys, so is anyways
// in control of it. Not sure what validating the signature adds.

Auswirkung

• Ein Angreifer, der die TLS-Verbindung zum zentralen IDP per Man-in-the-Middle abfängt, greift die SMC-B-signierte Authentifizierungsantwort und das beim Login ausgetauschte Schlüsselmaterial ab. Mit diesem Material kann der Angreifer sich gegenüber dem ePA-Backend als die legitime Einrichtung authentifizieren und die Akten der Betroffenen lesen oder verändern, für die die SMC-B-Karte der Einrichtung tätig werden kann.
• Während eines Testlaufs lieferte ein Mock-IDP ein Discovery-JWT aus, das mit einem dem Client nicht vertrauten Schlüssel signiert war; der Client schloss den Autorisierungsfluss gegen die angreiferkontrollierten Schlüssel-URIs ab (beobachtet als send_authcode_sc auf dem entschlüsselten Kanal), was die Annahme des gefälschten Dokuments bestätigte.

Abhilfe

Aktualisieren Sie epa4all-client auf 1.2.2 oder höher. Für betroffene Versionen ist kein Workaround verfügbar. Der Fix prüft die JWT-Signatur in parseFromJwt() gegen einen Schlüssel, der gepinnt oder aus einer vertrauenswürdigen, nicht aus dem JWT abgeleiteten Quelle bezogen wird, validiert den issuer gegen eine Allowlist vertrauenswürdiger TI-IDP-URIs und pinnt die IDP-Discovery-URL, statt sie aus dem iss-Claim des Challenge-JWT abzuleiten.

Checkliste für Betreiber

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

  Alle Versionen vor 1.2.2 sind betroffen. Der Fix ist Pull Request #36.

• Sicherstellen, dass die Discovery-JWT-Signatur tatsächlich geprüft wird.

  Prüfen Sie nach dem Update, dass ein mit einem nicht vertrauten Schlüssel signiertes Discovery-Dokument abgelehnt wird. Der Signaturschlüssel muss aus einer gepinnten oder vertrauenswürdigen Quelle stammen, nicht aus dem JWT oder der Challenge selbst.

• IDP-Discovery-URL pinnen und den Issuer per Allowlist prüfen.

  Leiten Sie die Discovery-URL oder die Schlüssel-URIs nicht aus dem iss-Claim des Challenge-JWT ab. Pinnen Sie den Discovery-Endpunkt und validieren Sie issuer gegen eine bekannte Liste von TI-IDP-URIs, um das selbstreferenzielle Vertrauen aufzubrechen.

• Nicht den Konnektor-Proxy als einzige Barriere annehmen.

  Das Transport-Routing durch die TI beschränkt, wer den IDP-Pfad erreicht, ist aber keine Authentifizierung des Discovery-Dokuments. Ein Angreifer innerhalb der TI oder einer, der den Proxy erreicht, gewinnt ohne die Signaturprüfung weiterhin.

Bewertung im Detail

Referenzen

• CVE-2026-45575 (NVD)
• GHSA-gqx7-6552-67hf (Oviva)
• Oviva epa4all-client PR #36 (Fix)
• Oviva-epa4all-client-Repository
• Verwandt: ePA-VAU-Client-Sicherheit (Übersicht)

So können wir helfen

• MDR-Penetrationstests