Unit 42 Cloud Threat Report Update: Cloud Security Weakens as More Organizations Fail to Secure IAM

Executive Summary

Cloud environments are more susceptible to attacks today than they were at the end of last year, according to new research from Unit 42. We identified significant increases in the number of organizations that did not enable multi-factor authentication (MFA), failed to rotate access keys or used overly permissive service accounts in their instances with cloud service providers (CSPs). That puts those organizations at increased risk of experiencing a high-profile security incident caused by compromised identity and access management (IAM) accounts for CSP environments.

These findings supplement our Unit 42 Cloud Threat Report, 2H 2020. In that October 2020 report, we analyzed the security risks IAM misconfigurations can pose to cloud environments. We decided to follow up that research to see how trends have changed over the past eight months, particularly in light of the highly significant MFA ramifications of the SolarStorm attack and the Microsoft Exchange Server attacks.

Between January and June 2021, Unit 42 researchers found that cloud environments are more susceptible to attacks today than in October 2020. Most notably, researchers made additional discoveries, including:

• A 60% increase in the number of organizations that configure Google Cloud storage buckets so they are accessible to all users, putting their data at higher risk.
• A 42% increase in the number of organizations that did not enable MFA settings for root accounts on the Amazon Web Services (AWS) platform.
• A 22% increase in the number of organizations using AWS, where access keys are not rotated for more than 90 days.

These findings (MFA disablement, no routine key rotation operations and the provisioning of over-privileged accounts) indicate the need for organizations to tighten their DevOps security operating procedures.

It is highly recommended that all organizations invest in cloud-native security platforms, such as Palo Alto Networks Prisma Cloud, to routinely monitor cloud environments for IAM misconfigurations both within production and development environments.

MFA Misconfigurations

The findings regarding those who do not enable MFA in cloud environments only pertain to a CSP’s native IAM capabilities and not those provided by a third-party identity provider (IdP). CSP root accounts present a critical security bottleneck in terms of an organization’s cloud IAM security. The CSP root account is the first account created within a cloud environment. It is an all-powerful account holding “the keys to the kingdom,” including allowing and managing any IdP configuration. This is important to point out, as a compromised CSP root account could circumvent any security measure put in place by an IdP.

It is a security best practice to configure the organization’s CSP root account with MFA to safeguard it, which includes the organization’s cloud environment itself. While there are instances where MFA can be bypassed (e.g. phishing attacks, insecure protocols and vulnerabilities), these types of attacks are incredibly costly for attackers. Microsoft found that the “[u]se of anything beyond the password significantly increases the costs for attackers, which is why the rate of compromise for accounts using any type of MFA is less than 0.1% of the general population.” According to IDC, 90% of enterprises will rely upon a cloud infrastructure to meet production requirements by 2022. To help secure that cloud infrastructure, following MFA best practices will help ensure organizations do not suffer avoidable identity security exposures.

MFA, also referred to as two-factor authentication (2FA), is the process of providing two or more forms of authentication before being granted access to an application. The three forms of authentication are:

1. Something you know.
   • Password.
   • Passphrase.
2. Something you have.
   • Hardware security key.
   • Software token application.
   • SMS token.
3. Something you are.
   • Biometric scan or iris scan.
   • Voice authentication.

When MFA is enabled and a user requests access to an application, the user will be required to successfully provide two or more authentication checks before being given access. This typically involves supplying a password (something you know) and entering a token value (something you have).

In the previously mentioned CTR, 2H 2020, Unit 42 researchers examined MFA misconfigurations where organizations had not properly enabled or configured MFA resources for their root and standard user accounts. Unfortunately, these statistics have worsened since October 2020, as shown in Table 1. An explanation for the downward trend in these numbers could be that it is due to organizations failing to properly configure user accounts, which may lie outside of their IdP platform. This means, for organizations that are using an IdP (e.g. Okta, Auth0, SailPoint or OneLogin), they may not have disabled those IAM accounts created within the cloud platform itself. This would include the IAM account that was used to establish the IdP integration.

^{Table 1. Organizations not enabling MFA for IAM accounts.
*RAM – Resource Access Management is the identity and access control service within the Alibaba cloud that enables users’ central management and their permissions.}

Whereas Amazon Web Services (AWS), Oracle Cloud and Alibaba Cloud have incorporated the IAM authentication functionality within the cloud platform itself, Google Cloud and Microsoft Azure use their proprietary IdP services with their cloud platforms to perform IAM authentication. Google Cloud uses the proprietary Google Accounts service, and Azure uses Microsoft’s Azure Active Directory (AD) service. If organization administrators wish to enable MFA for their Google Cloud accounts, please refer to this Google Workspace guide. If organization administrators want to enable MFA for their Azure cloud accounts, please refer to this Azure AD Multi-Factor Authentication guide

Additional Misconfigurations

Diving into the IAM access key rotation findings, Unit 42 researchers found a roughly 20% global increase in cloud organizations failing to perform access key rotation operations between October 2020 and June 2021. This was found within organizations using Google Cloud and AWS platforms.

Much like passwords, new CSP access keys should be rotated every 90 days to ensure that they will not remain active for long periods if the keys are leaked or stolen. Access keys become compromised if they are accidentally uploaded to code repository sites such as GitLab or GitHub or placed on a cloud instance that later becomes compromised. As can be seen within Table 2, organizations using AWS, Google Cloud and Oracle Cloud platforms exhibited notable occurrences of long-lived access keys. (Each of the cloud providers offer access to configuration settings to protect the cloud infrastructure from this issue, though not all users enable them.)

Due to the increase in cloud demand and complexity paired with the overall low severity rating of long-lived credentials, it is likely that organizations are choosing to address other cloud development operations, such as on-prem to cloud migrations or application development, rather than addressing long-lived credential misconfigurations. However, access key rotation is one of the few use cases that presents an ever-increasing risk severity. The longer credentials remain unchanged and the more cloud infrastructures being built that use those credentials, the more damaging their exposure could be to the organization should those credentials become leaked.

^{Table 2. Organizations not rotating access keys.}

Each of the primary CSPs offers methodologies for automating the process of access key rotation. Please see the following links for more details: Alibaba Cloud, AWS, Azure, Google Cloud and Oracle Cloud.

Excessive Permissions

Finally, Unit 42 researchers revisited the likelihood of organizations with excessive permissions, which allowed for IAM accounts and roles. The most notable IAM excessive privilege issue centers around the misuse of the AWS AssumeRole functionality. (While AWS provides configurations to protect against AssumeRole misuse, not all users enable them.) This service has received a great deal of attention from both Unit 42 researchers and CSO Online industry best practice articles, and even SolarWinds has a tie into misconfigured AssumeRole services. Due to this level of attention, researchers are beginning to see a decrease in the number of organizations that are overly privileging AssumeRole configurations, which has decreased by 67% in just six months (see Table 3).

^{Table 3. Organizations allowing overly permissive IAM privileges.}

While the reduction in over-privileged AWS AssumeRole services is good news, we believe it is time to switch our collective attention to correcting other IAM security concerns within other CSP environments. For example, this includes overly permissive IAM service accounts within Google Cloud environments, which have increased in frequency by 17%, as well as locking down publicly accessible Google Cloud storage resources, which have increased in frequency by a massive 60% over the last six months.

Conclusion

CSP root accounts pose a critical security risk to cloud environments. Providing proper security protection for these accounts should be an urgent priority for any organization operating in the cloud. Organizations improperly configuring and maintaining their cloud environments could experience grave consequences. Unit 42 researchers strongly recommend that organizations limit operational functionality from CSP root accounts to only configuring an IdP platform. The CSP root account should have MFA enabled, preferably via an MFA hard token, and that root account should never be used, except for emergencies. Any and all administrative functions must be performed through a newly designated IdP-based administrative account.

Unit 42 researchers also found an increase in the number of organizations not rotating their IAM access keys and the number of organizations deploying overly privileged IAM accounts and roles. Similar to rotating user passwords, access keys must be rotated at least every 90 days to maintain minimal risk. Finally, the principle of least-privilege should be applied when creating and maintaining all IAM entities, be they users, roles or group privileges. The critical IAM misconfigurations discussed can be detected and alerted on, out of the box, within Prisma Cloud. The platform allows organizations to maintain awareness of their cloud environment configurations, especially for those organizations using a multi-cloud setup.

Recommendations

• Ensure that the CSP root account has MFA enabled, preferably with a hardware token.
• Use the CSP’s root account to set up the IdP configuration and never use that root account for any other function.
• Create an IAM administrative account configured through the IdP to perform all administrative functions.
• Monitor IAM Roles, groups and trust policies through Prisma Cloud’s IAM Module.
• Establish an automated Access Key Rotation function for all IAM users and service accounts.
• Employ the principle of least-privilege when building IAM permissions.

Source: https://unit42.paloaltonetworks.com/iam-misconfigurations/?web_view=true