Lost in Resolution: Azure OpenAI's DNS Resolution Issue

Executive Summary

In late 2024, Unit 42 researchers discovered an issue with Azure OpenAI’s Domain Name System (DNS) resolution logic that could have enabled cross-tenant data leaks and meddler-in-the-middle (MitM) attacks. This issue stemmed from a misconfiguration in how the Azure OpenAI API handled domain assignments, versus how the user interface (UI) handled them.

While the UI required unique custom domain names for each OpenAI instance, the API did not have this requirement for one specific custom domain. This allowed multiple tenants to share the same custom domain, potentially resolving to an incorrect, untrusted external IP address.

The risk posed by this behavior included potential data interception and service disruption. This misconfiguration could have allowed an attacker to potentially direct API calls, sensitive data and credentials intended for Azure OpenAI endpoints to an attacker-controlled server outside of Azure’s network.

Microsoft has since remediated the issue. Affected domains now resolve to legitimate Azure resources or are non-resolvable.

This finding underscores the importance of continuously monitoring cloud configurations, validating DNS resolutions and scrutinizing API-driven workflows. Security teams should regularly audit managed services for misconfigurations to prevent even the most routine settings from introducing unforeseen risks.

Organizations can gain help assessing cloud security posture through the Unit 42 Cloud Security Assessment.

If you think you might have been compromised or have an urgent matter, contact the Unit 42 Incident Response team.

Background

In our own past research, we have often focused on uncovering high-impact vulnerabilities and security issues. But sometimes, something as simple as overlooked misconfigurations can threaten entire cloud environments. This specific research concerns Azure’s implementation of OpenAI. According to the documentation, “With Azure OpenAI, customers get the security capabilities of Microsoft Azure while running the same models as OpenAI. Azure OpenAI offers private networking, regional availability, and responsible AI content filtering.”

This article describes a subtle yet impactful flaw that we discovered in Azure OpenAI's DNS resolution logic — a flaw that could have enabled cross-tenant data leaks and MitM attacks.

We found that custom domain enforcement (ensuring that accounts use unique domain names) failed under specific conditions and DNS lookups resolved to an untrusted IP address outside of Azure's control. What made this discovery notable was not its criticality, but that it existed at all.

This flaw would have allowed attackers to potentially intercept API calls, credentials and sensitive data without compromising individual tenant accounts.

Figure 1 below maps the flow of multiple tenants resolving to the same DNS, and sending sensitive information to an unknown destination.

UI Versus API: Same Goal, Different Rules

When creating an Azure OpenAI service, the UI requires users to specify a unique custom domain name like margol.openai.azure[.]com. If the name is already in use, Azure rejects the request and returns an error message indicating that the name is already in use, as shown in Figure 2.

Although a custom domain name was required when creating an account from the portal UI, a custom domain name was not required for accounts created using the API. If an account was created through the API without a custom domain name, it could be accessed via the default domain name <region>.api.cognitive.microsoft[.]com. This name can be changed only once after the domain name is set.

Cross-Tenant DNS Resolution Issue: When DNS Points Outside of Azure

There is one specific custom domain that could be applied to multiple Azure OpenAI instances: test.openai.azure[.]com. This flaw allowed multiple services to share the same custom domain, potentially affecting all Azure tenants.

Figure 3 shows multiple services with the same custom test.openai.azure[.]com domain name.

We found that resolving the test.openai.azure[.]com URL led to a specific IP address at 66.66.66[.]66. As shown in Figure 4, every DNS provider resolves this domain to that specific IP address. This is not an Azure IP address. It belongs to an external, non-Azure internet service provider (ISP).

This posed a security risk, because sending sensitive data such as API calls, data files and API keys to the OpenAI endpoint with this custom domain exposed them to an untrusted entity. This resolution to a non-Azure IP address also created a potential vulnerability to MitM attacks if a threat actor listened on the IP address for HTTP calls. A successful MitM attack would have posed a threat to all Azure tenants that used the OpenAI endpoint with the test.openai.azure[.]com custom domain.

Microsoft’s Response

Within days of receiving our initial report, Microsoft addressed the DNS resolution issue associated with the test.openai.azure[.]com domain and took corrective actions. Specifically, they deleted the DNS A record pointing to 66.66.66[.]66 that they had used for internal activities.

Microsoft’s response to our report stated that “...authentication mechanisms are consistently enforced across their systems to prevent unauthorized access.” Furthermore, the domain now either resolves to a legitimate production API Management instance or is non-resolvable, eliminating the potential for misuse.

Disclosure Timeline

• October 28, 2024 – Initial report to Microsoft Security Research Center (MSRC)
• October 29, 2024 – Microsoft acknowledged the report and opened a case (MSRC 92222)
• October 30, 2024 – Palo Alto Networks research team observed that the misconfiguration has been addressed
• November 22, 2024 – MSRC closed the case and stated that the issue has been resolved

Takeaways for Security Researchers

Fundamental settings, such as default DNS setups and domain name enforcement policies, can have significant implications, unintentionally exposing multiple tenants to shared risks. Flaws in these basic areas can evolve into a major security issue, impacting all tenants relying on the shared infrastructure.

In our roles as cloud security researchers, we should methodically examine every aspect of these configurations, regardless of how routine they appear. This helps to identify and mitigate hidden risks before they affect the wider environment. Such diligence ensures the security and integrity of interconnected systems.

Takeaways for Security Practitioners

While shared infrastructure risks are generally low, they do exist. Awareness of risks like cloud service provider (CSP) logic flaws or vulnerabilities on managed resources is critical.

This article demonstrates that security issues can arise even when organizations follow best practices. In this case, the lack of unique domain names across tenants and DNS resolution conflicts for “test” cases could have compromised cloud-hosted resources.

Regularly monitor and validate DNS resolutions of cloud resources, to ensure that associated IP addresses belong to the CSP. Don’t assume that all managed resources are safe. Scrutinize API-driven workflows.

Conclusion

As cloud services underpin critical business operations, our Azure OpenAI finding highlights a broader challenge of securing shared infrastructure against misconfigurations. Microsoft’s quick remediation of the issue we identified demonstrates the industry's commitment to preventing attackers from exploiting newly found vulnerabilities and security issues.

This finding reinforces the importance of proactive security practices, like continuous monitoring, API behavior auditing and DNS resolution validation. Security practitioners must remain vigilant, as even minor gaps in configuration logic can create cascading risks across multiple tenants. The takeaway: Trust but verify. In cloud security, assumptions can be costly.

Palo Alto Networks Mitigation

Organizations can gain help assessing cloud security posture through the Unit 42 Cloud Security Assessment.

If you think you may have been compromised or have an urgent matter, get in touch with the Unit 42 Incident Response team or call:

• North America: Toll Free: +1 (866) 486-4842 (866.4.UNIT42)
• UK: +44.20.3743.3660
• Europe and Middle East: +31.20.299.3130
• Asia: +65.6983.8730
• Japan: +81.50.1790.0200
• Australia: +61.2.4062.7950
• India: 00080005045107

Palo Alto Networks has shared these findings with our fellow Cyber Threat Alliance (CTA) members. CTA members use this intelligence to rapidly deploy protections to their customers and to systematically disrupt malicious cyber actors. Learn more about the Cyber Threat Alliance.

Additional Resources

• Name resolution for resources in Azure virtual networks – Microsoft Learn