When it comes to the cloud, what is the most significant security risk? The cloud itself? Hybrid-cloud environment? Or even a multi-cloud scenario? The truth is that when it comes to cloud security, it’s all about misconfiguration, and there’s a lot of misconfiguration.

Security misconfiguration on cloud and hybrid environment leads to cyber attacks!

To harden the Cloud isn’t an easy task because it contains many layers and many components. Are you aware of your environment and know how to handle misconfiguration and its risks? Probably not all of the layers, elements, and features.
The following blog-post focuses on Azure security and misconfiguration in many aspects, layers, components, and features. The post will be updated weekly with many misconfigurations and the ways to mitigate each one of the misconfigurations.
How to avoid becoming another Azure misconfiguration statistic? Knowing your shared security responsibility in Azure is the first thing, and from there you must know the misconfiguration on your cloud.

Azure Security Risks and Recommendations

How to avoid becoming another Azure misconfiguration statistic? I wrote down the basic misconfigurations that must be part of your following security tasks by category.

Azure AD

Azure AD is the first service and a critical one because it handles all of the identity for every service, component, and feature. The default Azure AD configuration contains misconfiguration, and therefore you must make sure it configure with the relevant settings and recommendations.

App registrations

With App registrations, users can register applications, and with the Azure app authorization process, the user can grant the app access to the resources it needs. An attacker can use this opportunity to trick users into giving their malicious app access to one or more sensitive cloud resources.
The security risk is that the attacker can use this kind of attack based on App permissions many actions, for example:

• Spear phishing from the organization itself
• Stealing files and emails from any service on Office 365
• Recon and enumerating everything in Office 365 tenant and Azure

If this option is configured with the option yes, then non-admin users may register custom-developed applications for use within this directory. If this option is configured with an option no, only users with an administrator role may change these applications.
To mitigate App registration risk, make sure to set the App registration to NO. From this situation, only users with dedicated permissions can add an app to Office 365.

If this option is set to yes, then users may consent to allow applications that Microsoft does not publish to access your organization’s data if the user also has access to the data. This also means that the users will see these apps on their Access Panels.

If this option is set to no, then admins must consent to these applications before using them.

Admin Portal Access

The Azure AD administrative portal contains a large amount of sensitive information, and by default, any user under Azure AD can access it. This means that it is possible to login to the Azure portal as a standard user and browse around, view most of the settings and features, discover any user’s details, group membership, applications, etc.
The security risk is significant because an attacker can enumerate all Azure components and features.
When setting is set to No, it allows a non-administrator to use this Azure AD administration portal experience to access Azure AD resources to read or manage resources they own.
To mitigate, you must restrict all non-administrators from accessing any Azure AD data in the administration portal but do not limit such access using PowerShell or another client such as Visual Studio.

The security risk is when it is configured with the option of “Guests have the same access to Azure AD resources as member users” any guest can discover Office 365 and even bypass Microsoft Teams policy.

When guest access is restricted, guests can view only their own user profiles. Permission to view other users isn’t allowed even if the guest is searching by User Principal Name or objectId. Restricted access also restricts guest users from seeing the membership of groups they’re in.

To mitigate, you must make sure that Restricted access is configured for your Office 365 and Azure.

This setting determines whether guests have full access to enumerate all users and group memberships (most inclusive), limited access to other users and memberships, or no access to other users and group memberships, including groups they are a member of (most restrictive).

Device Access

Azure AD join allows you to join devices directly to Azure AD without the need to join on-premises Active Directory while keeping your users productive and secure. Azure AD join is enterprise-ready for both at-scale and scoped deployments.
The default allows any user to add the device to the Azure AD, and this is a risk because it provides the attacker a way to bypass many security controls. We must limit who can join Azure AD devices.

• Users may register their devices with Azure AD – Allow users to register their devices with Azure AD (Workplace Join). Enrollment with Microsoft Intune or Mobile Device Management for Office 365 requires Device Registration to configure either of these services.
• Require Multi-Factor Auth to join devices – You can choose whether users are required to provide an additional authentication factor to join their device to Azure AD. The default is No. We recommend requiring multi-factor authentication when registering a device.
• The recommendation is to use MFA when adding devices to Azure AD. When set to ‘Yes,’ users who are adding machines from the internet must add a second authentication method. This setting does not apply to hybrid Azure AD joined devices.

Azure Infrastructure

A central part of Azure is the infrastructure with IaaS components such as networking, VM’s, and more.

NSG Networks

Azure Network Security Groups enable you to control a resource’s inbound and outbound traffic, and they can undergo a considerable amount of change. The reason for this is simple: manually adding NSG rules is the easiest and fastest way to grant oneself access to a resource to perform a task, such as maintenance on an instance.
It’s critical to identify and correct these misconfigurations because bad actors use automation to detect them within minutes.

• Open ports for 0.0.0.0/0. This is a common NSG misconfiguration that opens up access to the Internet. It’s typically caused when someone on your team opens up this rule to perform a task, such as troubleshooting an instance or obtaining logs, and then often forgets to delete the rule once finished.
• Port 22, 3389, or a database port to perform maintenance on an instance, leaving behind an open door for hackers to discover.
• An NSG is modified by closing an open port, but that port is relied upon by another user of the same NSG, taking down the application.

NSG misconfiguration leads to a risk of allowing more traffic in than what is expected. These tiny, seemingly benign details often play an essential role in enabling them to breach the premises for attackers.
Apply primary deny on NSG or Apply Security Center’s Adaptive Network Hardening recommendations for network security group configurations that limit ports and source IPs based on actual traffic and threat intelligence.

Virtual Network and Subnet 

Azure Virtual Networks (VNet) are dedicated networks for your Azure accounts that are logically isolated from other VNets on Azure. A VNet can include one or more subnets.
Some examples of VNet and subnet misconfigurations that can lead to serious security incidents include

• A change to route tables or a network access control list (ACL) leaves a network exposed to unauthorized traffic.
• Lost or modified service tags that render the VNet hidden to management and security tools that track cloud resources using tags.

Use Virtual Network service tags to define network access controls on network security groups or Azure Firewall. Service tags can be used in place of specific IP addresses when creating security rules. Allow or deny the corresponding service’s traffic by specifying the service tag name (for example, API management) in the appropriate source or destination field of a rule.

RDP Access

Lockdown RDP to a source IP or IP Range – The default RDP port is 3389 that allows RDP connection from any IP in the world. When enabled, it is, therefore, a security risk. You can mitigate this by restricting RDP access to a specified source IP address or range with Azure NSG’s.
Every Virtual Machine will have its own NSG when deployed through Azure. You should apply these two Inbound Port rules:

• Allowing RDP from a specific IP address or range
• Denying all other RDP traffic

Brute force attacks can take days and even weeks to complete. An astounding number of attempts need to be made to connect through the RDP/SSH ports. So if you only have the port open when you need it, you reduce the vulnerability. Just-in-time VM access only opens the ports when you need them and locks them down to your IP address/range.
After you have finished what you were doing on the VM, it closes the port again.
You can enable JIT easily from Azure Security Center, configure it through an Azure Virtual Machine blade or configure a JIT policy on a VM programmatically.
Pros: Reduces the risk of successful brute force attacks as the port is only open when you need it
Cons: You still need to open port 3389 to the public internet, leaving you vulnerable within the allotted time frame.
RDP using a Private IP address across a Site to Site VPN – The ideal form of RDP connection is RDP across a Site-to-Site VPN connection. This keeps your communication with the Virtual Machine off the public internet granting protection against port scanning, brute force, and DDOS attacks.
With a VPN gateway from the Azure network to the on-premises network, Azure VMs can be RDP’ed using a private IP address – protected from the public internet’s prying eyes.
The public IP address must remove altogether if you don’t need it. If you need to use it for something, the RDP port (usually 3389) will be closed. This is an effective and seamless approach to connect to Azure VM without public IP addresses, reducing the threat of attacks.

Storage with Any Access

Azure Blob storage is a powerful and convenient way of sharing data on the cloud. It supports the following 3 access control (level) options:

• Private (no anonymous access)
• Blob (anonymous read access for blobs only)
• Container (anonymous read access for containers and blobs)

Configuring access level as either 2 latter options (anonymous read access) naturally presents a security risk of unauthorized access to data, data leakage, exfiltration, etc.
In a production environment, all blob storage should be set to private, disallowing any anonymous access.

VPN Gateway

When working with VPN gateway subnets, avoid associating a network security group (NSG) to the gateway subnet. Associating a network security group to this subnet may cause your VPN gateway to stop functioning as expected. However, enable network security groups for other non-VPN gateway subnets in your Virtual Network.
When the VPN gateway is not configured well, the security risk is the way to expose the hybrid environment for open ports and allow the attacker to scan the network externally.
To mitigate, you must filter network traffic with a network security group using the Azure portal and make sure you’ve got a route-based VPN gateway using the Azure portal.

More about Site-to-Site connection

Azure Functions

Azure Functions is a cloud service available on-demand that provides all the continually-updated infrastructure and resources needed to run your applications. You focus on the pieces of code that matter most to you, and Functions handles the rest. Functions provide serverless compute for Azure.

Injection flaws

Injection attacks try to exploit code that passes untrusted inputs directly to an interpreter before being executed or evaluated. Since serverless functions can be triggered from different event sources like Blob, CosmosDB, and more, injections are not strictly limited to inputs coming directly from the API calls, and functions can consume input from each type of possible event source.
To mitigate, you must to never trust input or make any assumptions about its validity and always use safe APIs that sanitize or validate the input. When possible, use APIs which bind or parameterize variables.

Function secrets

There is always a need to store and maintain secrets in our application. Secrets could be API Keys, credentials to other resources, Crypto-keys, and sensitive configuration settings.
Storing such secrets in a plain text configuration file could be uploaded to and leaked through shared repositories—there multiple tools that hackers use to identify such leaked keys. There are many storied.
While environment variables are a useful way to persist data across serverless function executions, in some cases, such environment variables can leak and reach the wrong hands.
It is critical to store such secrets in a secure, encrypted storage environment.
To mitigate, you can use the Microsoft CredScan tool to identify credential leaks, ensure your cred is safe, and manage encryption keys in a centralized encryption key management infrastructure or service like Azure Key-vault.

Authentication and Authorization

Serverless architecture requires orchestrating many functions and services on the overall system logic. While some functions expose public APIs, others serve as a pipe between processes, and there are multiple ways to trigger them, including internal trigger events.
Imagine a serverless application that exposes a set of public APIs, all of which enforce proper authentication. At the other end of the system, the application reads files from a blob storage service where file contents are consumed as an input to specific serverless functions.
The risk is when a proper authentication is not applied to the cloud storage service, the system is exposing an unauthenticated rogue entry point—an element not considered during system design.
The serverless architecture requires a solid access control configuration for each of the resources.
To mitigate

• Review and apply Authentication and authorization in Azure App Service.
• Follow Azure Identity Management and access control security best practices.
• External-facing resources should require authentication and access control.

Azure Kubernetes

Misconfigured Kubeflow workloads are a security risk.

Kubeflow is an open-source project, started as a project for running TensorFlow jobs on Kubernetes.
Nodes that are used for ML tasks are often relatively robust, and in some cases, including GPUs. This fact makes Kubernetes clusters used for ML tasks a perfect target for crypto mining campaigns, which was the aim of this attack.
The attacker used an exposed dashboard for gaining initial access to the cluster. The execution and persistence in the cluster were performed by a container that was deployed in the cluster. The attacker managed to move laterally and deploy the container using the mounted service account. Finally, the attacker impacted the cluster by running a cryptocurrency miner.
To mitigate, make sure to check if your cluster is impacted?

1. Verify that the malicious container is not deployed in the cluster. The following command can help you to check it:

kubectl get pods –all-namespaces -o jsonpath=”{.items[*].spec.containers[*].image}”  | grep -i ddsfdfsaadfs 

2. In case Kubeflow is deployed in the cluster, make sure that its dashboard isn’t exposed to the internet: check the type of the Istio ingress service by the following command and make sure that it is not a load balancer with a public IP:

kubectl get service istio-ingressgateway -n istio-system

More about this risk with Misconfigured Kubeflow workloads is a security risk – Microsoft Security.
More about Azure Security misconfiguration and security best practices soon in this post.