EAST - Extensible Azure Security Tool - Documentation

Extensible Azure Security Tool (Later referred as E.A.S.T) is tool for assessing Azure and to some extent Azure AD security controls. Primary use case of EAST is Security data collection for evaluation in Azure Assessments. This information (JSON content) can then be used in various reporting tools, which we use to further correlate and investigate the data.

This tool is licensed under MIT license.

Yours truly Nixu Cloud Security Team

Preview branch introduced

Changes:

Installation now accounts for use of Azure Cloud Shell's updated version in regards to depedencies (Cloud Shell has now Node.JS v 16 version installed)

Checking of Databricks cluster types as per advisory

Audits Databricks clusters for potential privilege elevation - This control requires typically permissions on the databricks cluster"

Content.json is has now key and content based sorting. This enables doing delta checks with git diff HEAD^1 ¹ as content.json has predetermined order of results

¹Word of caution, if want to check deltas of content.json, then content.json will need to be "unignored" from .gitignore exposing results to any upstream you might have configured.

Use this feature with caution, and ensure you don't have public upstream set for the branch you are using this feature for

Change of programming patterns to avoid possible race conditions with larger datasets. This is mostly changes of using var to let in for await -style loops

---

Current status of the tool is beta

Fixes, updates etc. are done on "Best effort" basis, with no guarantee of time, or quality of the possible fix applied We do some additional tuning before using EAST in our daily work, such as apply various run and environment restrictions, besides formalizing ourselves with the environment in question. Thus we currently recommend, that EAST is run in only in test environments, and with read-only permissions. All the calls in the service are largely to Azure Cloud IP's, so it should work well in hardened environments where outbound IP restrictions are applied. This reduces the risk of this tool containing malicious packages which could "phone home" without also having C2 in Azure. Essentially running it in read-only mode, reduces a lot of the risk associated with possibly compromised NPM packages (Google compromised NPM) Bugs etc: You can protect your environment against certain mistakes in this code by running the tool with reader-only permissions Lot of the code is "AS IS": Meaning, it's been serving only the purpose of creating certain result; Lot of cleaning up and modularizing remains to be finished There are no tests at the moment, apart from certain manual checks, that are run after changes to main.js and various more advanced controls. The control descriptions at this stage are not the final product, so giving feedback on them, while appreciated, is not the focus of the tooling at this stage As the name implies, we use it as tool to evaluate environments. It is not meant to be run as unmonitored for the time being, and should not be run in any internet exposed service that accepts incoming connections. Documentation could be described as incomplete for the time being EAST is mostly focused on PaaS resource, as most of our Azure assessments focus on this resource type

No Input sanitization is performed on launch params, as it is always assumed, that the input of these parameters are controlled. That being said, the tool uses extensively exec() - While I have not reviewed all paths, I believe that achieving shellcode execution is trivial. This tool does not assume hostile input, thus the recommendation is that you don't paste launch arguments into command line without reviewing them first.

Depedencies

To reduce amount of code we use the following depedencies for operation and aesthetics are used (Kudos to the maintainers of these fantastic packages)

Other depedencies for running the tool: If you are planning to run this in Azure Cloud Shell you don't need to install Azure CLI:

This tool does not include or distribute Microsoft Azure CLI, but rather uses it when it has been installed on the source system (Such as Azure Cloud Shell, which is primary platform for running EAST)

Azure Cloud Shell (BASH) or applicable Linux Distro / WSL

Requirement description Install

✅ AZ CLI	AZCLI USE	curl -sL https://aka.ms/InstallAzureCLIDeb | sudo bash
✅ Node.js runtime 14	Node.js runtime for EAST	install with NVM

Controls

EAST provides three categories of controls: Basic, Advanced, and Composite

The machine readable control looks like this, regardless of the type (Basic/advanced/composite):

Basic

Basic controls include checks on the initial ARM object for simple "toggle on/off"- boolean settings of said service.

Example: Azure Container Registry adminUser

acr_adminUser

Portal EAST

	if (item.properties?.adminUserEnabled == false ){returnObject.isHealthy = true }

Advanced

Advanced controls include checks beyond the initial ARM object. Often invoking new requests to get further information about the resource in scope and it's relation to other services.

Example: Role Assignments

Besides checking the role assignments of subscription, additional check is performed via Azure AD Conditional Access Reporting for MFA, and that privileged accounts are not only protected by passwords (SPN's with client secrets)

Example: Azure Data Factory

ADF_pipeLineRuns

Azure Data Factory pipeline mapping combines pipelines -> activities -> and data targets together and then checks for secrets leaked on the logs via run history of the said activities.

Composite

Composite controls combines two or more control results from pipeline, in order to form one, or more new controls. Using composites solves two use cases for EAST

You cant guarantee an order of control results being returned in the pipeline You need to return more than one control result from single check

Example: composite_resolve_alerts

Get alerts from Microsoft Cloud Defender on subscription check Form new controls per resourceProvider for alerts

Reporting

EAST is not focused to provide automated report generation, as it provides mostly JSON files with control and evaluation status. The idea is to use separate tooling to create reports, which are fairly trivial to automate via markdown creation scripts and tools such as Pandoc

While focus is not on the reporting, this repo includes example automation for report creation with pandoc to ease reading of the results in single document format.

While this tool does not distribute pandoc, it can be used when creation of the reports, thus the following citation is added: https://github.com/jgm/pandoc/blob/master/CITATION.cff

---

Running EAST scan

This part has guide how to run this either on [email protected], or BASH on Azure Cloud Shell (obviously Cloud Shell is Linux too, but does not require that you have your own linux box to use this)

⚠️If you are running the tool in Cloud Shell, you might need to reapply some of the installations again as Cloud Shell does not persist various session settings.

Fire and forget prerequisites on cloud shell

jump to next step

Detailed Prerequisites (This is if you opted no to do the "fire and forget version")

Prerequisites

Pandoc installation on cloud shell

Installing pandoc on distros that support APT

Login Az CLI and run the scan

Generate report

cd EAST; node templatehelpers/eastReports.js --doc

If you want to include all Azure Security Benchmark results in the report

cd EAST; node templatehelpers/eastReports.js --doc --asb

Export report from cloud shell

pandoc -s fullReport2.md -f markdown -t docx --reference-doc=pandoc-template.docx -o fullReport2.docx

Azure Devops (Experimental) There is Azure Devops control for dumping pipeline logs. You can specify the control run by following example:

node ./plugins/main.js --batch=10 --nativescope=true --roleAssignments=true --helperTexts=true --checkAad=true --scanAuditLogs --composites --subInclude=$subId --azdevops "organizationName"

Licensing

Community use

Share relevant controls across multiple environments as community effort

Company use

Companies have possibility to develop company specific controls which apply to company specific work. Companies can then control these implementations by decision to share, or not share them based on the operating principle of that company.

Non IPR components

Code logic and functions are under MIT license. since code logic and functions are alredy based on open-source components & vendor API's, it does not make sense to restrict something that is already based on open source

If you use this tool as part of your commercial effort we only require, that you follow the very relaxed terms of MIT license

Read license

Principles

AZCLI USE

Existing tooling enhanced with Node.js runtime

Use rich and maintained context of Microsoft Azure CLI login & commands with Node.js control flow which supplies enhanced rest-requests and maps results to schema.

This tool does not include or distribute Microsoft Azure CLI, but rather uses it when it has been installed on the source system (Such as Azure Cloud Shell, which is primary platform for running EAST)

Speedup

View more details

✅Using Node.js runtime as orchestrator utilises Nodes asynchronous nature allowing batching of requests. Batching of requests utilizes the full extent of Azure Resource Managers incredible speed.

✅Compared to running requests one-by-one, the speedup can be up to 10x, when Node executes the batch of requests instead of single request at time

Parameters reference

Example:

Param Description Default if undefined

--nativescope	Currently mandatory parameter	no values
--shuffle	Can help with throttling. Shuffles the resource list to reduce the possibility of resource provider throttling threshold being met	no values
--roleAssignments	Checks controls as per microsoft.authorization	no values
--includeRG	Checks controls with ResourceGroups as per microsoft.authorization	no values
--checkAad	Checks controls as per microsoft.azureactivedirectory	no values
--subInclude	Defines subscription scope	no default, requires subscriptionID/s, if not defined will enumerate all subscriptions the user have access to
--namespace	text filter which matches full, or part of the resource ID example /microsoft.storage/storageaccounts all storage accounts in the scope	optional parameter
--notIncludes	text filter which matches full, or part of the resource ID example /microsoft.storage/storageaccounts all storage accounts in the scope are excluded	optional parameter
--batch	size of batch interval between throttles	5
--wait	size of batch interval between throttles	1500
--scanAuditLogs	optional parameter. When defined in hours will toggle Azure Activity Log scanning for weak authentication events defined in: scanAuditLogs	24h
--composites	read composite	no values
--clearTokens	clears tokens in session folder, use this if you get authorization errors, or have just changed to other az login account use az account clear if you want to clear AZ CLI cache too	no values
--tag	Filter all results in the end based on single tag--tag=svc=aksdev	no values
--ignorePreCheck	use this option when used with browser delegated tokens	no values
--helperTexts	Will append text descriptions from general to manual controls	no values
--reprocess	Will update results to existing content.json. Useful for incremental runs	no values

Parameters reference for example report:

Param Description Default if undefined

--asb	gets all ASB results available to users	no values
--policy	gets all Policy results available to users	no values
--doc	prints pandoc string for export to console	no values

(Highly experimental) Running in restricted environments where only browser use is available

Read here Running in restricted environments

Developing controls

Developer guide including control flow description is here dev-guide.md

Updates and examples

Auditing Microsoft.Web provider (Functions and web apps)

✅Check roles that are assigned to function managed identity in Azure AD and all Azure Subscriptions the audit account has access to

✅Relation mapping, check which keyVaults the function uses across all subs the audit account has access to

✅Check if Azure AD authentication is enabled

✅Check that generation of access tokens to the api requires assigment .appRoleAssignmentRequired

✅Audit bindings

Function or Azure AD Authentication enabled Count and type of triggers

✅Check if SCM and FTP endpoints are secured

Azure RBAC baseline authorization

⚠️Detect principals in privileged subscriptions roles protected only by password-based single factor authentication.

Checks for users without MFA policies applied for set of conditions Checks for ServicePrincipals protected only by password (as opposed to using Certificate Credential, workload federation and or workload identity CA policy)

Maps to App Registration Best Practices

An unused credential on an application can result in security breach. While it's convenient to use password. secrets as a credential, we strongly recommend that you use x509 certificates as the only credential type for getting tokens for your application

✅State healthy - User result example

⚠️State unHealthy - Application principal example

Contributing

Following methods work for contributing for the time being:

Submit a pull request with code / documentation change Submit a issue issue can be a:

⚠️Problem (issue)

Feature request

❔Question

Other

By default EAST tries to work with the current depedencies - Introducing new (direct) depedencies is not directly encouraged with EAST. If such vital depedency is introduced, then review licensing of such depedency, and update readme.md - depedencies There is nothing to prevent you from creating your own fork of EAST with your own depedencies