Cloud Squatting: The Risk of IP Reuse on Public Clouds

Our recent work demonstrates a broad class of attacks against services deployed to public clouds. These attacks, which we refer to as cloud squatting, allow bad actors to receive sensitive user, financial, and medical data when cloud services are not managed properly.

What is cloud squatting?

When organizations rent servers from the cloud, these servers are given an IP address. Customers connect to the IP address and send information. When the organization is done with the server, the IP address is then given to another cloud tenant.

The problem arises when organizations leave references to this IP address even after they no longer control the associated server. This can happen for many reasons:

• The IP address is still stored in DNS records for the organization.
• Other servers or cloud services have saved the IP address and continue to connect to it.
• End-user devices still connect to the IP address. For instance, a mobile application may have the address hard-coded into the app itself.

When a new organization is given the IP address, they will receive network traffic from end users believing they are talking to the original service. While this traffic is usually ignored by the new organization, an attacker can purposefully record this traffic and extract sensitive user data.

How prevalent is cloud squatting?

Our study of a small fraction of IP addresses on Amazon Web Services showed over 5,400 organizations potentially affected, including 23 of the top-1000 websites. Because of how our study was structured, the actual number of affected organizations is likely far higher.

What sorts of data were being leaked?

We found many instances of sensitive data being leaked to IP addresses intended for previous organizations. These are best highlighted by example:

• Mobile devices were sending analytics and tracking data intended for other organizations. These organizations no longer ran services to collect the data, but devices were still configured to send it.
• A financial services organization sent transaction data between their various cloud services, including to addresses they no longer controlled.
• Domain names for government websites pointed to IP addresses they no longer controlled. An attacker could pose as a government agency by controlling these addresses.

The types of data sent can be as diverse as services run on public clouds. Because end-user devices believe they are talking to the original service, any data intended for that service can be sent to attackers.

Is there any evidence that attackers have used this attack to steal user data?

Our study focused on characterizing the vulnerability. Cloud customers are certainly receiving traffic and sensitive user data intended for other organizations, and may even be unintentionally storing or processing it. Whether attackers are collecting and exploiting this is an open question.

Why don’t existing defenses protect against this?

When an attacker performs a cloud squatting attack, end users send data directly to them believing they are talking to some other organization. Because of this, sensitive data never even reaches the intended recipient, preventing auditing tools from detecting the issue.

Some organizations currently look for subdomain takeover attacks by scanning their DNS records for issues. Our work demonstrates that cloud squatting can be performed independently of DNS, so this scanning alone does not fully protect organizations.

What can organizations do to protect themselves and their customers?

Cloud providers are updating best practices to ensure users manage their cloud services securely. The most important step organizations can take is to ensure that all cloud services within the organization follow these best practices. IT departments should have centralized oversight of cloud accounts within the organization to help ensure this.

Cloud squatting occurs when IP addresses are reused but references to those addresses linger. Preventing either of these makes cloud squatting impossible.

Preventing IP address reuse

• Reserved IP Addresses: Cloud providers allow tenants to reserve IP addresses, which stay within the organization until they are explicitly released. Ensuring that all public IPs within the organization are reserved will prevent them from being automatically given to other organizations.
• Bring Your Own IP: Organizations can transfer their own IP addresses for use within the cloud. These addresses will similarly stay within the organization.
• Private IP Addresses: When cloud services do not need to receive traffic from end users, they could use private IP addresses. These addresses are only used within an organization and therefore are never shared with others.
• IPv6: Cloud squatting results from the scarcity of legacy (IPv4) addresses. Some cloud providers offer IPv6 addresses, which are so plentiful that such addresses never need to be reused.

Preventing lingering references

• Leveraging DNS: Organizations should make sure they never directly reference IP addresses, and instead refer to their servers through DNS. Having only one place where IP references are stored simplifies configuration management
• Securing DNS: Most cloud providers offer alias records, which automatically map domain names to the IP address of a service. Alias records are automatically cleaned up when the organization removes a service, preventing lingering references to IP addresses.

How are cloud providers responding to this vulnerability?

Upon discovering cloud squatting, we immediately notified Amazon and other major cloud providers. These providers are taking steps to alert customers of vulnerabilities and develop new best practices to protect end users. We recommend reaching out to individual providers for further details.

How can users protect themselves?

Users should limit the amount of personal data they share with companies and how many companies they share it with. They should also be suspicious of strange-looking sites requesting sensitive data, even if those sites are hosted under the correct domain name.

This material is based upon work supported by the National Science Foundation Graduate Research Fellowship Program under Grant No. DGE1255832, and in part by the NSF grant: CNS-1900873. Any opinions, findings, and conclusions or recommendations expressed in this material are those of the authors and do not necessarily reflect the views of the National Science Foundation.