Know Your App Services Before Your Enemy Does 

App Services: The low-down

App Services are a service offered by Azure for easily building and running web applications and APIs. It is getting increasingly popular as it allows you to integrate capabilities like load balancing, autoscaling, or Continuous Development / Continuous Integration (CI/CD) in an easy fashion.

So, what could be wrong with your App Services? 

With Azure and other cloud platforms, the main risk is that developers are building applications without understanding how to secure them. We will see in the next section that Microsoft provides great recommendations and guidelines on how to secure these App Services, but as often, the problem is that these settings are not enabled by default. If your developers are unaware of these guidelines and best practices, they may make sensitive data available to anyone on the internet.  

This article provides knowledge of App Services that you host in your tenant or subscriptions, which can be accessed by anyone on the Internet. So, let’s dig into what you need to know about App Services in terms of security, and how to discover if your developers are well-versed in terms of best practices. 

Security recommendations for App Services 

In their online documentation, Microsoft defines a total of 19 recommendations classified into five categories (General, Identity and access management, Data protection, Networking, and Monitoring). In the context of this work, two recommendations are particularly important for restricting access to anyone on the internet: 

• Authenticating web requests whenever possible: “use the App Service authentication module instead of writing code to handle authentication and authorization.” The screenshot below gives an example App Service that does not have any authentication settings configured: 

Figure 1: Example of an App Service with no authentication settings configured 

• Restricting network access to your application: “Azure App Service lets you define a list of IP addresses that are allowed to access your app. The allowed list can include individual IP addresses or a range of IP addresses defined by a subnet mask.” The screenshot below gives an example App Service that does have access restrictions configured:Figure 2: Example of an App Service with access restrictions configured 

So how can we translate these two recommendations into something we can query using the Azure API? Well, let’s see how the Azure Resource Graph Explorer can help us here. 

Azure Resource Graph Explorer to the rescue 

If you have never heard of the Resource Graph Explorer in Azure, now is the time to try it out! Resource Graph Explorer is a service in Azure that gives you the ability to query resources’ configuration, using the Kusto Query Language, and gives back results in seconds.  

As Microsoft explains in their documentation, you will need read access to the resources you want to query for the Resource Graph Explorer to return meaningful results. 

So, let’s build a query to get all running web applications of type 'microsoft.web/sites': 

Figure 3: Resource Graph Explorer query to get all existing web applications 

Resource Graph Explorer has found a total of 848 web applications in our tenant in under 6 seconds of work. Now let’s clean up this query and filter out Function Apps as we don’t want to tackle these for now. On top of that, let’s focus on running applications, with their public network access property not being disabled (so enabled): 

Figure 4: Example of our Resource Graph Explorer query with the associated results 

We have found a total of 515 App Services that don’t have any network restrictions configured. 

The other filter we want to add now is to check if requests must be authenticated. The resources table we just used doesn’t seem to contain this piece of information though. Authentication settings can only be queried in the table appserviceresources. Thanks to KQL capabilities, this can be achieved using a join statement as shown below. 

Figure 5: Improved query to get App Services with no authentication settings 

We now have a total of 493 App Services that don’t have any network restrictions and any authentication settings configured. These 493 App Services are therefore supposedly accessible from anyone on the internet. It is however possible that:  

• Additional controls are implemented elsewhere than at the Azure platform level, i.e., in the application itself. 

• The Resource Graph Explorer is not able to see the real value of the publicNetworkAccess setting. In my tests, I’ve realized that most App Services returned by the query have the value of null. However, if I browse to the App Service itself in the Azure portal and check its network settings, I am able to see if the access is restricted or not. This looks like either a Resource Graph Explorer bug/limitation, and it is definitely not helping our assessment here. 

So, how can we validate even further this list of supposedly accessible App Services? Well, now that we have a reduced list, let’s build a quick Powershell script to check these out automatically. Without doing anything too fancy, the script would:  

• connect to the Azure using the Connect-AzAccount comandlet,  
• use the Search-AzGraph commandlet to run our KQL query,  
• use a loop to go through the results,  

• connect to the domain using the Invoke-WebRequest command,  
• and compile the results depending on if we receive an HTTP 403 (which means access to the page is forbidden), or if we are redirected to Microsoft authentication page.  

The final script can be found here, but below is a snippet of its output. The list of domains and the associated result is given in a CSV format so that it can easily be copy/pasted in an Excel sheet later. 

In the end, we have reduced our list of 848 existing web applications in Azure to 493 App Services supposedly available using appropriate filters. Scripting this query then has allowed us to automatically identify which ones have additional controls implemented in the application itself and has highlighted a total of 98 verified accessible App Services. 

What's next? 

Now, what to do with these results? The exact answer will depend on these, your organization, and your role in this one. But without being too specific, here is some food for thought:  

• Start by validating the results and prioritizing the remediation work. Now that you have highlighted App Services that are directly reachable by anyone on the internet, you must check the results manually and remediate these if they contain sensitive information.  
• Think about how to run this script periodically to quickly flag any new App Service that may be publicly accessible. Azure provides interesting capabilities like Automation Accounts to execute runbooks like this one. 

• If you have few or no results, that is good news! That doesn’t mean though you are out of trouble: start checking settings in more detail, like the list of subnets allowed or denied in the access restrictions details. If the network restriction rule is to deny one specific IP, then it still means that the whole internet (minus 1) can access your App Service… 
• If your developers are implementing authentication and authorization controls in their application, be mindful that this is not following best practices (as explained by Microsoft), as it will take significant work to keep it up to date and follow the industry’s best practices and standards.  
• Work on guidelines, requirements, and guardrails for your developers. As discussed in the introduction, the main risk is that developers are building web applications without understanding how to secure their resources. It is therefore paramount to:
  • Work on guidelines based on well-known recommendations such as Microsoft’s or the CIS benchmarks for Azure. 
  • Define and discuss requirements with your developers. Should they be allowed to build publicly accessible web applications using App Services, and for what type of data classification?   

• Once you have precise requirements, you can build guardrails to restrict developers from deploying non-compliant App Services. Azure Policy is a great native tool to define rules to audit, modify or deny such deployments. Here are few pointers to interesting policies regarding authentication and network access: 
  • A policy to audit if authentication is enabled for your App Services
  • A policy to disable public network access to your App Services  
  • All built-in policies regarding App Services  
    

Also, be sure to check out our Mirai Security services if you are interested in the security services we are doing at Mirai and especially what we are doing to help secure your cloud.