The Top 3 Most Common Cloud Attacks and How to Avoid Them

The advantages of the cloud are clear, which is why so many enterprises are leveraging platforms like Amazon Web Services (AWS), Microsoft Azure, and Google Cloud Platform (GCP) to facilitate web applications. Benefits like scalability, storage, and operational efficiencies drive organizations to move more applications and workflows to the cloud. But what organizations may not realize is that just because they’re offloading critical infrastructure into the cloud, they can’t offload security concerns.

There’s a common assumption that cloud providers deliver sufficient visibility and monitoring of the cloud environment – but this is often not the case. Because they’re unaware of this gap in protection, security teams might fail to configure critical controls and secure architecture practices, leaving the businesses vulnerable to attacks.

In addition to carefully configuring and maintaining controls, security teams should also be aware of the most common attack classes that threat actors use against the top three cloud service providers: AWS, Azure, and GCP. While the individual methods and tactics used to attack each individual service may differ because of implementation or design differences, each one generally suffers from the same classes of attacks, which are detailed here.

• Misconfigured Storage Buckets

Many web applications use storage buckets from cloud service providers to host content. Many websites rely on using storage buckets to service static content, then use a combination of a functional interface (such as JavaScript) in conjunction with a serverless computing platform (for example, AWS Lambda, Google Cloud Functions, or Microsoft Azure Functions) to provide a more interactive and dynamic experience for the end user.

In other cases, storage buckets may be used to host large data sets, such as web application logs (e.g., transaction information for an e-commerce service), or even as an internal file host for more sensitive files like SSH access and/or API keys. Cloud service providers do offer mechanisms to secure storage buckets. However, in some cases the bucket policies may be misconfigured, or open policies may be necessary to facilitate the design of the application. A quick Internet search of the term “insecure bucket data leak” will show many documented cases where an insecure storage bucket led to a myriad of data breaches with moderate to severe impact.

There are also a number of publicly published attack tools such as cloudhunter or gcpbucketbrute, as well as blogs centered around exploiting this concept. Most of these tools generally rely on the fact that storage buckets are easily enumerated and often have unintentionally lax access policies.

Even if appropriate permissions are set on your storage buckets, you should check the contents of the bucket for any sensitive information. GCP, for example, provides the Cloud Data Loss Prevention API that allows identification of sensitive data such as credit card numbers, phone numbers, and other information in storage buckets.

• Metadata Service Exploitation Through SSRF

Each of the top cloud service providers provides a metadata service for instances running in their environments, generally accessible via HTTP at the link-local address 169.254.169.254. The metadata service allows a user to query and manage an instance programmatically, and generally, an instance has access to its metadata API without additional authorization.

This feature is extremely useful for organizations operating a cloud environment at scale, simplifying administration of cloud instances. However, in the same way an administrator can make use of the metadata service to manage an instance, attackers also look for chances to interact with the metadata service, hoping to find a misconfiguration and use it to further accomplish their desired objectives.

A web application hosted on a cloud instance may have to accept input from a user, and a vulnerability in the web application’s logic may allow for a class of vulnerability called server-side request forgery (SSRF). SSRF exploitation allows attackers to force the server to submit a web request on their behalf. By exploiting an SSRF vulnerability, an attacker can force an instance to interact with its metadata service, potentially leading to further compromise.

As an example, in 2019 CapitalOne experienced a data breach where the attacker leveraged a SSRF vulnerability to force a cloud instance to query its metadata service, retrieve its account credentials, and use those credentials to retrieve about 100 million consumer applications for credit. In other cases, storage buckets may be used to host large data sets, such as web application logs (like transaction information for an e-commerce service), or even as an internal file host for more sensitive files such as SSH access keys.

Most cloud providers provide protections to help prevent this class of attack. For example, both Azure and GCP check for a metadata header in metadata http requests and reject any request without the header.

Amazon AWS introduced a new version of its instance metadata service that adds new protections to help mitigate this vulnerability, protecting every request with session authentication, and making metadata requests use the HTTP PUT method. However, legacy instances may not be using this version of the metadata service.

To audit instances for SSRF vulnerabilities, consider blocking metadata access for cases where it’s not being used, and audit instances of account permissions too mitigate lateral movement opportunities. Gitlab’s blog on privilege escalation in GCP provides a great reference on how an overly permissive service account attached to an instance can be leveraged via SSRF exploitation to interact with an instance’s metadata service, resulting in total compromise of the environment.

• Credential Leakage and Overly Permissive Access

Another common reason for data breaches in cloud environments is overly permissive access policies. Between publicly accessible storage buckets that were intended to be private, or over-permissioned IAM (identity and access management) accounts, proper application of access policies within your cloud environment can significantly reduce risk exposure.

In fact, these risks are not exclusive to cloud environments, and inadvertent credential leakage can also result in compromise. In some cases, access keys to cloud environments are unintentionally published with applications, or committed to the public eye in code repositories and even forum posts. Attackers scour the Internet looking for leaked credentials and have many tools available to help facilitate this, such as trufflehog. In cases where these leaked credentials are over-permissioned, this can result in compromise.

Ensure that your organization is following the principles of least-privilege, giving accounts as little access as possible to accomplish their roles. The major cloud service providers offer some form of IAM to allow for very granular control of access policies.

Your organization should also be monitoring all activity from service accounts. Most cloud service providers offer a method to monitor for this activity: AWS provides GuardDuty, GCP has Event Threat Detection part of Security Command Center, and Azure aggregated Advanced Threat Protection into the Microsoft Defenderoffering. Get the most out of cloud services by configuring these solutions to monitor for suspicious activity and quickly take action, even if credentials are leaked.

To learn more about common cloud attacks and to view sample rules and queries to help find unauthorized usage or access to cloud resources, download the ReliaQuest guide, The Tactical Guide to Securing Data on Cloud Platforms in 2021.

Joe Partlow is the CTO of ReliaQuest, a leading Information Security services provider. Joe currently oversees all new research and development efforts and new product initiatives. Joe has been involved with Infosec in some capacity or role for over 20 years, mostly on the defensive side but always impressed by offensive tactics. Current projects and interests include data analytics at scale, forensics, threat, security metrics & automation, red/purple teaming and artificial intelligence. Outside of Information Security, Joe has led or been involved in many other areas of the business including Web Development, Business Intelligence, Database Administration, Project Management, IT and Operations. Joe has experience in many different business verticals including retail, healthcare, financial, state/local government and the Department of Defense. He is also a regular speaker and contributor at security conferences, groups and associations. Joe has a degree in Computer Information Systems and holds many industry-specific certifications.