Hijacking des Authentifizierungsablaufs

Der gematik Authenticator registriert sich als Handler für das benutzerdefinierte URI-Schema authenticator:// und akzeptiert einen challenge_path-Parameter, der den Identity Provider (IDP) für eine OpenID-Connect-Anmeldung benennt. Keine Allowlist schränkt ein, welcher Host als IDP dienen darf, sodass ein präparierter Deep Link den Authenticator auf einen angreiferkontrollierten Server lenken kann. Der Link lässt sich über eine Webseite, eine E-Mail oder einen QR-Code zustellen.

Der Parameter wird nur auf die URL-Form geprüft, nicht auf die Domain. Jede http/https-URL wird akzeptiert:

export async function validateChallengePath(challengePath: string) {
  if (!COMMON_USED_REGEXES.URL.test(challengePath)) { /* throw */ }
}

// constants.ts
URL: /(http|https):\/\/(\w+:?\w*@)?(\S+)(:\d+)?(\/|\/([\w#!:.?+=&%@!\-/]))?/,

Der Authenticator ruft das OpenID-Connect-Discovery-Dokument von diesem Host ab und decodiert es mit jsonwebtoken.decode(), das keine Signaturprüfung durchführt:

const res = await window.api.httpGet(
  context.state.idpHost + IDP_ENDPOINTS.OPENID_CONFIGURATION, { /* ... */ }
);
context.commit('setOpenIdConfiguration', jsonwebtoken.decode(res.data));

jsonwebtoken.decode() decodiert das Token nur per Base64; die Dokumentation der Bibliothek warnt ausdrücklich, dass es nicht für nicht vertrauenswürdige Nachrichten verwendet werden darf. Das unsignierte Dokument des Angreifers (alg: none) wird akzeptiert, und seine Felder authorization_endpoint und uri_puk_idp_enc werden unverändert genutzt. Anschließend verschlüsselt der Authenticator die per Smartcard signierte Assertion mit dem öffentlichen Schlüssel des Angreifers und sendet sie per POST an dessen Endpunkt:

const payload = 'signed_challenge=' + state.jweChallenge;
const url = context.state.openIdConfiguration.authorization_endpoint;
const response = await window.api.httpPost(url, payload, { /* ... */ });

Das gesendete JWE umschließt ein JWS mit dem X.509-AUT-Zertifikat der Karte (x5c-Header) und der Smartcard-Signatur. Da der Angreifer den Verschlüsselungsschlüssel besitzt, kann er es entschlüsseln und die signierte Assertion gewinnen; dieser Abgriff der Credentials ist gegen die Mock-Umgebung Ende-zu-Ende nachgewiesen. Die Challenge-JWT enthält keine Umgebungsbindung (kein cnf-Claim, keine Quell-IP, keine TLS-Sitzungskennung), sodass die abgegriffene Assertion ihrerseits an den echten IDP weitergereicht werden kann, um die Anmeldung als betroffene Person abzuschließen — bewertet anhand der Spezifikation und der Referenz-IDP-Implementierung, nicht gegen die Produktivinfrastruktur getestet.

IDP-Zertifikats-Pinning war in v4.4.1 vorhanden, wurde aber in v4.12.0 zugunsten des Betriebssystem-Truststores entfernt. Der Host des Angreifers benötigt daher nur ein gewöhnliches, öffentlich vertrauenswürdiges TLS-Zertifikat (etwa von Let's Encrypt). Der private Schlüssel der Smartcard verlässt die Karte nie; die Schwäche besteht darin, dass der Authenticator den IDP, mit dem er spricht, nicht authentifiziert.