5 ms·

The blog post buries the lead a little bit because it's talking about lots of pain points with the ec2 API and IAM. The important point to take away is that any

• kevsim 10y ago
  I believe Pocket faced exactly this issue once upon a time.
  • Qerub 10y ago
    Indeed! https://www.gnu.gl/blog/Posts/multiple-vulnerabilities-in-pocket/ https://www.gnu.gl/blog/Posts/multiple-vulnerabilities-in-po...
• strictfp 10y ago
  ....and that you can imitate the metadata service to make life easier :) A plug for my friends side project: https://github.com/otm/limes https://github.com/otm/limes . It's a local metadataservice. Very handy for making aws libs work without having to config them much. And great support for MFAs.
• deleted 10y ago
  [deleted]
• novaleaf 10y ago
  do you know if any similar vulnerability exists with Azure or Google Cloud? edit: not sure why the downvote, I use Google Cloud, so honest question :(
  • Pharaoh2 10y ago
    You are getting downvoted because it's not a vulnerability. It's well documented and very useful feature in aws and it also exists in gcloud, although gcloud documentation is not as good^1. It only becomes a vulnerability if you don't read the documentation AND don't follow best practices^2. I don't know if azure provides this feature. ^1 I use gcloud now and have used aws in the past. ^2 Don't run unknown code without proper sandboxing
    • hueving 10y ago
      It's borderline a privilege escalation vulnerability. The default behavior is that an unprivileged user on the system with network access can get access to an instance's credentials that can be used to perform administrative functions. Like Colin pointed out in the blog post, this completely subverts the permissions model in modern operating systems.
      • subway 10y ago
        No, it is not a vulnerability. Misunderstanding of this functionality can result in developer introducing a vulnerability, but this is a well described, well defined feature. Calling this a vulnerability is akin to calling the existence of `rm` a vulnerability because it can delete files.
    • novaleaf 10y ago
      I didn't mean to suggest it being what it isn't. I allow usage patterns similar to what is being described, so it is a vulnerability in something, be it my fault or not.
      • Pharaoh2 10y ago
        If your service allows arbitrary url queries that a user can trigger then you should make sure that you only allow queries to publicly routable ip ranges anyway. 169.254.0.0/16 is link-local range which you should be flitering along with publicly routable ip ranges that might be very upset if you access them like .mil reserved ip ranges. Go as far to also only allow DNS names instead of arbitrary ip, keeping in mind dns names may resolve to non publicly routable ranges or ranges you may not wish to access. These are all standard dangers of making queries on a user's behalf. Good list of ipv4 ranges you should not allow: https://github.com/robertdavidgraham/masscan/blob/master/data/exclude.conf https://github.com/robertdavidgraham/masscan/blob/master/dat...
  • mdeeks 10y ago
    There is a local metadata API for Azure but it is fairly simple right now. Some limited instance info about your host ID, fault domain, and update domain: curl http://169.254.169.254/metadata/v1/InstanceInfo http://169.254.169.254/metadata/v1/InstanceInfo Poll this regularly to find out when your VM is about to go down for maintenance: http://169.254.169.254/metadata/v1/maintenance http://169.254.169.254/metadata/v1/maintenance Those are the only two endpoints I know of. I encouraged them to require a special header for access to this API before releasing to the public but it looks like it was not included. A special header would help prevent your app from being able to access this from a user specified URL. Google requires a header to help prevent this: https://cloud.google.com/compute/docs/storing-retrieving-metadata#querying https://cloud.google.com/compute/docs/storing-retrieving-met...
    • novaleaf 10y ago
      thank you so much for posting these extra details. My product is hosted on Google Cloud and allows users to arbitrarily craft http requests (including headers!) I try to limit the possibility of abuse (restricting protocol to http, https, //, data, or ftp) but didnt know about this metadata issue. I updated my product to account for this issue too. it looks like google's metadata doesn't leak any important secrets (unless I had custom metadata, which i do not) but better safe than sorry!
• inopinatus 10y ago
  Fun fact: you can ignore EC2 instance roles and use the Amazon Cognito service for processes to obtain role-based short-term credentials. I've described it previously as "Kerberos for the AWS Cloud" (which will make any self-respecting crypto nerd squirm) but hopefully it conveys the general idea. Yes it was designed for mobile & browser use, and yes the API isn't pretty, but it's there.
• cddotdotslash 10y ago
  This is actually a vulnerability I've seen countless times. If a site accepts a URL which it reads and returns to the user, submit the 169.254.169.254 metadata service. About 1 out of 5 times I've tried it, I'm about to get a response.
  • startling 10y ago
    Sometimes you can do this with things like smtp servers as well.
  • stevekemp 10y ago
    I think that's another example of bad filtering, same thing that happens if you accept an URL and don't disallow `file:///etc/passwd`.