Blog

How to take over a subdomain in Google Cloud DNS

27 Jan, 2022
Xebia Background Header Wave

An attacker can take over your DNS subdomain in Google Cloud DNS when you reference a managed zone in Cloud DNS which no longer exists. In this blog I will show you how this happens and how you can detect potential misconfiguration. Google Cloud DNS allows you to create a managed zone for any DNS domain name, even for domains you do not own. Whenever you create a DNS managed zone, it assigns your domain to one of seven shards of Cloud DNS name servers. To allow an attacker to take over your subdomain, do the following:

  • create the dns managed zone
  • add the NS record to the parent domain
  • delete the DNS managed zone
  • wait for the attack…
  • attacker creates dns managed zone

Create the DNS managed zone

So, let’s start with creating the managed zone for the subdomain shop.binx.io.

gcloud dns managed-zones create shop-binx-io \
  --dns-name shop.binx.io \
  --format 'value(nameServers)'

ns-cloud-b1.googledomains.com.;ns-cloud-b2.googledomains.com.;ns-cloud-b3.googledomains.com.;ns-cloud-b4.googledomains.com.

This managed zone is now served by shard b of the Google Cloud DNS name servers.

At the momentof writing there are shards six shards: ns-cloud-a through to ns-cloud-f.

add the NS record to the parent domain

To activate this managed zone, add the name servers to the managed zone of binx.io:

gcloud dns record-sets create shop.binx.io. \
  --type NS \
  --zone binx-io \
  --ttl 300 \
  --rrdatas ns-cloud-b1.googledomains.com.,ns-cloud-b2.googledomains.com.;ns-cloud-b3.googledomains.com.;ns-cloud-b4.googledomains.com.

Now, Cloud DNS resolves the domain shop.binx.io with our managed zone.

dig NS shop.binx.io
;shop.binx.io.               IN      NS

;; ANSWER SECTION:
shop.binx.io.        299   IN      NS      ns-cloud-b1.googledomains.com.
shop.binx.io.        299   IN      NS      ns-cloud-b4.googledomains.com.
shop.binx.io.        299   IN      NS      ns-cloud-b3.googledomains.com.
shop.binx.io.        299   IN      NS      ns-cloud-b2.googledomains.com.

delete the managed zone

This is the dangerous part: delete the managed zone without removing the NS record from the parent domain.

gcloud dns managed-zones delete shop-binx-io 

The name server reference is now a dangling reference. DNS requests are still sent to the b shard of Google Cloud DNS, but there is no data there.

wait for the attack…

Now it is a matter of time, before somebody finds out that your subdomain is no longer resolving. And discovers that it points to a Google Cloud DNS name server.

attacker creates dns managed zone

The attacker now only has to re-create the managed zone in his/her own project, until Cloud DNS assigns his managed zone to the same shard.

gcloud dns managed-zones create attempt-1 \
  --dns-name shop.binx.io. \
  --format 'value(nameServers)'

ns-cloud-a1.googledomains.com.;ns-cloud-a2.googledomains.com.;ns-cloud-a3.googledomains.com.;ns-cloud-a4.googledomains.com

Miss! That is the a shard of Cloud DNS name servers. Let’s try again!

gcloud dns managed-zones create attempt-2 \
  --dns-name shop.binx.io. \
  --format 'value(nameServers)'

ns-cloud-b1.googledomains.com.;ns-cloud-b2.googledomains.com.;ns-cloud-b3.googledomains.com.;ns-cloud-b4.googledomains.com

Bingo! As there are only six shards, on average it will take three attempts. Now the attacker has control of the DNS subdomain name shop.binx.io. This allows the attacker to generate certificates and redirect traffic to a malicious site. Note that an attacker can also deny you the possibility to create a managed zone for a subdomain you own. By creating six managed zones for your domain name, there are no shards left to serve your domain. This will result in the following error:

The domain ‘shop.binx.io.’ (or its child domains) may be reserved or registered already, prohibited by policy, or there may be no DNS name server shards remaining for the name. For more information see https://cloud.google.com/dns/quotas#nameserver_limits

checking Cloud DNS organizational integrity

To check the integrity of your Cloud DNS managed zones in your organization, you can use the cloud-dns-integrity-checker. It reads all the DNS managed zones in your organization and checks the referential integrity of the name server records. t will report:

  • name server records which do not resolve on the internet.
  • mismatches between defined and actual name server records.
  • duplicate managed zones in the organization.
  • NS records without a matching managed zone in the organization.
    To run it, type:
cloud-dns-integrity-checker -organization xebia.com

2022/01/17 21:17:21 INFO: checking DNS nameserver integrity for organization xebia.com
2022/01/17 21:17:22 INFO: checking nameserver integrity for somebody-else.google.binx.dev.
2022/01/17 21:17:22 ERROR: mismatch in nameserver configuration for managed zone somebody-else.google.binx.dev. for domain somebody-else-google-binx-dev in project speeltuin-mvanholsteijn. expected
    ns-cloud-c1.googledomains.com.
    ns-cloud-c2.googledomains.com.
    ns-cloud-c3.googledomains.com.
    ns-cloud-c4.googledomains.com.
got
    ns-cloud-b1.googledomains.com.
    ns-cloud-b2.googledomains.com.
    ns-cloud-b3.googledomains.com.
    ns-cloud-b4.googledomains.com.
2022/01/17 21:17:22 INFO: checking nameserver integrity for google.binx.dev.
2022/01/17 21:17:22 INFO: checking nameserver integrity for mismatch.google.binx.dev.
2022/01/17 21:17:23 ERROR: unresolved nameservers for domain mismatch.google.binx.dev. in managed zone google-binx-dev of project speeltuin-mvanholsteijn: lookup mismatch.google.binx.dev. on [fd00::2e91:abff:fea1:b7b6]:53: server misbehaving
2022/01/17 21:17:23 INFO: checking nameserver integrity for somebody-else.google.binx.dev.
2022/01/17 21:17:23 INFO: checking nameserver integrity for xke.xebia.com.
2022/01/17 21:17:23 ERROR: unresolved nameservers for domain xke.xebia.com. of managed zone xke-xebia-com in project speeltuin-mvanholsteijn-2: lookup xke.xebia.com. on 192.168.188.1:53: no such host
2022/01/17 21:17:23 INFO: checking nameserver integrity for ttn.binx.io.
2022/01/17 21:17:23 INFO: checking nameserver integrity for playf.internal.
2022/01/17 21:17:23 ERROR: unresolved nameservers for domain playf.internal. of managed zone test-zone-internal in project playground-fchyla: lookup playf.internal. on 192.168.188.1:53: no such host
2022/01/17 21:17:23 INFO: checking nameserver integrity for xke.xebia.com.
2022/01/17 21:17:23 ERROR: unresolved nameservers for domain xke.xebia.com. of managed zone xke-xebia-com in project xke-nxt: lookup xke.xebia.com. on 192.168.188.1:53: no such host
2022/01/17 21:17:24 INFO: checking nameserver integrity for mismatch.google.binx.dev.
2022/01/17 21:17:24 ERROR: unresolved nameservers for domain mismatch.google.binx.dev. of managed zone mismatch-google-binx-dev in project speeltuin-mvanholsteijn: lookup mismatch.google.binx.dev. on [fd00::2e91:abff:fea1:b7b6]:53: server misbehaving
2022/01/17 21:17:24 INFO: checking nameserver integrity for my.dns.binx.io.
2022/01/17 21:17:24 ERROR: unresolved nameservers for domain my.dns.binx.io. of managed zone my-dns-zone in project speeltuin-mvanholsteijn: lookup my.dns.binx.io. on 192.168.188.1:53: no such host
2022/01/17 21:17:25 INFO: checking nameserver integrity for u.girlsday.fun.
2022/01/17 21:17:25 ERROR: unresolved nameservers for domain u.girlsday.fun. of managed zone u-girlsday-fun in project girlsday: lookup u.girlsday.fun. on 192.168.188.1:53: no such host
2022/01/17 21:17:25 ERROR: domain mismatch.google.binx.dev. has a nameserver record in google-binx-dev, but there is no managed zone for it in this organization
2022/01/17 21:17:25 ERROR: domain somebody-else.google.binx.dev. has a nameserver record in google-binx-dev, but there is no managed zone for it in this organization

Conclusion

An attacker can take over your DNS subdomain in Google Cloud DNS, if you delete the managed zone from your project without removing the associated nameserver records. So you must remove the NS records when you delete a managed zone. The cloud-dns-integrity-checker can detect problems in the Cloud DNS configuration of your GCP organisation. Note that the same type of error can occur when using AWS’s Route53. Image by Darkmoon_Art from Pixabay

Mark van Holsteijn
Mark van Holsteijn is a senior software systems architect at Xebia Cloud-native solutions. He is passionate about removing waste in the software delivery process and keeping things clear and simple.
Questions?

Get in touch with us to learn more about the subject and related solutions

Explore related posts