3 ms·
If your threat model is your cloud provider, aren't you already screwed since they already have physical access to your VMs?
by trinovantes 5y ago
If your threat model is your cloud provider, aren't you already screwed since they already have physical access to your VMs?
- kjaftaedi 5y agoThe threat is not the cloud provider and this has nothing to do with physical access. The software vulnerability can be exploited by anyone with network access to the machine.
- NovemberWhiskey 5y agoI don't think that's the threat model here - this is more a lateral movement vector for an attacker that's able to get inside your service network perimeter.
- rocqua 5y agoCorrect. Sadly the issue is that the cloud provider installed an agent that only blocks requests if the authentication header does not contain correct authentication. If you remove the authentication header, that check never fires, and it considers you authenticated. Then it proceeds to let you run any command. Now the point is, anyone who can send you messages can strip the authentication header, so anyone who can send you messages can execute arbitrary commands.
- nonameiguess 5y agoThe thread model isn't the cloud provider, it's anyone who can spoof the IP of your cloud provider's metadata service CIDR block. These tend to be link-local IPs, so it's common for the cloud boundary firewall itself to block anything incoming from that block, so the attacker would need to already in the perimeter, but it isn't exactly hard to get inside the data center just by being another tenant. This is one reason why it's common to block at the host level any packets with a src IP in the metadata service's CIDR block, just in case. You give up certain forms of remote management capabilities, but that is often worth it not to open up back doors developers are rarely even aware of.