“CloudSquatting”: Taking Over Abandoned Cloud Storage Locations

Co-Authors: Godwin Vincent, Kevin Vincent, Shawn Blue, Harinder Jagpal

Summary

We have identified a pervasive issue resulting from websites or applications erroneously referencing abandoned cloud resources. An attacker can easily take over these abandoned resources and potentially steal logins or payment information, modify website content, or even take control of computers. We have dubbed this class of vulnerabilities “CloudSquatting.”

In a short time window, we identified 18 million requests to abandoned resources, affecting over 10,000 applications. Affected entities include e-commerce, healthcare, government websites, browser extensions, mobile applications, and desktop applications. One of the 10,000 applications was the popular app, TikTok. This issue was reported to TikTok and was swiftly fixed.

Vulnerability

Modern applications today pull resources from all types of remote locations. These applications often use public cloud storage services from providers like Amazon Web Services, Google Cloud Platform, and Azure. The naming convention of these object stores relies on just the common name of the storage location like “my-special-storage-location” to register and subsequently reference the object store over the internet.

Over time, these cloud storage locations are deleted for one reason or another. Yet, there may still be applications that attempt to fetch resources out of them. Since there is no scope of ownership of deleted resources, anyone with an account with the cloud provider can register a storage location with the same common name and serve arbitrary content.

Scope

To quantify the scope of this issue, we analyzed web crawler logs over the course of 8 months. We scanned for occurrences where web applications attempted to access a resource from a cloud storage service that did not exist. To do this, we looked for urls that matched common cloud storage patterns that returned the HTTP error code 404 or cloud storage provider specific error codes. These patterns are like:

• https://{bucket-name}.s3.amazonaws.com/{key-name}
• https://storage.googleapis.com/{bucket-name}/{key-name}
• https://{storage-account}.blob.core.windows.net/{container}/{blob}

In the 8 month span, we identified more than 10,000 instances where an application tries to load resources from a nonexistent source. When split between the cloud providers we observed the following:

AWS: 10,026 storage locations

GCP: 1188 storage locations

Azure: 745 storage locations

While a 404 or cloud provider specific error code is an indicator that a storage location may be vulnerable, we wanted to confirm if applications were still trying to access resources from the storage location. We decided to focus on AWS S3 and programmatically registered the 10,026 S3 buckets we had identified. We then enabled access logging on these buckets to monitor if applications were still attempting to pull resources from them, and investigate exactly what resources they were trying to pull. The numbers were staggering:

• 5,214 buckets received some type of request in a single day
• 18,000,000+ requests were made to the buckets in a 24 hr period
• 1,500,000+ of these requests were attempting to pull a JavaScript file
• 52,000+ of these requests were attempting to load an executable file type.

These were the numbers for just the small subset of S3 buckets we were able to identify in web crawler logs collected in an 8-month timespan. We believe the scope of this issue is much larger.

Javascript Requests

As seen above, we received ~1.5 million attempts to load javascript files from cloud storage locations we controlled. In the majority of these cases, minus mitigating controls, we would have had the ability to execute arbitrary javascript on requesting web pages. One such example of this was an e-commerce platform, where by executing arbitrary javascript, we could have exfiltrated user information or simply rewrite the page to phish the user for their credentials or financial information.

Executable Requests

We also received 52,000 attempts to load executable files from cloud storage locations we controlled. These included file types such as .exe, .jar, .bat, .sh, .dmg, etc. In the majority of these cases, minus mitigating controls, we would have had the ability to remotely execute arbitrary code on requesting clients.

Case Study: TikTok Video Takeover

One of the buckets our scanner identified was musically-prod, which received millions of requests over a 24 hour time period. Given metadata in the logs, and the name, Musical.ly, we were able to identify that this bucket was attempting to serve videos, video previews, and profile pictures to TikTok applications.

The yellow highlights show a user’s video and corresponding request to an Akamai CDN endpoint which is then translated into requests to the musically-prod S3 bucket we were able to register, evidenced by the access logs below.

Since we owned this bucket we could have served arbitrary video files back to TikTok users who visited these posts; it would have appeared as if the creator had posted the video themselves. Access logs show that over 600,000 unique TikTok videos or images could have been modified in this way in a 24 hour timespan.

We disclosed the vulnerability to TikTok who confirmed the issue and swiftly implemented a fix.

How can I prevent this from happening to me or my company?

1. Review Access Logs before deprovisioning cloud resources (eg. S3 Access Logging)
2. Alert on 404 errors to cloud storage locations in application logs
3. Use a client side error logging framework to identify requests to non-existent resources
4. When possible, verify the integrity of resources that are being accessed (Eg. For javascript files, use subresource integrity checks)

What can Cloud Providers do?

Given the shared responsibility model for security in utilizing cloud providers, there are future enhancements that cloud providers can take to help mitigate these issues.

1. Inform users about recent access to cloud resources that are being deprovisioned
2. Alert users when requests continue to a deprovisioned resource
3. Establish scopes of ownership for storage objects

Barrage Security is an organization created by four researchers from the University of California, Berkeley, School of Information: Godwin Vincent, Kevin Vincent, Shawn Blue, and Harinder Jagpal. The group is passionate about discovering and evangelizing critical cloud security issues impacting organizations today. Barrage Security originated with a capstone project in the Master of Information and Cybersecurity (MICS) program at UC Berkeley.