Cloudification has been taking over IT in the past decade and has been a huge factor in the explosion of the size of companies’ ecosystems 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 online ecosystems 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 Driving Larger Online Ecosystems
What makes the rush to cloud adoption so impactful on the growth of online ecosystems is its impact is twofold:
Indirectly Growing Online Ecosystems: Adding to 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.
Directly Growing Online Ecosystems: Adding Ecosystem-Generating “Connections”
The cloud providers are, by definition, third-parties to their customers and “connections”, in the form of DNS records, 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, but 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’ ecosystems:
- 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 makes it more likely in the cloud than elsewhere, to find security misconfigurations leading to exposed resources.
- The management and control planes for the cloud are accessible from the internet and thus form an attack surface all on their own. They too may have access control misconfigurations.
- 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, perhaps 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 frequently it’s the application teams, focused as they are on “making things work”, rather than security teams, who configure the buckets and their access controls, 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 build 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.
Connections to S3 Buckets are Likely to “Break” Over Time
Like practically all cloud resources, S3 buckets can be deleted with the proverbial click of a button. A company will create a bucket for a purpose and when it stops making sense to pay for it, it will simply remove it. 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.
But, importantly, dangling connections to cloud resources, S3 buckets (and most others!!! ), are often particularly easy to exploit. To see why consider this: the native FQDN of a bucket has the form <Bucket Name>.s3.<Bucket Region>.amazoaws.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, and so, if there are connections still using that FQDN (again, directly or indirectly), a new owner of the name – which anybody can become – 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 and 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, and it’s exactly the nature of the cloud that allows these to dangling connections to be easily weaponized and exploited.
Finally, in all three of the 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.
Cyberpion Ecosystem Security Platform
The Cyberpion platform delivers deep security monitoring for cloud resources in our customers’ ecosystems, including assessments of their access controls in both the data and control/management layer.
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 protections against their exploitation. To get an understanding of the number, risks, and vulnerabilities of the cloud instances within your own online ecosystem contact us to get your free, non-intrusive ecosystem scan.