We’re in the age of cloud computing where resources like virtual servers and storage space are often provisioned programmatically through deployment scripts as needed. While spinning up such assets is an almost instant process, removing them when they’re no longer needed is not as straightforward. Simply deleting cloud assets without making sure you have deleted all your organization’s records that might point to them, whether in your domain’s DNS zone or in your codebase, can open serious security holes for attackers to exploit.
Imagine the following scenario: You want to run a special holiday campaign for your customers, and you decide to create a microsite for it to host all the promotional materials, the sign-up forms, and so on. Your developers get to work, they design the site, and they provision a new virtual server on AWS — or any cloud computing service — to host it along with a storage bucket to store the site’s data.
The cloud service provider will allocate a publicly reachable IP address to your EC2 instance from its pool of reusable IP addresses and will assign a hostname for your storage bucket under their domain — bucket-name.s3.region-code.amazonaws.com — so you can access it through the API.
Users need to reach your site and search engine, and robots need to index it, so the next step is to create a subdomain for it on your main domain name and point it to the IP address so the web server can be reachable from your subdomain. Then you create a subdomain for the S3 bucket and a DNS CNAME record to point it to the bucket’s AWS hostname. Let’s say you also have a mobile application that sends data to this campaign website, so the hostnames also make it into the application’s code. You have other internal apps and tools that need to integrate with the site for reasons like statistics tracking or database backup.
What you’ve now created are a multitude of records in different locations that point to what are essentially temporary cloud resources. If you ever delete those cloud assets because they’ve served their purpose, but you fail to also delete the records your developers and infrastructure engineers created for them, you’ve generated a lot of risk.
Attackers can use your subdomains for phishing sites, malware delivery
An attacker can obtain the same IP address from Amazon because it’s now free and they have your subdomain pointing to it so they can create a phishing site or a malware serving site. They can register an S3 bucket with the same name because they found a reference in your app’s code and now your app is sending sensitive data to a storage bucket they own.
This is the scenario that TikTok security engineer Abdullah Al-Sultani presented at the DefCamp security conference in Bucharest recently. He referred to the attack as “cloud squatting.” It goes beyond just DNS records as the type and number of cloud services that do resource and name reallocation once an account is closed is very broad. The bigger the company, the bigger this shadow cloud records issue is.
Identifying cloud squatting risk harder for large enterprises
Al-Sultani came across cloud squatting after TikTok received reports through its bug bounty program that involved the reporters taking over TikTok subdomains. His team quickly realized that trying to find all stale records was going to be a serious undertaking because TikTok’s parent company ByteDance has over 100,000 employees and development and infrastructure teams in many countries around the world. It also has thousands of domains for its different apps in different regions.
To tackle this issue, the TikTok security team built an internal tool that iterated through all the company’s domains, automatically tested all CNAME records by sending HTTP or DNS requests to the; identified all domains and subdomains that pointed to IP ranges belonging to cloud providers like AWS, Azure, Google Cloud, and other third-party services providers; and then checked if those IP records were still valid and were assigned to TikTok. Luckily the company was already tracking IP addresses assigned to its assets by cloud providers inside an internal database, but many companies might not do this type of tracking.
Al-Sultani is not the first to highlight the dangers of cloud squatting. Last year, a team of researchers from Pennsylvania State University analyzed the risk of IP reuse on public clouds by deploying 3 million EC2 servers in Amazon’s US East region that received 1.5 million unique IP addresses or around 56% of the available pool for the region. Among the traffic coming into those IP addresses the researchers found financial transactions, GPS location data, and personally identifiable information.
“We identified four classes of cloud services, seven classes of third-party services, and DNS as sources of exploitable latent configurations,” the researchers said in their research paper. “We discovered that exploitable configurations were both common and in many cases extremely dangerous […] Within the seven classes of third-party services, we identified dozens of exploitable software systems spanning hundreds of servers (e.g., databases, caches, mobile applications, and web services). Lastly, we identified 5,446 exploitable domains spanning 231 eTLDs-including 105 in the top 10,000 and 23 in the top 1,000 popular domains.”
Cloud sqatting risks inherited from third-party software
The risk from cloud squatting issues can even be inherited from third-party software components. In June, researchers from Checkmarx warned that attackers are scanning npm packages for references to S3 buckets. If they find a bucket that no longer exists, they register it. In many cases the developers of those packages chose to use an S3 bucket to store pre-compiled binary files that are downloaded and executed during the package’s installation. So, if attackers re-register the abandoned buckets, they can perform remote code execution on the systems of the users trusting the affected npm package because they can host their own malicious binaries.
In a similar example, earlier this year researchers from Aqua Security showed that GitHub repositories that have been deleted or renamed can be re-registered by attackers. If applications or documentation still point to them, they can be used to serve malware. The researchers called this attack RepoJacking.
Mitigating cloud squatting risk
The attack surface is very large, but organizations need to start somewhere and the sooner the better. The IP reuse and DNS scenario seems to be the most widespread and can be mitigated in several ways: by using reserved IP addresses from a cloud provider which means they won’t be released back into the shared pool until the organization explicitly releases them, by transferring their own IP addresses to the cloud, by using private (internal) IP addresses between services when users don’t need to directly access those servers, or by using IPv6 addresses if offered by the cloud provider because their number is so large that they’re unlikely to ever be reused.
Organizations should also enforce a policy that prevents the hardcoding of IP addresses inside applications and instead should use DNS names for all their services. They should regularly maintain these records and delete stale ones, but having everything addressable through DNS provides a central place of management rather than chasing down hard-coded IP addresses.