What Do You Really Know About The
Security Posture Of Your Digital Ecosystem?
See the risks you’re exposed to with a vulnerability assessment.
Cloudification has been taking over IT in the past decade and has been a huge factor in the explosion of the size of companies’ online 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.
What makes the rush to cloud adoption so impactful on the growth of online ecosystems is its impact is twofold:
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.
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.
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:
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.
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.
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.
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.
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 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.
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.