Most security issues in the cloud can be traced back to someone doing something stupid. Sorry to be that blunt, but I don’t see ingenious hackers out there. I do see misconfigured cloud resources, such as storage and databases, that lead to vulnerabilities that could easily be avoided.
I always teach how your first line of defense is not cool security tools but training. This is often ignored, considering that budgets are directed at new tools rather than teaching admins how not to do dumb things. It is frustrating considering the investment needed versus the value gained. Oh well.
A new threat
Although cloud squatting is being pushed as a new threat, we’ve known about it for years. What changed is that as we move more assets into the public cloud and have new people taking care of these assets, there seems to be a renewed interest in this vulnerability. Perhaps the bad actors are getting better at exploiting it.
The core issue is that cloud asset deletions often occur without removing associated records, which can create security risks for subdomains. Failure to also delete records allows attackers to exploit subdomains by creating unauthorized phishing or malware sites. This is called cloud squatting.
Resources are provisioned and deallocated programmatically, typically. Allocating assets such as virtual servers and storage space is quick, generally done in seconds, but deallocation is more complex, and that’s where the screwups occur.
We’re seeing the creation of multiple records pointing to temporary cloud resources for different applications and tools; then organizations fail to delete cloud assets and associated records. Let’s discuss how this happens.
Mitigating cloud squatting
Identifying and fixing cloud squatting is challenging for large enterprises with vast amounts of domains. Moreover, global infrastructure teams have varying degrees of training, and with 100 or more people in the security admin team, you’re bound to run into this problem a few times a month. Keep in mind it is avoidable.
To mitigate this risk, the security teams design internal tools to comb through company domains and identify subdomains pointing to cloud provider IP ranges. These tools check the validity of IP records assigned to the company’s assets. These are assigned automatically by cloud providers. I always get nervous when companies create and deploy their own security tools, considering that they may create a vulnerability.
Mitigating cloud squatting is not just about creating new tools. Organizations can also use reserved IP addresses. This means transferring their owned IP addresses to the cloud, then maintaining and deleting stale records, and using DNS names systemically.
If you’re not a network person and don’t know your DNSs from your IRSs, that’s fine. The idea is to remove the ability for old, undeleted records to be exploited. Anyway, what you can do is not a complex process. Also, enforce a policy to prevent hard-coding of IP addresses and using reserved IPv6 addresses (if offered by the cloud provider).
Two-phase approach
We can deal with this risk in two stages:
- First, address the large attack surface by implementing the above-mentioned mitigation strategies.
- Second, enforce policies for using DNS names, and regularly maintain records for effective management.
If this seems like nothing too taxing, you are correct. However, two things are occurring right now that are causing cloud squatting to become more of a threat.
The issue is the rapid expansion of cloud deployments during the pandemic. Massive amounts of data were pushed into the clouds, with domains allocated to find that data and little thought about removing them when they became unnecessary. I see this often left out of deployment playbooks. When I call people out on it, I usually get the response, “We did not have time to think about that.”
We’re also working with a talent deficiency right now. Most of these issues can be traced to inadequate training or hiring lower-tiered cloud administrators to keep things going. Often, certifications will get you a job, whereas actual experience is more important. I suspect that most enterprises will have to “touch the stove” to understand the impact.