search

irsl / gcp-dhcp-takeover-code-exec

Google Compute Engine (GCE) VM takeover via DHCP flood - gain root access by getting SSH keys added by google_guest_agent
532 stars 35 forks source link

Query about network level firewalling #4

Open ct-dh opened 3 years ago

ct-dh commented 3 years ago

Apologies if I have misunderstood something here, but in my tests, if I have Google firewall rules in place denying ingress on UDP port 68 (or no rules explicilty allowing it) then the traffic does not get through. From reading the README, I was led to think this was not possible and it had to be achieved using host based firewall rules.

Can you confirm if I am correct in my assessment that the GCP SDN network based firewall is capable of mitigating this attack?

Also, I checked some Google COS (container optimized OS) based images, and I don't see the DHCP hook google_set_hostname on the filesystem. Can you confirm what images/distros you tested in this exploit?

irsl commented 3 years ago

Communication between VMs on the same network is unfiltered by default, so udp/68 is accessible and can be targeted. This is what attack 1 and 2 are about. Exploitation here of course requires attacker presence in that subnet (a compromised VM, container, or similar where UDP traffic can be initiated from.) If you want to ensure that a compromised VM can't infect the others in the same project, you can do that by setting up a host level firewall rule blocking udp/68 with source IP other than the metadata server. The "full remote" attack 3 does not work in default setups as it requires the firewall to allow udp/68 either explicitly or by disabling the firewall as is.

I carried out the research with the default VM OS in GCE, which is "Debian GNU/Linux 10 (buster)". I didn't test Google COS at all.

ct-dh commented 3 years ago

Thanks for the response.

It might be worth updating the remediation section or the FAQ to state that you can use the network level firewalling to remediate this. The way it is currently worded, I read it as meaning you can't use the GCP firewall rules to block this type of traffic and would have to rely on host based firewall rules. The traffic from the legitimate metadata server cannot be blocked according to the docs, so the users do not have to worry about their rules accidentally blocking the real metadata traffic.

irsl commented 3 years ago

You are correct, thanks for drawing this to my attention. I'm adding an entry about this in the FAQ soon. Btw, could you please reference the docs about the metadata server?

c3st7n commented 3 years ago

@ct-dh is my work based account, posting this from personal device under different user.

The docs are at https://cloud.google.com/vpc/docs/firewalls#alwaysallowed