Cloud providers have a wide variety of different predesigned service offerings, but they’re intended to be created and used quickly and easily, sometimes to the detriment of having secure configurations by default. It can be confusing for developers to know if a default was chosen with security in mind or just for ease of deployment, and often times it is not straightforward to even find the right places to modify configuration parameters. Luckily, configuration is something that can easily be verified via the cloud provider’s APIs and some automation.

In the case of Amazon’s AWS there are some good tools out there already, but the Azure space is lacking something that gives us the information we need and the flexibility to use it as we want. This was the motivation for inzure.

This blog aims to introduce inzure and some of its more useful features for both security professionals and businesses using the Azure cloud.

Danny Rosseau introducing inzure at SnoFROC – Denver OWASP Conference

What is inzure?

inzure is, first and foremost, a library for testing Azure infrastructure configurations and gathering security relevant data by leveraging Azure’s Go APIs. It comes with a command line tool, but your business can directly use the library to tailor it to your own specific needs with minimal code. inzure can be used for discovering misconfigurations and then either reporting or fixing them all in less than 100 lines of Go code (or sometimes none at all). We use inzure at the start of every Azure assessment and it enables us to get started testing on minute 1 of the first day.
Let’s go through two use cases – inzure for security professionals and inzure for businesses – and learn some things about inzure along the way.

inzure for security professionals

Using inzure as a security professional is similar to using other Azure recon tools out there, but with more flexibility and a more powerful querying mechanism. When I start an assessment, I run an inzure gather to get information on all inzure supported resources and then inzure attacksurface to get started right away. inzure attacksurface allows you to get a picture of exposed services, usage looks like this:

I typically save the attacksurface output and then use jq to pipe its output to other tools such as nmap or a brute force content discovery tool on the web applications. The APIServices output gives you all of the frontend and backend endpoints, so you can start trying to hit both, which may allow you to circumvent authentication if the backend is exposed to the internet and only expecting requests from the API service for example.

There is a lot of data in an inzure JSON though and sometimes we want to find specific things or ask questions. This is where inzure’s query strings come into play, so let’s take a quick look at what they’re all about.

inzure query strings

inzure query strings are a powerful tool for querying inzure data: you can think of them as a minimal query language to ask for resources that match some conditions. These conditions can be resource group names, resource names, values of know configuration parameters, or even the output of object methods. The command line interface to query strings is inzure search: you can pass any valid query string to it and it will filter the data accordingly. We’ll save an in depth look at how to use query strings for another post, but a quick example should give some idea of how useful they can be.

Here we’re seeing how the included command line tool, along with autocompletion, can make querying inzure data straightforward. We ask inzure to return us the information it has about a given resource type, WebApps, but we also ask it to filter the results it gives based on a condition. Definitely check out the query string documentation and the next blog post if you want to know more.

inzure for businesses

While command line tools are nice for security professionals and curious developers, they don’t typically fit into business logic well. You end up with a collection of shell scripts that are difficult to maintain and inefficient. This is why we designed inzure as a library first: you can use it in your own workflow and tailor it to your specific needs. The repository has a few examples that are worth checking out. The slackposter example will post a message to a Slack channel:

The other example easily fixes an issue:

These examples represent the two main ways we see inzure fitting into your business: automated reporting and/or remediation. Both of these start off with the same flows: you gather some inzure data, run some tests, and then take the steps you think are appropriate. This shared flow and potential for defining your own more complex inzure programs also motivated us to design our own Go plugin based reporting framework around inzure, and we’ll release and discuss that in the next blog post. The teaser is that it leverages Go plugins to support a dynamic and sharable testing workflow that requires minimal code.

Closing remarks

inzure is a very powerful library if you know how to leverage it correctly. With the soon to be released reporting framework, it can completely revamp the view you have of the security critical configurations in your Azure subscriptions. It takes a bit of time to get things setup and decide on what you’d like to investigate and how to handle it, but once you have that part complete, everything becomes much simpler and significantly less error prone. You will no longer have to rely on the Azure portal or writing a significant amount of boiler plate code for checking your own configurations.

inzure is open source and we’d love contributions, go ahead and fork and make pull requests as you see fit!