Securing your cloud network (VPC) using firewall rules is common practice. Google Cloud firewall rules however do not apply to Cloud DNS calls made from the metadata server. Therefore, you can exfiltrate data by querying public domains from your instance. In this blog I’ll share how that happens and what you can do about it.

DNS data exfiltration?

After gaining access to personal/company data, the challenge is to get the data out. Typically the company firewall blocks internet access, so you need an alternative to exfiltrate data.

To exfiltrate date using DNS, you send multiple queries to your own name server. Each query contains a portion of the data to exfiltrate:

1. a0123zzlaure01.my-evil-domain.com
2. a0123zzns0002.my-evil-domain.com
3. a0123zzloves03.my-evil-domain.com
4. a0123zzcloud04.my-evil-domain.com

On your name server, you combine query logs to return personal/company data. In this case: laurens loves cloud.

Name resolution for Cloud DNS

Resources running in Google Cloud use the metadata server (169.254.169.254) as their name server by default. This name server uses your VPC’s DNS configuration, which by default queries publicly available DNS servers to resolve the IP address, and to get your data out.

To change this you can configure zones, server policies and response policies. Zones allow you to configure your own DNS records for a specific domain e.g. example.com. Server policies allow you to forward DNS requests to your own name servers to resolve internal DNS records for example. Response policies allow you to alter results for DNS requests.

The final behavior uses the following logic:

• If an outbound server policy applies, all DNS queries are forwarded to the alternative servers.
• Without an outbound server policy, the following priority of zones and response policies applies to the best match (longest suffix match):
  1. response policy
  2. private zone such as Cloud DNS private zone, forwarding zone and/or peering zone
  3. internal dns of Compute Engine e.g. my-vm.europe-west4-a.c.my-project.internal
  4. public dns

Blocking public DNS requests

To keep the data in you must limit public DNS requests. A brute force solution is to block all public DNS requests using the top level private zone: ..

resource "google_dns_managed_zone" "black_hole" {
  project  = var.project_id
  name     = "black-hole"
  dns_name = "."

  visibility = "private"

  private_visibility_config {
    networks {
      network_url = var.network_id
    }
  }
}

While this might work for an isolated VPC, disabling DNS will break most solutions. Sadly, an out of the box, Google managed solution is currently not available. Therefore you could run your own secure DNS server or implement custom logic that scans the DNS logs and configures response policies to block specific domains.

Conclusion

Additional measures are required to protect your data from DNS exfiltration attacks. Sadly, these measures are not yet offered as Google managed service. However, by understanding the attack and the available GCP options, you are well suited to monitor for the attack and respond accordingly.

Image by Susanne Jutzeler, Schweiz from Pixabay