Beschreibung

Diese Auswirkung hat dieselbe SSRF-Ursache und denselben Fix wie der Token-Diebstahl. Die betroffene Import-Validierung akzeptierte Quell-URLs außerhalb des konfigurierten Storage-Accounts. Der Storage-Client griff mit der Managed Identity des Dienstes darauf zu.

Der Import liest ein Quell-Blob, verarbeitet dessen FHIR-NDJSON und stellt die importierten Ressourcen über die FHIR-API bereit. Abrufbar ist gültiges FHIR-NDJSON auf Accounts, die die Dienstidentität lesen und erreichen kann. Beliebige andere Blob-Inhalte werden nicht zurückgegeben.

Ein synthetischer Patient-Testdatensatz wurde vom konfigurierten Account importiert und anschließend ausgelesen. Der Aufrufer hatte nur FHIR Data Importer und keine Storage-Rolle. Ein separater Test bestätigte den authentifizierten Zugriff auf einen weiteren Account. Ein vollständiger Datenabruf über diese Account-Grenze ergibt sich aus dem gemeinsamen Codepfad, wurde aber nicht gesondert nachgewiesen.

Testdatensatz nach dem Import (bereinigter Auszug der Originalausgabe)

GET /Patient/probe-canary-<id> -> 200
identifier.value = 'PROBE-CANARY-<id>-NOT-REAL-PHI'

GetImportRequestHandler übernimmt Quell-URLs und Fehlertexte des Storage-SDK in OperationOutcome.issue.diagnostics. Im folgenden Test mit drei Zielen lieferte der für die Identität zugängliche Account einen detaillierten Storage-404. Die beiden anderen Anfragen endeten mit allgemeinen 500-Fehlern.

Statusantworten für drei Testziele (gekürzt und bereinigt)

# A - Storage account the Managed Identity can read (public callers firewall-denied):
GET /_operations/import/<job-A>
  status=404  diagnostics: "Service request failed. Status: 404 (BlobNotFound)
                            Server: Windows-Azure-Blob/1.0  x-ms-request-id: <redacted>"

# B - unresolvable host (no DNS record anywhere):
GET /_operations/import/<job-B>
  status=500  diagnostics: "InternalServerError"

# C - reachable public non-Storage host:
GET /_operations/import/<job-C>
  status=500  diagnostics: "InternalServerError"

Die Antworten des erreichbaren Nicht-Storage-Hosts und des nicht auflösbaren Hosts waren nicht unterscheidbar. Die Ergebnisse belegen ein begrenztes Storage-Response-Oracle. Allgemeine Aussagen zur Netzwerkerreichbarkeit oder zu allen denkbaren Fehlerfällen lassen sich daraus nicht ableiten.

Auf dem separaten Test-Account hatte die Dienstidentität Storage Blob Data Reader. Die Firewall verweigerte Zugriffe standardmäßig, ließ aber die Ausnahme für vertrauenswürdige Microsoft-Dienste zu. Eine direkte Anfrage von außerhalb lieferte 403; der FHIR-Dienst erreichte Storage und erhielt 404. Diese Ausnahme ist eine unterstützte Netzwerkoption; alternativ können bestimmte IP-Adressen freigegeben werden.

PR #5536 beschränkt Importe auf den konfigurierten Storage-Account. Reguläre Importe und detaillierte Fehlermeldungen innerhalb dieses Accounts bleiben möglich: GetImportRequestHandler ist in release/4.0.759 unverändert. Eine CVE wurde nicht vergeben.

Auswirkung

Der Codepfad ermöglicht die Offenlegung von gültigem FHIR-NDJSON auf weiteren Accounts, die die Dienstidentität lesen und erreichen kann. Dazu können vorhandene exportierte Patientendaten gehören. Der Importmechanismus und der Zugriff auf einen separaten Account wurden unabhängig voneinander nachgewiesen.
Fehlermeldungen legten im Test Storage-Metadaten offen. Der Dienst erreichte den Test-Account, weil sowohl seine Rolle als auch die dortige Firewall-Ausnahme den Zugriff erlaubten.

Abhilfe

Microsoft hat die Zielprüfung in Azure Health Data Services ausgerollt. Wer Microsoft FHIR Server selbst betreibt, sollte auf release/4.0.759 oder neuer aktualisieren. Der Fix verhindert Importe aus anderen Accounts; am Zugriff innerhalb des konfigurierten Accounts ändert er nichts.

Checkliste für Betreiber

Import- und Storage-Berechtigungen begrenzen.
Gewähren Sie import/action nur für vertrauenswürdige Import-Prozesse und entziehen Sie der Dienstidentität nicht benötigte Storage-Rechte. Prüfen Sie dabei auch die Netzwerkausnahmen.
Zugriffe vor dem Fix prüfen.
Soweit Protokolle aktiviert und aufbewahrt wurden, gleichen Sie FHIR-Importe anhand verfügbarer Zeitstempel, Ressourcen-URIs und Request-Metadaten mit Storage-Zugriffen der Dienstidentität ab. Storage-Protokolle allein identifizieren den ursprünglichen FHIR-Aufrufer oder Import-Job nicht.
Fehlermeldungen auf das Nötige beschränken.
Ersetzen Sie in selbst betriebenen Forks den Storage-SDK-Fehlertext in Statusantworten durch eine allgemeine Meldung zum fehlgeschlagenen Lesezugriff. Technische Details gehören in entsprechend geschützte Betriebsprotokolle.

Bewertung im Detail

AV:NImport- und Status-Endpunkte sind über das Netzwerk erreichbar.AC:LEs sind weder eine Race-Condition noch ein bestimmtes Timing erforderlich.PR:LErforderlich ist FHIR Data Importer, eine auf den FHIR-Dienst beschränkte Rolle.UI:NDer Dienst ruft die Quelle automatisch ab.S:CDie FHIR-Berechtigung des Aufrufers ermöglicht Zugriffe mit den gesonderten Storage-Rechten der Dienstidentität.C:HDer gemeinsame Codepfad sowie getrennte Tests des Imports und des authentifizierten Account-Zugriffs belegen die Grundlage für die Offenlegung von FHIR-Daten auf weiteren Accounts. Ein vollständiger accountübergreifender Datenabruf wurde nicht nachgewiesen.I:NDer Import von Ressourcen ist für diese Rolle bereits erlaubt. Eine darüber hinausgehende Beeinträchtigung der Integrität wurde nicht nachgewiesen.A:NEine Auswirkung auf die Verfügbarkeit wurde nicht nachgewiesen.

$import ermöglicht den Zugriff auf FHIR-Daten in weiteren Storage-Accounts

Beschreibung

Auswirkung

Abhilfe

Checkliste für Betreiber

Bewertung im Detail

Referenzen

So können wir helfen

Wer wir sind

Dr. rer. nat. Simon Weber

Dipl.-Inf. Volker Schönefeld

Penetrationstest gesucht?