Building a Security Training Testbed for Azure

This blog was originally published by Adobe here.

Written by Akriti Srivastava, Security Analyst, Adobe OpSec Team.

With any cloud platform, a lack of understanding of required security controls and unintentional misconfigurations can bring additional risk to the DevSecOps process. A test environment, where engineers can safely learn new attack methodologies, is the preferred approach, but what do you do if such a testbed isn’t readily available from the security and development community?

Introducing AzGOAT

Learning security in complex public cloud infrastructure environments can be challenging. Mature testbeds for AWS and a host of web applications are readily available from their respective development communities. However, a similar “vulnerable-by-design” learning environment for Azure that met our needs did not readily exist.

Thus, we created our own Azure vulnerability testbed, called AzGOAT, to help our teams better manage this potential risk. AzGOAT is a simulated lab environment for Azure developed by the Adobe Operational Security team. Comprised of a collection of real-life scenarios encountered while performing security assessments for Adobe products hosted on Azure and a “deliberately insecure” Azure test environment in which to model a variety of attacks, AzGOAT helps enable developers to improve their Azure security skills by completing capture-the-flag-styled scenarios.

How does AzGOAT work?

Developers run the setup script to create the vulnerable environment in a non-Adobe Azure account, keeping it completely separated from our prod/dev/stage environments. After spinning up AzGOAT, pen-testers, engineers, and ops teams can simulate how an attacker might perform an intrusion in an Azure environment.

In addition to mistakes that we encountered through our own development processes, the testbed also includes several other insecure coding errors and misconfigurations pulled from Microsoft bulletins, security interest groups, and external Azure security researchers. We grouped these together in scenarios that provide different paths of entry and lateral movement in the vulnerable testbed environment.

Three scenarios

Here are three common, avoidable attack scenarios that we integrated into AzGOAT, which can help developers understand how to avoid common security issues, such as detailed data enumeration, privilege escalation, persistence, and misconfigured code in Azure.

Scenario 1: SSRF (Server-Side Request Forgery) leads to compromise

In this scenario, a web application on “Machine A” is publicly accessible and allows a URL as input, which the attacker tests to see if the app accepts the URL. “Machine B” lives on a corporate network and is only accessible through a specific IP. In this scenario, the attacker tries to access an internal .dat file from “Machine B” using ‘test integration functionality’ of the web app on “Machine A.” This .dat file stores storage account credentials, which help the attacker to gain access to “Machine B” and read sensitive information.

Scenario 2: SSRF in a publicly hosted Azure application leads to storage account key leakage

If a publicly accessible web app on “Machine ‘A” can query metadata services, an attacker can gain access to Managed Identity Tokens. Armed with these tokens, the attacker can query Azure ReST APIs for a list of storage accounts and get the access key for any of those accounts.

Scenario 3: Leaked credentials from a publicly available BLOB leads to compromise of database

This scenario replicates an attacker accessing a publicly available BLOB, where they can find SSH credentials to connect to a virtual machine. In the virtual machine, the attacker then accesses a web.config file, which contains the connection string for an Azure Cosmos database, giving the attacker access to the database.

What’s next?

After positive initial feedback and suggestions for additional tools, we plan to keep the AzGOAT testbed up to date with newly discovered attack scenarios. In addition, to help developers spin up an AzGOAT environment more quickly, we plan to automate the setup phase in the near future.To aid the greater Azure DevSecOps community, we also plan to open-source AzGOAT at a future date.