How to Identify Vulnerabilities in Public-Facing Azure Services
H

Post Credit: David Okeyode & Karl Fosaaen

TL;DR: As a penetration tester, you may be tasked with anonymously attacking an Azure tenant as part of your assessment. From a scope perspective, this can be tricky. Anyone can name an Azure service whatever they want, and it may be hard to find resources that are truly in scope. Regardless of whether you are chasing a bug bounty or shadow IT assets during a penetration test, anonymous Azure service discovery can be a helpful tool in identifying vulnerabilities in an environment.

In this post, we’ll discuss guidelines for pentesting Azure services. We will also cover attacks in Azure that do not require any authentication to an Azure tenant and assess Azure vulnerabilities.

 

Guidelines for Azure Penetration Testing

Since June 2017, Microsoft no longer requires organizations to obtain pre-approval to conduct a penetration test against their Azure resources (https://docs.microsoft.com/en-us/azure/security/fundamentals/pen-testing). It is important to note that this exemption does not apply to other Microsoft cloud services, such as Office 365. Even though you do not need to notify Microsoft before you perform a penetration test, there are still stated rules of engagement that you must always comply with, and you absolutely should not cross these boundaries. Failure to comply could lead to a suspension or termination of your Azure account, legal action brought against you by Microsoft, and financial liability claims being made against you!

Important note

As these guidelines are occasionally updated, we recommend that you visit https://www.microsoft.com/en-us/msrc/pentest-rules-of-engagement to review the latest information.

The following activities are prohibited:

  • Scanning assets that belong to other Azure customers.
  • Gaining access to any data that is not yours.
  • Performing any kind of denial of service testing is strictly forbidden as it may result in unplanned downtime for other Azure customers.
  • Attempting phishing or other social engineering attacks against Microsoft employees.

The following activities are allowed:

  • Scanning your Azure endpoints to uncover application or configuration vulnerabilities
  • Port scanning and fuzz testing your Azure endpoints

In general, any activity that could impact other Azure customers or the stability of the underlying Azure infrastructure is not allowed (including testing and accessing other customers’ data without permission). Testing your Azure endpoints and the applications hosted on them is encouraged.

 

Azure Pentest Scopes

Penetration tests in Azure can come in a variety of different scopes. Depending on how your organization determines the threats to the environment, and how they define a penetration test, there may be different goals for the test.

Common Azure penetration test scopes include the following:

  • Anonymous external testing
  • Read-only configuration review
  • Internal network testing
  • Architecture review

Many times, an Azure penetration test will consist of any combination of these scopes. In any case, we will want to get written legal approval from the owners of the Azure assets before we start testing. Like any other penetration test, having a clearly defined scope and methodology is crucial to the success of the project.

For those that are approaching this content from a bug bounty standpoint, this chapter will provide you with plenty of options to go after Azure targets from an external perspective. Just like any other test, it is always good to make sure that the Azure targets fall within the scope of the bug bounty program that you are working on.

 

Anonymous Service Identification

Now that we have a basic understanding of Azure infrastructure and the available scopes for an Azure penetration test, let’s get started with some practical attacks. In this section, we will cover how we can anonymously identify internet-facing services that are hosted in Azure. Given that many organizations are making use of Azure services, this will be applicable for any external test, regardless of the cloud.

 

Test at your own risk

For the purposes of this tutorial, we will have some real resources in the examples that you can use for testing these tools. All the examples in this post, unless noted otherwise, will point to resources that you are authorized to follow the examples with.

Important note: Do not run the tools or examples in this post against systems or services that you do not have the authorization to test.

 

Azure public IP address ranges

Like other cloud providers, Microsoft Azure allows organizations to assign internet-accessible IP addresses to Azure resources. A public IP address can be allocated to the following Azure resources: a virtual machine network interface, an internet-facing load balancer, a VPN gateway, an application gateway, or an Azure firewall instance.

When public IP addresses are allocated, they can either be static or dynamic. Dynamic public IP addresses can change over the lifespan of the Azure resource, while static public IP addresses will not change over the lifespan of the Azure resource.

 

1) Hands-on exercise – parsing Azure public IP addresses using PowerShell

This exercise will walk you through how an external adversary could use the published Azure public IP ranges to identify potential targets that they can scan for vulnerabilities.

Here are the tasks that we will complete in this exercise:

  • Task 1: Download the published Azure public IP ranges JSON file on our pentest VM.
  • Task 2: Parse the downloaded file to identify potential targets using PowerShell.

Let’s begin:

  1. Within your pentest VM, open a web browser and browse to https://www.microsoft.com/en-us/download/details.aspx?id=56519 (you can also use this shortened URL: http://bit.ly/azureipranges).
  2. Click on the Download button to obtain the current list of Azure public IP address ranges. This will download a JSON file that contains a list of the public IP address ranges by region and by service.
  3. For demonstration’s sake, we will not be using this downloaded JSON file. Instead, we will be using the link that is presented to download the file from our command-line session:
    Figure 3.2 – Downloading the JSON file

    Downloading the JSON file

  4. In the window that is displayed, right-click on click here to download manually, and then click on Copy link address to obtain the URL to the JSON file:
    Figure 3.3 – Obtaining the URL of the JSON file

    Obtaining the URL of the JSON file

  5. Note: The JSON file we’ve downloaded here is for the Azure public cloud. There is a separate file for the Azure US Government cloud. The file can be downloaded from https://www.microsoft.com/en-us/download/details.aspx?id=57063.

  6. In the PowerShell console of your pentest VM, download the JSON file using the following commands. Replace <json_url> with the URL that you obtained in Step 3:
    cd C:\Users\$env:USERNAME\
    Invoke-WebRequest <json_url> -O azure_ip_range.json
  7. For our example, we will use PowerShell to filter the public IP address ranges for all the services in the Azure UK South region. This will return a list of IP ranges that an attacker could scan to determine the open ports and the listening services on those ports:
    $jsonData = gc .\azure_ip_range.json | ConvertFrom-Json
    ($jsonData | select -ExpandProperty values | where name -EQ AzureCloud.uksouth).properties.addressPrefixes
  8. Next, try filtering the public IP address ranges used by a specific service (Azure App Service instances) in the UK South region. An attacker could obtain these IP ranges and scan them for web application vulnerabilities, as Azure App Service resources are typically used to host web applications and APIs:
    ($jsonData | select -ExpandProperty values | where name -EQ AppService.UKSouth).properties.addressPrefixes
  9. An attacker could obtain the IP ranges and scan them for open ports and listening services to understand the attack surface area. Using the examples in Steps 6 and 7, try out other queries to identify the public IP ranges for other Azure services and regions.

    Important note: To “just make things work,” some Azure administrators/engineers may open up wide ranges of IPs that have been assigned to different Azure regions to allow virtual machines to communicate. This may also allow you to reach those same systems from a VM in the right region. If you have authenticated access to the Azure environment, keep an eye out for Azure IP ranges in the network security group rules that you may be able to take advantage of.

 

2) Hands-on exercise – using MicroBurst to enumerate PaaS services

The MicroBurst (https://github.com/NetSPI/MicroBurst) toolset is a grouping of PowerShell scripts that can be used for multiple different attacks in Azure. In this exercise, you will install MicroBurst on your pentest VM and use its Invoke-EnumerateAzureSubDomains.ps1 script to anonymously enumerate Azure services that the authors of this post have previously set up in the Azure cloud.

Following the methodology outlined here, the script will create a list of permutations from a base word and try to resolve DNS hostnames based on those permutations. Here are the tasks that we will complete in this exercise:

  • Task 1: Download and install MicroBurst.
  • Task 2: Use MicroBurst to enumerate active Azure platform service instances.

Let’s begin:

  1. Within the RDP session of your pentest VM, right-click the Start button and click on Windows PowerShell (Admin):
    Figure 3.4 – Opening Windows PowerShell as an administrator

    Opening Windows PowerShell as an administrator

  2. Download MicroBurst using the following command:
    git clone https://github.com/NetSPI/MicroBurst.git

    Here’s what the output looks like:

    Figure 3.5 – Cloning the MicroBurst GitHub repository

    Cloning the MicroBurst GitHub repository

  3. Import the MicroBurst module into your PowerShell session with the following commands:
    cd .\MicroBurst\
    Import-Module .\MicroBurst.psm1
  4. The MicroBurst toolkit will import different PowerShell functions depending on which PowerShell modules you have installed on your system. We can see in our example that the MSOnline functions are not imported. This is fine for our use case. Also, the import could take a few minutes:
    Figure 3.6 – Importing the MicroBurst PowerShell module

    Importing the MicroBurst PowerShell module

  5. Use the Invoke-EnumerateAzureSubDomains function to identify potential targets that have a base name of azurepentesting:
    Invoke-EnumerateAzureSubDomains -Base azurepentesting
  6. As we can see in this example, the resulting output table indicates that there are Azure platform service instances with the azurepentesting resource name:
Figure 3.7 – MicroBurst enumerating services anonymously

MicroBurst enumerating services anonymously

The authors have set up the resources listed in the preceding screenshot for the purposes of this exercise.  Please use caution when following examples to avoid attacking or accessing resources not specifically defined by this post’s examples.

Important note: Remember to double-check the resource names that you are working in your exercises, to avoid attempting to access a resource that belongs to an Azure customer that you are not authorized to access.

 

Custom domains and IP ownership

Some Azure services allow customers to use custom domains. Additionally, some hosts may have redirects or transparent proxies in place to obfuscate the fact that the services are hosted in Azure. As part of the penetration testing process, you will want to fully understand where your targets live, as it could make a major difference in your scope. For example, your external penetration test scope may include specific IPs and hostnames for the environment that you are authorized to attack. If these hosts end up being in Azure, that will influence how we go about attacking those specific resources.

 

Identifying vulnerabilities in public-facing services

Once your anonymous attack surface has been identified and confirmed by the resource owner, you can start looking for vulnerabilities. As a very general rule of thumb, vulnerabilities in Azure can be broken down into three main categories: configuration, patching, and code-related.

Configuration-related vulnerabilities

This grouping of vulnerabilities can be broken into multiple sub-categories, but the two that we will be focusing on are Infrastructure as a Service (IaaS) and Platform-as-a-Service (PaaS) misconfigurations. These misconfigurations are typically caused by human error, resulting in sensitive information being exposed or unauthorized access to services.

IaaS configuration-related vulnerabilities

Azure IaaS services can be generalized as services that take the place of traditional infrastructure. The most common resources are virtual machinesvirtual machine scale sets and Windows Virtual Desktops (WVDs). These services can be deployed privately within a virtual network, connected to on-premises networks, or exposed to the internet using a public IP address.

Using the list of public IP addresses that a client has provided to us from the results, we can scan those IP addresses with common vulnerability scanning tools. Remember to always check the IP that you have been provided with for ownership and authorization.

 

PaaS configuration-related vulnerabilities

Using the list of enumerated Azure services from the previous section, we can start anonymously looking for vulnerabilities in those services. Now, we can dig deeper into that resource to find misconfigured containers in that storage account.

 

Patching-related vulnerabilities

While these issues are less commonly found, there are still plenty of new security patches released every week. As a result, there are plenty of forgotten or abandoned services, applications, and virtual machines that miss these patches.

From an external perspective, we will typically be scanning Azure virtual machines, with public IPs, for internet-facing services. These services can typically be fingerprinted by network scanning tools to identify the specific version of the software hosting the service.

Once the version of the software has been identified, we can either use vulnerability scanners (Nessus, Nexpose, and so on) or some basic Google skills to find potential vulnerabilities in these services.

 

Code-related vulnerabilities

The “cloudification” of existing applications and the drive toward cloud-native development are some of the driving forces bringing organizations into the Azure cloud. By porting existing or legacy applications into a cloud environment, many organizations are just bringing along many of the old vulnerabilities that previously existed in their original applications.

While there are many benefits to moving to the cloud, it is not a magic bullet to fix application vulnerabilities. Some of the existing common application issues can actually become more impactful in a cloud environment, as the platform can then be abused by these issues to escalate access.

At a high level, the following vulnerabilities can be very impactful in an Azure environment, so it may be worth prioritizing these while you are testing:

  • SQL injection (SQLi)
  • Local file include and directory traversal
  • Command injection
  • Server-side request forgery (SSRF)

 

In this post, we covered guidelines to successful Azure pentesting and hands-on exercises from the perspective of an outsider that has very little information about a target’s cloud assets. I hope you learned how to find misconfiguration vulnerabilities to exposed resources, which could lead to initial access to a tenant.

This tutorial is based on Chapter 3 of Packt’s Penetration Testing Azure for Ethical Hackers authored by David Okeyode & Karl Fosaaen. If you are looking for a hands-on approach to exploring Azure penetration testing methodologies, consider reading this book to protect your environment by identifying vulnerabilities in the Azure cloud.

Stay up to date with the latest threats

Our newsletter is packed with analysis of trending threats and attacks, practical tutorials, hands-on labs, and actionable content. No spam. No jibber jabber.