Threats and Vulnerabilities Hiding in the Cloud

Cloudification has been taking over IT in the past decade and has been a huge factor in the explosion of the size of companies’ external attack surface and the types of risks that exist within them.

Cloud instances have a unique set of risks and potential vulnerabilities. Due to cloud adoption, cloud instances are prevalent throughout the external attack surfaces of nearly every organization that has an online presence. In this post I’ll drill down into some of the specific vulnerabilities that we frequently see.

The Rush to the Cloud is Expanding the Attack Surface

Cloud adoption is so impactful on the growth of the attack surface that its impact is two-fold:

Increasing the overall number of company assets

The use of cloud services promotes distributed, service-oriented architectures with separate resources dedicated to delivering distinct microservices. This means that e.g., instead of having a single website to serve all the contents required to render a webpage, companies that are in the cloud will have likely adopted some form of microservices architectures and thus would likely have separate domains (www.x.y, scripts.x.y, fonts.x.y, images.x.y) to point to various microservices. Such architectures add to the overall number of assets companies will have in their online inventory.

Expanding attack surface-generated “connections”

Cloud providers are, by definition, third parties to their customers and “connections”, in the form of DNS records. As such, providers are required to map company domains to the cloud resources that deliver the corresponding service. For a minority of cloud services, this will be a matter of renting a public IP address from the cloud provider, statically associating it with the resource, and setting a DNS A record to that public IP address. In the case of most cloud PaaS services, the service instance will have only a fixed native domain (e.g., mycompany.s3.eastus.amazonaws.com) and then the company will have to add a DNS CNAME record to map the required domain (e.g., files.mycompany.com) to the native domain name of that resource.

The Risks of Cloud Adoption

From a risk perspective there are three dimensions to the way massive cloud adoption has reshaped and arguably increased the risk level in companies’ external attack surface:

1. In the case of most cloud services (specifically all the services that do not live inside a VPC/vNET), the only mechanisms for enforcing access controls are some built-in, service-specific access control mechanisms offered by the cloud provider and, more often than not, configured by the application team rather than the security team. This increases the likelihood of cloud security misconfigurations leading to exposed resources.
2. The management and control planes for the cloud are accessible from the internet and thus form an attack surface all on their own. They may also have access control misconfigurations.
3. The dynamic nature of the cloud is making resources deployed there more fungible and transitory. This makes connections–HTML tags referencing a domain, HTTP redirects, DNS records, or any other—that point to cloud resources more likely to get broken over time.

To make these points more concrete we’ll use AWS S3, the single most widely-used cloud service, as an example. But note that similar considerations apply to practically all cloud services, across all cloud providers.

S3 Buckets are Always Outside the Traditional Perimeter

AWS S3 buckets don’t live inside a VPC and so there’s no way to put a firewall or an IPS in front of an S3 bucket. Instead of such traditional perimeter access controls, Amazon offers at least three distinct  access control mechanisms that are built right into S3. Each allows a somewhat different set of selectors to be used in expressing access rules to S3 buckets. The complexity of the resulting security model, and the fact that application teams, rather than security teams, configure the buckets and their access controls to their liking, make it the case that all too often, buckets are found to allow anonymous “write” operations on buckets: Anonymous users can often upload and change files in S3.

The APIs for Managing S3 ACLs Might Allow Anonymous Access

On the management plane of S3 buckets, there are APIs (and SDKs/CLIs built on top of them) for the configuration of these buckets. Some such S3 APIs can be configured (or likely, misconfigured) to allow anonymous access, including the API to manage S3 ACLs themselves. When that happens, it allows attackers to stealthily grant themselves permissions.

Like practically all cloud resources, S3 buckets can be deleted with the proverbial click of a button. A bucket will be created for a specific purpose and when it stops making sense to pay for it, it will simply be remove. But often this is done without sufficient efforts to ensure that there are no links or other connections that remain pointing to that bucket. Such connections, once our bucket is removed, will become broken, or dangling. Because removing cloud resources is so easy, and because it happens so often, connections that point to cloud resources are more likely to get broken over time.

Importantly, dangling connections to cloud resources, no matter the provider, are often particularly easy to exploit. To understand why, consider this. The native FQDN of a bucket has the form <Bucket Name>.s3.<Bucket Region>.amazonaws.com. To say that there’s a broken connection to that bucket is to say that there are still connections (HTML tags, HTTP redirects, DNS records, etc) or chains of such connections, that ultimately point to that FQDN. Now when an organization deletes a bucket, that bucket’s name becomes immediately available for anyone to use. If there are connections still using that FQDN (again, directly or indirectly), a new owner of the name – which anybody can leverage – can set up their bucket to serve any requests that are based on those connections. We’ve seen multiple cases of these occurrences, and the possibilities for capitalizing on these exploits are unlimited. Depending on the types of connections that point to a taken-over bucket name, an attacker can now serve illicit content while hiding behind their victim’s domain name. Or they can impersonate their victim’s site to harvest user credentials and data.

Rentable Resources Create a Management Nightmare

At the core of this class of potential vulnerabilities lies what makes the cloud so very attractive to begin with—the ability to quickly “rent” a resource with a unique IP address or FQDN, and then just release that resource when it’s no longer needed. But in this hyperconnected world, it’s likely that when a resource is released, broken connections are left dangling. It’s exactly the nature of the cloud that allows these dangling connections to be easily weaponized and exploited.

Finally, in all three of the cloud attack vectors mentioned, once the attacker controls the content of the bucket, many other exploits are possible:  If the bucket was used to serve scripts, an attacker can serve their own script, thereby creating persistent XSS or Magecart attacks. But also more “lowly” inclusions like CSS, image, font or even hyperlinks that point to resources in the bucket can be used to both change the behavior of the sites and/or infect the endpoint making the requests with malware.

How Cyberpion’s Platform Can Help

The Cyberpion platform delivers deep security monitoring for cloud resources, including assessments of their access controls in both the data and control/management layers.

The Cyberpion platform is also quite unique in its focus on monitoring connections and assessing their inherent risks. In the case of the most critical vulnerabilities, the platform goes one step further and provides automatic active threat protection against their exploitation. To get an understanding of any risks and vulnerabilities of your cloud instances, contact us to get your free, non-intrusive external attack surface discovery.