[CB25]Cloud-Wide Contamination: Chaining SSRFs for Tenant Compromise in Azure (CVE-2025-29972)

### Overview In this talk, Vladimir Tokar details CVE-2025-29972, a critical (CVSS 9.8) Server-Side Request Forgery (SSRF) vulnerability discovered while working on the Azure Network Security Research (ANSR) team at Microsoft. The flaw resides in the Azure Storage Resource Provider (SRP), specifically within the handling of identity URLs during encryption scope processing. By bypassing network, service, control/data plane, and tenant trust boundaries, an attacker could trigger out-of-band requests from Azure's backend, leak Azure Active Directory (AAD) authentication tokens, and chain DNS rebinding techniques to force SRP instances to issue cross-tenant management commands.

### Key Topics - **SSRF Discovery in Storage Resource Provider (SRP):** How user-controlled identity URLs in encryption scope methods trigger backend HTTP requests. - **Azure AD Token Generation and Leakage:** Exploiting the `WWW-Authenticate` header handshake to extract internal AAD tokens. - **DNS Rebinding & "Spray and Pray":** Overcoming Azure's 5-minute internal DNS caching window by sending bursts of SSRF requests. - **Cross-Tenant Attack Vectors:** Targeting the SRP `regenerate password` endpoint to cause persistent denial-of-service and obtain unredacted SSH credentials. - **Mitigations and Defense-in-Depth:** Why Azure's architectural isolation limited the blast radius, and the specific fixes deployed by Microsoft.

### Technical Details In Azure's architecture, resource requests pass from the Azure Portal to Azure Resource Manager (ARM) and down to resource providers like SRP. Within SRP, the `process encryption scope` logic (and related functions like `refresh delegated resource identity async`) extracts an identity URL and invokes `get identity metadata async`. This method issues an initial `GET` request to the target URL; if it receives a `401 Unauthorized` response containing a `WWW-Authenticate` header, SRP parses the authorization and resource fields, generates an Azure AD token, and issues a follow-up `GET` or `POST` request with that token to the same URL.

Although protected behind a feature flag (requiring REST API enablement in corporate accounts or specific regional allowances), an attacker controlling the identity URL can point it to a malicious domain. By responding to the initial `GET` with a tailored `WWW-Authenticate` challenge, the attacker prompts SRP to send back a valid Azure AD token.

To pivot this token leakage into cross-tenant action, the attacker needs SRP to send the second authenticated request against an internal Azure service rather than the attacker's HTTP server. Because Azure caches DNS queries for roughly 5 minutes, traditional alternating-IP DNS rebinding fails. The researcher developed "spray and pray for bind," firing SSRF requests at 15-second intervals so that an attempt landing right at the 5-minute cache expiration window triggers a fresh DNS resolution returning an internal target IP.

The evaluated attack vector demonstrated SRP calling another tenant's SRP `regenerate password` endpoint for an SFTP/storage account (given the subscription ID, resource group, account name, and username). This regenerated the SSH password, causing a denial of service for the legitimate user. Furthermore, the response containing the new SSH password was returned to SRP and serialized into an identity metadata structure. Because `ssh password` was omitted from SRP's redaction list (which only filtered fields like `client secret`, `password`, `token`, and `key`), the plaintext credential was written directly into backend logs.

### Takeaways The research demonstrates how fundamental web vulnerabilities like SSRF and DNS rebinding can threaten multi-tenant cloud control planes when external inputs influence identity metadata resolution. Microsoft mitigated the vulnerability by enforcing regex-based URL validation, deploying DNS rebinding defenses (including randomized caching/TTL handling), expanding log redaction to cover SSH passwords, and enhancing internal network monitoring. Key operational takeaways include never trusting external input during identity flows, ensuring sensitive credentials are never stored unredacted in telemetry or logs, and enabling multi-factor authentication (MFA) to prevent unauthorized access even when credentials are leaked.