Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Query about network level firewalling #4

Open
ct-dh opened this issue Jun 30, 2021 · 4 comments
Open

Query about network level firewalling #4

ct-dh opened this issue Jun 30, 2021 · 4 comments

Comments

@ct-dh
Copy link

ct-dh commented Jun 30, 2021

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
Copy link
Owner

irsl commented Jun 30, 2021

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
Copy link
Author

ct-dh commented Jul 1, 2021

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
Copy link
Owner

irsl commented Jul 1, 2021

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
Copy link

c3st7n commented Jul 2, 2021

@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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants