Cloud Metadata Case Study: Request for Instance Credentials Blocked Before Any Connection Is Made

A program asks the cloud’s metadata address for the machine’s credentials, the classic first move after a server-side request forgery. vpnw refuses it before any connection is made.

On most clouds, 169.254.169.254 answers any program on the machine with the instance’s credentials. An agent talked into fetching that address, by a crafted link or an instruction hidden in a page, can hand over the keys to the cloud account. The case was recorded with VPN Works 0.2.0’s demo kit; the screenshot is from that recording, and the behavior is the same in 0.4.0.

The defense is one line in the policy.

deny_private

[policy]
deny_private = true
allow = ["api.github.com", "pypi.org"]

deny_private refuses loopback, the private ranges, link-local addresses (where cloud metadata lives) and the IPv6 forms that embed them. It’s checked against every address a name resolves to, before the allow list, so a name that points at a private address is refused too. A rebinding trick, a public name that resolves to 169.254.169.254, gets nowhere.

The refusal happens in vpnw before it dials anything, so nothing reaches the metadata service. In the recorded run the policy was just two flags, --deny-private --default allow: the whole internet allowed, the metadata address refused, and curl got vpnw’s explanation instead of credentials.

Even Without a Policy

The sealed sandbox has no route to 169.254.169.254 at all, so a program that ignores proxy settings and connects directly fails at once. That route is one of the 17 ways out the tests try, and it’s blocked. The sealed sandbox

Through a Tunnel

With a WireGuard path, deny_private still applies, and it applies to the tunnel’s own private addresses too. That’s usually what you want for an agent that should reach only the internet. For an agent that needs an office system on a private address, allow that address explicitly, or leave deny_private off and keep the allow list short.