1

AWS has a feature called Instance Metadata, which on EC2 gives you access to the AWS credentials through HTTP calls:

curl http://169.254.169.254/latest/meta-data/iam/security-credentials/<role>

The feature itself is intentional, thus technically not a vulnerability. The risk is also stated in the documentation:

If you use services that use instance metadata with IAM roles, ensure that you don't expose your credentials when the services make HTTP calls on your behalf. The types of services that could expose your credentials include HTTP proxies, HTML/CSS validator services, and XML processors that support XML inclusion.

As long as an application cannot be tricked by an attacker to make such a request and to output the response, it is certainly a convenient feature. Unfortunately, it is a common source of attacks.

Of course, a server should properly verify all URLs before, but in the spirit of defense in depth, I wonder if it is possible to disable it, or maybe allow it only during startup (before opening any ports).

Questions:

  • Is it technically possible to disable the feature? In other words, how can I ensure that requests to http://169.254.169.254/ are blocked?
  • If it is technically possible, are there any drawbacks in blocking it?
  • Is there a way to still have access to the safe parts of the API, but not to the critical ones? Maybe by whitelisting specific paths? For example, I see the point of allowing /meta-data/spot/instance-action, which tells you whether your EC2 spot instance has been scheduled for termination.
  • 2
    I assume you're running Linux on the instance? Most platforms have a way to firewall specific outbound requests. – CBHacking Oct 10 at 0:38
  • 1
    There's an excellent episode of Paul's Security Weekly about how the metadata service was exploited in the Capitol One hack, and how you can design your apps to prevent these kinds of SSRF vulns. youtube.com/watch?v=QA4osihIAkY – Mike Ounsworth Oct 10 at 0:40
  • 1
    As @CBCHacking says, the place to start is some reading about outbound iptables or firewalld rules (ip-based firewall) or outbound WAFs (URL-based firewall, do OS-level outbout WAFs even exist??). Though you should be careful with these; I'm under the impression that some of the background AWS services on the VM that make it play nicely in the EC2 environment will fail if they can't reach metadata. I have not confirmed myself though. – Mike Ounsworth Oct 10 at 0:41
  • @MikeOunsworth Thanks for sharing. – Philipp Claßen Oct 10 at 0:44
  • @CBHacking Yes, there are all Linux systems. Firewall rules would probably work. I can give that a try. – Philipp Claßen Oct 10 at 0:54
2

Since you're using Linux, you can do this using iptables. It's possible to block specific UIDs from making specific requests. See https://unix.stackexchange.com/questions/104830/block-specific-application-with-iptables, or https://www.cyberciti.biz/tips/block-outgoing-network-access-for-a-single-user-from-my-server-using-iptables.html (the latter is quite old, but I think still correct).

What I'd do for your case: add a rule that DROPs network OUTPUT from the UID that your server(s)/process(es) run as to that IP address. Assuming you don't run everything as the same user, that shouldn't break any other processes that want to access the metadata service, while preventing SSRFs or similar issues for that specific endpoint.

iptables -I OUTPUT -d 169.254.169.254 -m --uid-owner <UID or maybe username> -j DROP

This (I think; not tested):

  • Adds a rule to the beginning of the OUTPUT chain (used for outbound packets)
  • Filters to packets that are bound for 169.254.169.254
  • Matches only packets originating from a process with the specified owner (unsure whether this checks real or effective UID but you should drop any higher privileges as soon as possible anyhow)
  • Drops it on the floor.
  • Separating by the user is an interesting idea to avoid undesired side-effects. I'll try that out. – Philipp Claßen Oct 10 at 1:09

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.