Pentesting Azure — The Report

Recently on the OWASP DevSlop Show, Teri Radichel and I performed a security assessment of the Azure implementation for DevSlop.co. We did it based on my previous blog post, Pentesting Azure — Thoughts on Security in Cloud Computing. You may want to read that article before you continue.

You can watch the video of the security assessment here. Subscribe to the DevSlop YouTube Channel for more awesome content like this!

The first step to any PenTest is setting your Scope, Goals and Rules of Engagement for yourself and your client. You would restate this in your findings report, and you should always have a signed agreement from the client before you test anything.

Below is the scope of the testing and assessment that we did on the DevSlop show.

Scope: https://DevSlop.co, the DevSlopPatty Resource Group, the TANYA Azure Subscription (my subscription ID would be included in the doc). Nothing more.

Rules of engagement: Do not attack other tenants, or the Azure Service Fabric (that’s Microsoft’s underlying infrastructure that makes Azure). Some manual testing, some scanning, but mostly using Azure Security Center. Also: dates and times for testing.

Goals: Lock down DevSlop.co and my entire subscription.

Inform: We informed Azure that we were going to be performing security testing activities, and received acknowledgement before starting. **

** It is not mandatory that you inform Microsoft in advance of a PenTest, but for most other cloud providers you must ask permission. Informing Azure in advance of your testing takes 2 minutes, and may simplify your testing. Definitely worth doing.**

Executive summary:

Turn on all the security features in Azure Security Center (app whitelisting, file integrity monitoring), select a network security model and apply it (use network security groups), fix your VM security misconfigurations and keep patching it, address the 2 database VA (Vulnerability Assessment scan) findings, and consider getting a WAF (Web Application Firewall).

Risk Summary:

This Azure implementation (application + network + infrastructure) is very secure from an outsider-threat, as the application has had regular security testing and is using only known-to-be-secure and up to date components and frameworks. The subscription itself is also very secure from outside threats, thanks to the usage of Azure Security Center, a security policy, and the tight controls over subscription Access (MFA+ Difficult password + excellent password hygiene).

This system is not very safe from an insider-threat, assuming the malicious actor could gain access to the subscription. As only this subscription, not the “top level subscription”, was in scope, this was not investigated.

If the application was compromised it appears that the threat protection could potentially stop some types of attacks (SQL Server or Storage attacks only), and report on the damage after, however the protections against malicious attacks is not as substantial as it could be; multiple tools would be better.

Ifyou want to learn about about what we did to get these results, read the previous article: Pentesting Azure — Thoughts on Security in Cloud Computing. If you prefer to see what we did and follow along with us, watch the video. Better yet: do both.

PenTest Report — The Findings

A “+” indicates a pass, while a “X” indicates a fail of the test. Multiple “+” were used when a defense offers protection in multiple ways.

1. Azure Security Centre (ASC) is turned on, with the default security policy.++
2. MFA (Multi-Factor Authentication) is enabled for subscription access, use of a 64-bit random character that is saved into a password manager is one of the factors, the other is Microsoft’s Authenticator app, which requires not only physical access to and unlocking of a second device, it also requires a finger print. It could be argued that 3 factor auth is being used. +++
3. ASC has 100% coverage of all subscriptions that were in scope of this assessment. +
4. TANYA subscription was *not* compliant with the Azure Policy, earning a secure score of 340/580. (points are removed for each item below)
5. JIT was enabled on the one VM in the subscription, properly configured +
6. Threat Protection was enabled on all possible resources, properly configured. +
7. Regularly VAs are enabled and schedule for the one database (+), however the database is not in compliance with VA results (X).
8. There is no network security plan or model in place. X
9. There are no Network Security Groups (NSGs). X
10. Adaptive Application Controls (Application Whitelisting) is not enabled. X
11. File Integrity Monitoring is not enabled. X
12. DevSlop.co is not protected by a WAF (web app fire wall). X
13. DevSlop.co forces HTTPS only on the app service. +
14. There are no other security tools installed, such as IPS/IDS (intrusion prevention and detection systems), SIEM, or any other products or tools. X

Score: 10/17

Database Specific Findings:

1. Firewall rules not restrictive enough/non-existant X
2. Using DB Owner privilege for an app that definitely does not require it (apply least privilege) X
3. Sensitive data columns are not labelled properly X
4. Regular VAs configured +
5. Threat Protection & Detection Enabled +
6. JIT enabled +
7. Auditing and logging enabled +
8. Database not internet accessible. +

5/8

Compute-Specific Findings (on one single VM):

1. Missing disc encryption on server X
2. 66 Critical security misconfigurations X
3. 28 Warning security misconfigurations X
4. JIT Configured +

1/4 (note: it does not list all the things we did correctly in this section)