According to Gartner, the global market for cloud infrastructure services increased by 30% in 2022, exceeding $100 billion for the first time. AWS and Azure account for almost two-thirds of this figure. While many organizations benefit from these platforms, the popularity of the cloud can also present significant security challenges. The ethical hacking of Azure and AWS by expert practitioners provides key insights into potential vulnerabilities and the ways in which threat actors are able to exploit them. In this article, we outline the most common types of cloud security threats on AWS and Azure and some defenses against them, from the perspective of an experienced offensive security specialist.
Cloud Security Threats on AWS and Azure
Cloud Storage Attacks
Cloud storage attacks are a significant challenge for organizations because they target data and other important business assets. An important first step for pen testers in identifying these types of cloud security threats is to check enumerated buckets for unauthenticated user access. Enumeration can lead to discovery of Azure Shared Access Signature (SAS) links. For these links, pen testers will start with a similar Azure URL structure which will also contain “ss”, “srt”, “sp”, “se” and “sig” parameters and will then load it via the Azure Storage Explorer.
An example of an Azure SAS link is:
https://..core.windows.net/?ss=bfqt&srt=sco&sp=rwdlacup&se=2023-09-15T13:00:00Z&sip=88.208.222.83&sig=ACNA15d%2B%2BZSzPtPO71fMS34k%2FhLf2W13hjnamoGffIm%3D A key defense against cloud storage attacks is to check your organization’s containers to ensure that appropriate permissions are set up. Confirm that any open buckets are meant to be open. If utilizing SAS, it is also important to establish that permissions aren’t too broad-ranging.
Password Spraying Against Azure/O365 Accounts
If in-scope, penetration testers may be able to use password spraying, which targets commonly used passwords, such as those including the season and year, for example, “Summer2023.” Pen testers will choose the type of password that an end user would use, such as Fall2023!, Autumn2023! and September2023! This is then sprayed to valid accounts using a tool such as MSOLSpray or CredMaster.
A useful layer of defense against these types of cloud security threats on AWS and Azure environments is to implement and maintain a strong password policy, supported by multi-factor authentication (MFA). Keep in mind that attackers can spray passwords slowly, even using different IP addresses for each request. Implement detection mechanisms suitable for your organization, based on whether attacks are likely to be on a large number of failed logins from a single IP or on successful login from cloud service provider IPs.
Social Engineering
Attackers often attempt to phish, vish or smish user credentials to cloud services to gain credentials and also permissions. An example of this is an illicit consent grant attack in Azure. In this type of attack, the threat actor registers a multitenant application in their own tenant. The app is usually configured for user.read and user.readbasic.all permissions. If consent is granted, the attacker can obtain user access tokens.
Regular training and awareness sessions for all employees are a critical aspect of defending against phishing. Ensure detection with URL rewriting via email protection. Apply user behavior analytics, message trace logs and audit trace logs, etc.
Implement phishing-resistant authentication methods, such as devices enrolled in Fast Identity Online (FIDO), especially for privileged users. Alongside this, review and update IT helpdesk policies and exception-handling procedures to address social engineering attacks aimed at enrolling or disabling multifactor authentication (MFA) and unauthorized devices.
Use creative Conditional Access control (CAC) policies to reduce your attack surface, for example:
- If your corporate device policy only includes Windows for desktop and iOS mobile devices, block Android and MacBooks from authenticating.
- Disable or limit the scope of allowed MFA methods, such as SMS and voice approval, or unused MFA application types.
- Consider blocking or flagging authentication attempts and enrollment from geographies outside the scope of your organization’s footprint.
- Limit the number of allowed MFA devices per user and require extra authentication factors when authorizing MFA devices.
- Review and reduce session token lifetimes and implement continuous access evaluation features (CAE), where available
To defend effectively against illicit consent grant, ensure that your organization’s app consent policies are being effectively managed. Limit the apps that users can consent to or disable them altogether. Any previously consented application will still have consent after making changes.
Ensure effective detection of social engineering attacks in the cloud by:
- Using Microsoft 365 Defender portal (if licensed)
- Removing all Oauth consent grants
- Utilizing AzureADPSPermissions.ps1
Web App Attacks
More traditional types of attacks are still possible even in cloud environments. Examples include:
- Insecure File Upload
- Server-Side Template Injection (SSTI)
- Remote Code Execution (RCE)
- Path Traversal
- Server-Side Request Forgery (SSRF)
To identify SSRF attacks in AWS, pen testers look for a feature that makes calls to another server or local resource. In a case recently observed by Kroll, the threat actors were seen attempting to access Metadata API via the following URL, which provided AccessKeyId and SecretAccessKey to the underlying account that the web app utilized. In this instance, an attacker would simply need to utilize the URL in the vulnerable input to obtain this information.
http://169.254.169.254/latest/meta-data/iam/security-credentials/
Metadata APIs
Instance metadata APIs are another vector for threat actors. Metadata APIs allow applications to access information about the running instance. Generally accessible over APIPA (169.254.169.254), their features vary based on the specific provider. They respond to HTTP requests, with the structure of HTTP requests again varying on the basis of the provider.
AWS Metadata API has two versions: IMDSv1 and IMDSv2o, with the latter being more security-focused and session-based instead of role-based. Initial requests should be changed to PUT and additional headers are required. However, it can still be obtained if command execution is possible. The base URL is:
http://169.254.169.254/latest/meta-dataOrganizations should disable IMDS v1 in favor of only using IMDSv2. While IMDSv2 isn’t fool-proof, it offers more security features and makes exploitation more difficult.
In AWS, the base URL is: http://169.254.169.254/latest/meta-data/. The following table shows a sample of accessible metadata endpoints in AWS.
This post was originally published on the 3rd party site mentioned in the title of this this site