Securing Cloud Services against Squatting Attacks

Cloud Squatting poses a new threat to services deployed on public clouds. While providers are taking steps to protect their customers, it is also important that businesses and IT organizations follow new best practices to secure their infrastructure. This post covers cloud squatting from an IT practitioner’s perspective. Cloud squatting results from IP address reuse and latent (residual) configuration. By preventing either of these, IT orgs can mitigate the risk of cloud squatting. We’ll begin by exploring why cloud squatting occurs, then discuss the steps IT orgs can take to protect their infrastructure.

Click Here for more general info on our Cloud Squatting research.

Cloud Squatting: A summary

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 no longer needs the server and releases it back to the cloud provider (for instance, when scaling down from loads or decommissioning an old service) the IP address is then given to another cloud tenant.

The problem arises when organizations leave configuration that references 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 configuration no longer serves its intended use, we refer to that configuration as latent. Latent configurations are diverse, and could be as simple as a sticky note on an employee monitor with an IP address. In any case, the references to previously-controlled IP addresses cause users or devices to trust the address. They may connect to it and send sensitive data, or Certificate Authorities (CAs) may issue TLS (HTTPS) certificates using the address.

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. Cloud IP addresses receive a massive amount of background traffic on a daily basis, so the traffic caused by this has historically never been noticed. However, our research shows that an attacker can specifically create cloud servers with the intent to look for this traffic. Upon identifying it, they can determine the associated company, and extract sensitive data from the traffic.

Why should organizations care?

Vulnerabilities against computer systems are routinely demonstrated by security researchers, and it can be easy to assume that the vulnerabilities are not an issue in practice, or that the potential for exploitation is remote. In this case, however, the vulnerability is readily exploitable, can and has leaked highly sensitive data from organizations, and can bypass existing perimeter defenses that organizations may employ.

Cloud squatting is an attack of opportunity, meaning that an adversary does not need to target your organization specifically to receive sensitive data. Instead, they can lease cloud resources and collect all the data they receive, then identify vulnerable organizations and leaked information. Small companies might assume they would not be targets of an attack, but in this case attackers can target all organizations simultaneously. It’s important that organizations of all sizes and technical sophistication take steps to ensure their cloud services are protected.

Because cloud squatters pose as legitimate services by an organization, the information they receive can be as sensitive as any the organization processes. For instance, we received real-time location data, personally identifiable information (virtually anything on a driver’s license or government document), and even web tracking data and browsing history. Even if an organization does not purposefully request sensitive data from end users, an attacker posing as them could cause harm by stealing login credentials, among other data.

Existing monitoring tools may not detect cloud squatting, and attackers who pretend to be an organization receive sensitive data directly from customers. This means that existing organizational controls to prevent data theft (for instance, an Intrusion Detection System) cannot analyze the attack traffic to identify issues. Organizations need to take additional steps that directly address cloud squatting.

Root Causes

Cloud squatting occurs when latent (residual) configuration refers to IP addresses that the cloud provider reuses. One example of such an issue is a subdomain takeover, a well-known issue in computer security. In a subdomain takeover, an attacker controls a domain name belonging to the organization by controlling the underlying resource, either an IP address or a virtual host the organization previously had. While subdomain takeovers are just one instance of the broader cloud squatting problem, it can demonstrate the issues at play that put data at risk.

Fundamentally, a DNS record accomplishes two things: (1) it tells clients where to connect to access some service, and (2) it establishes trust with that service, so clients are willing to send sensitive data or trust the information they receive. Other cloud squatting vulnerabilities function the same way; a resource (usually an IP address) is reused, and configuration causes clients to connect to and trust the resource. For instance, cloud service configuration can cause other cloud services (Amazon SNS, for instance), to continue connecting to the IP address and sending sensitive data. If a mobile application has the IP address hard coded, the app will continue connecting until an update is released that removes the configuration.

Examples of exploitable latent configuration

Cloud squatting can occur across a variety of services and configurations. Here we outline a few examples to show the extent and potential severity of these issues. Because each organization’s cloud deployment is different, these should be seen as a starting point towards auditing potential security issues, rather than an exhaustive list.

DNS

The most easily recognizable issues we found were with DNS. Over 5,400 domains were found vulnerable. In one case, for instance, we found a subdomain of a major financial services company was mapped to an IP address that we controlled. Customers are trained to check the domain names they are connecting to before providing sensitive financial information. In this case, however, an attacker controlling this address could easily pose as the legitimate company. Even worse, cookies or password fillers could automatically share sensitive information with this subdomain without user interaction.

Cloud Services

We found data being shared by four different cloud services on AWS: SNS, Route53, Cloudfront, and API Gateway. By far the most sensitive information was shared by Amazon SNS configurations. In this case, IP addresses can be subscribed to message channels in SNS, and SNS will continue to send messages to the IP even after the tenant no longer controls it. As a result, cloud IP addresses can receive sensitive information. We recommend IT organizations audit their cloud services, especially Amazon SNS and similar products on other providers, to ensure sensitive information is not being leaked. These configurations are not automatically removed by cloud providers. Further, these old subscriptions can continue to accumulate large bills for cloud tenants even though they serve no purpose.

Because cloud services are intended to communicate information within an organization, the data leaked as a result of these issues can be–and in our study was–highly sensitive. In one case, for instance, cloud messaging was used to share real-time location data and personal information (virtually anything found on a driver’s license) about employees and customers of a social services organization. As a result of misconfigured cloud services, an attacker could receive this information with virtually no effort. They could then determine clients of that organization and blackmail them or steal their identities using the collected information. The routes for abuse of this data leakage are obvious and severe. What’s worse, attackers would have a clear incentive to collect this private data, as it could be used to gain value at the expense of victims.

Third-party services

While DNS and cloud services are standardized offerings and therefore easy to analyze, it’s much harder to make sense of the diverse other traffic cloud servers receive. In this other traffic, we identified that a large amount was caused by clients trying to connect to IPs controlled by previous tenants. For instance, mobile applications often host one-off analytics endpoints on the cloud. When a provider no longer hosts a service at that address, attackers can get the address from the cloud provider and receive this traffic. Much of the traffic we observed used no encryption, and contained sensitive end-user information. Leaking ad tracking data in this way could violate business responsibilities under legislation such as GDPR.

Preventing Cloud Squatting

With the root causes of cloud squatting in mind, IT practitioners can take steps to protect their resources against attack. These can take the form of preventing IP addresses from being reused, or by preventing latent configuration from misrouting traffic or causing clients to trust services hosted by attackers. Cloud squatting results from a chain of failures in configuration management, so successfully preventing any of these means cloud squatting is no longer possible.

Many of the techniques discussed below have varying names between cloud providers. You can find documentation to each cloud provider’s offering below.

Preventing IP Reuse

Cloud squatting results when a public IP address is reused. To prevent this, cloud tenants should take steps to ensure the IPs they use to communicate will not be quickly controlled by other tenants.

One way to achieve this is by using private IP addresses. All major cloud providers support private networking within regions. When communication is done between instances within the cloud provider, these private addresses should be used for all communication (this also has other benefits for security). Because these private addresses are scoped to the tenant, it is impossible for traffic routed via these addresses to be sent to another tenant. Some cloud providers offer compliance rules that automatically enforce private networking, such as AWS.

Organizations may be used to a data center model, where a block of IP addresses is used to allocate resources and those IPs are only ever used within the organization. When performing a lift-and-shift¹ of data center resources to the cloud, this assumption can break down to the detriment of security. However, cloud providers offer the ability to bring these IP blocks to the cloud. These Bring-Your-Own-IP (BYOIP) blocks can then be used to provision IPs as one would classically do. After decommissioning, the addresses will likewise never be used outside the tenant.

IP address reuse in public clouds is a direct result of the scarcity of IPv4 addresses. If possible, using IPv6 addresses will usually prevent addresses from being reused, also preventing cloud squatting. For instance, communication within the organization between different cloud regions could be done over public IPv6 addresses. For client-facing services, however, a public IPv4 address will likely still be necessary for compatibility (as only a minority of global users support IPv6).

Preventing Latent Configuration

The types of configuration referring to IP addresses can be highly diverse, from a DNS record to a sticky note on an employee’s monitor. In each case, configuration causes clients to connect to IP addresses, and to trust that the IP is controlled by the party they are expecting. To prevent cloud squatting, we need to ensure that these configurations are managed and removed when they are no longer needed. It is also important to have centralized oversight of this process to ensure nothing is missed.

With this in mind, management of configuration is key. Any time a client decides what IP address to connect to, there should be one authoritative repository of configuration with centralized oversight. The most obvious place to keep this is DNS, as there already exist best practices and techniques to keep DNS secure (discussed below). Organizations should avoid hard-coding IP addresses into any other configurations.

With configuration centralized on DNS, IT orgs can take steps to protect their zone against attack. DNS zones should be audited regularly to ensure that referenced IP addresses are controlled by the organization. Some cloud providers, such as Azure, offer utilities to help with this. AWS also supports this on a per-service basis. In addition to routine audits, policies can be put in place to ensure DNS records are removed any time a referenced IP address is released to the cloud provider. In response to our research we anticipate cloud providers will offer more tooling to automatically ensure compliance here.

Controlling Trust

Our research showed a large amount of traffic that trusts IP addresses solely because of configuration referencing it. However, smart organizations can achieve defense-in-depth by authenticating services before sending sensitive information. By using pre-shared certificates for TLS, for instance, the client can ensure they are talking to a legitimate service even if the IP address is reused.

One key concern here is reliance on Public Key Infrastructure (PKI), which is how most TLS certificates are issued. Because many Certificate Authorities (CAs) now issue certificates based on validating DNS, an attacker who takes over a subdomain can also receive a TLS certificate for that domain. The greatest risk here is automated issuance via HTTP Challenges, which allow whoever hosts a web server under a domain to receive a valid certificate. This can be a subtle yet serious risk, as fraudulent TLS certificates further increase client trust in services controlled by attackers.

If organizations are using CA-issued certificates to authenticate servers before connecting, additional steps should be taken to prevent attackers from issuing certificates during subdomain takeovers. DNS zones can contain a CAA Record to limit certificate issuance to trusted CAs. Ideally, this CAA record should limit to a CA that does not support HTTP Challenges.

Solutions across cloud providers

Product offerings vary by provider. This table links to provider-specific documentation for the solutions discussed above:

How cloud providers are responding

We’ve notified major cloud providers of the issues we’ve discovered, and there are steps that providers can take to help protect tenants. In the case of Amazon, we disclosed all affected properties we discovered on their cloud, and they have indicated that they are taking steps to help assist their users²:

• Cloud Configuration. When cloud services can be configured to interact with an AWS compute resource, the management console is being updated to alert users when they subscribe elastic IP addresses directly to SNS Topics or health checks.

• Expanded scanning/disclosure of vulnerabilities. Amazon is developing tools that analyze control-plane information to locate customers with current misconfigurations across all tenants and regions. The outputs of scans will be used to send notices to customers with misconfigured cloud services to review their configuration for SNS topics and Route53 heath checks.

• Automated Policy Enforcement. Amazon is developing managed Config rules that customers can apply to their accounts within an organization. These Config Rules can be configured to prevent, remediate, or alert on cloud assets that meet the conditions of the rules.

• Updated Best Practices. AWS is updating Route53 and SNS best practices documentation to recommend customers avoid tying services and configurations to elastic IPs and ensuring good hygiene for server instantiating and decommissioning. For instance, best practice documentation for SNS will discuss the risks of failing to remove subscriptions, especially when raw IP addresses of AWS instances and unencrypted messages are used.

Conclusions

Cloud squatting poses a serious concern for IT organizations, and steps should be taken immediately and in the long-term to protect resources. In the near-term, orgs should review their DNS records, cloud services (especially subscriptions sending messages to IP addresses), and applications to ensure there are no old IP addresses that could leak sensitive information. Longer term, there should be a switch to consistent management of these configurations, with DNS serving as a central repository that supports policies and auditing. While the risks of cloud squatting are real, prudent management of resources can help organizations reap the benefits of the cloud while protecting user data.

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.