Caveat: This maybe obvious to experienced Cloud professionals and is not a 0-day. Either way I thought the Azure portal UI is not clear enough and is likely resulting in more than 1 company exposing SQL servers to unintended audiences.

Documentation: https://learn.microsoft.com/en-us/azure/azure-sql/database/firewall-configure?view=azuresql SQL Server Docs

For this scenario to have any impact, an Azure SQL Server needs to be created with “SQL Authentication” or “Use both SQL and Microsoft Entra authentication”. Then an attacker would need to have compromised valid SQL server credentials.

SQL Authentication

The next step in the UI/scenario and what this whole blog post is about it, is the checkbox “Allow Azure services and resources to access this server”. If you don’t take the extra step to hover over the information icon, it can be easy to assume that this means “hey I want to access this SQL server from my app service, vm, etc.”. What it really means is anyone coming from an Azure IP can access the SQL server.

SQL server allow AZ

The more secure way would be to use a Private Endpoint.

The rest of this blog post is going to demonstrate how an attacker who has your Azure SQL server creds could access it even when there are no whitelisted Firewall rules defined.

If you navigate to the Azure SQL server resource > Security > Networking blade, you’ll see no firewall rules defined. Which means deny by default, but since we have “Allow Azure services and resources to access this server” it is technically publicly accessible via Azure.

SQL server networking

If we try to access the Azure SQL server via a non-Azure IP, we get the expected firewall block.

SQL server ssms

If we try to access the Azure SQL server via an Azure IP, say a linux Virtual Machine with Impacket’s mssqlclient.py, then there is no firewall block.

SQL server impacket

Some resources that go into more depth about this: