Cloud Misconfiguration and Risks – Azure
What is the most significant security risk when it comes to the Cloud? 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 one big misconfiguration, and there’s a lot of misconfiguration. But it’s not only the misconfiguration because the Cloud and multi-cloud are very dynamic and lead to misinformation, skills gaps, and more.
A security breach that comes from misconfiguration is your fault!
ItHardening the Cloud is difficultecause it contains many layers and 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 how to mitigate each misconfiguration.
How to avoid becoming another Azure misconfiguration statistic? Knowing your shared security responsibility in Azure is the first thing; 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 critical service because it handles all identities for every service, component, and feature. The default Azure AD configuration contains misconfiguration; therefore, you must ensure it configures 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 and many actions, for example:
- Spear phishing from the organization itself
- Stealing files and emails from any service on Office 365
- Recon and enumerate everything in Office 365 tenant and Azure
If this option is configured with yes, non-admin users may register custom-developed applications within this directory. Only users with an administrator role may change these applications if this option is configured with an option no.
To mitigate the App registration risk, set the App registration to NO. From this situation, only users with dedicated permissions can add an app to Office 365.
Enterprise Applications
Users can consent to apps accessing company data on their behalf, allowing users assigned to the app to sign into existing service principles. But, it does not grant users the right to create new service principles.
When an attacker enables it, the security risk can manipulate the user to consent to an app with high permissions and steal creds and the first initial access to the Azure and Office 365 tenant.
To mitigate, you must enforce Administrators to Provide Consent for Apps Before Use because it is a high risk.
Admin Portal Access
The Azure AD administrative portal contains a large amount of sensitive information; by default, any user under Azure AD can access it. This means it is possible to log in to the Azure portal as a standard user and browse, view most of the settings and features, and discover user details, group membership, applications, etc.
The security risk is significant because an attacker can enumerate all Azure components and features.
When the 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 this, you must restrict all non-administrators from accessing Azure AD data in the administration portal. Do not limit such access using PowerShell or another client such as Visual Studio.
External Collaboration Access
Guest objects are among the most significant risks in Azure and Office 365. A guest option is like an Active Directory trust relationship to your Azure AD. Once guest users have the default permissions, they guest user can enumerate and discover the Azure and Office 365 environments.
Azure AD restricts what external guest users can see in their organization in Azure AD. Guest users are set to a limited permission level by default in Azure AD, while the default for member users is the complete set of default user permissions.
The guest permissions level on your Azure AD are:
| Permission level | Access level |
|---|---|
| Same as Member users | Guests have the same access to Azure AD resources as member users |
| Limited access (default) | Guests can see members of all non-hidden groups |
| Restricted access (new) | Guests can’t see membership of any groups |
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 user profiles. Permission to view other users isn’t allowed even if the guest searches by User Principal Name or objectId. Restricted access also restricts guest users from seeing their membership in groups.
To mitigate this, you must ensure 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 members of (most restrictive).
Device Access
Azure AD join allows you to join devices directly to Azure AD without joining 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, which is risky because it allows the attacker 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 must 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 add 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, VMs, 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.
Identifying and correcting these misconfigurations is critical 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 than expected. These tiny, seemingly benign details often play an essential role in enabling them to breach the premises of 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 traffic and threat intelligence.
Virtual Network and Subnet
Azure Virtual Networks (VNet) are dedicated networks for your Azure accounts 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
- Changing route tables or a network access control list (ACL) exposes a network to unauthorized traffic.
- Lost or modified service tags hide the VNet from 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.
RDP Access
Lockdown RDP to a source IP or IP Range – The default RDP port is 3389, allowing 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 NSGs.
Every Virtual Machine will have its 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. Many attempts must be made to connect through the RDP/SSH ports. So if you only have the port open when needed, you reduce the vulnerability. Just-in-time VM access only opens the ports and locks them down to your IP address/range when needed.
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. The RDP port (usually 3389) will be closed if you need to use it for something. This is an effective and seamless approach to connecting 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 to share cloud data. It supports the following three 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 option (anonymous read access) naturally presents a security risk of unauthorized access to data, data leakage, exfiltration, etc.
All blob storage should be private in a production environment, disallowing anonymous access.
VPN Gateway
Avoid associating a network security group (NSG) to the gateway subnet when working with VPN gateway subnets. Associating a network security group with 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 exposes the hybrid environment for open ports and allows 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 an on-demand cloud service 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 computing 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. Functions can consume input from each type of possible event source.
To mitigate, you must never trust input or make assumptions about its validity and always use safe APIs that sanitize or validate the input. When possible, use APIs that 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 and leaked through shared repositories—hackers use multiple tools to identify such leaked keys. There are many storied.
While environment variables are a helpful way to persist data across serverless function executions, in some cases, such environment variables can leak and reach the wrong hands.
Storing such secrets in a secure, encrypted storage environment is critical.
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 that 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 proper authentication is not applied to the cloud storage service. The system exposes an unauthenticated rogue entry point—an element not considered during system design.
The serverless architecture requires a solid access control configuration for each resource.
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 that started as a project for running TensorFlow jobs on Kubernetes.
Nodes 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 to gain initial access to the cluster. The execution and persistence in the cluster were performed by a container deployed in the cluster. The attacker moved laterally and deployed 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.
- 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
- 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
