Hacker News new | past | comments | ask | show | jobs | submit login
Locking Down the Instance Metadata Service: Announcing Imds-Filterd (daemonology.net)
41 points by cperciva on Jan 28, 2020 | hide | past | favorite | 8 comments



This is great defense in depth but if someone gets RCE on your host then I would assume that entire box is compromised. Local privilege escalation is very frequently possible, only costs ~$50k for a 0day [1] and there are tons of free PoCs available if you don't keep your systems fully patched.

The protection I would highly recommend everyone use is enabling Amazon's "v2" metadata service [2] in enforce mode, which will neuter nearly all SSRF metadata attacks. This won't do anything if someone has RCE on your host, but it would have prevented the Capital One breach the author uses as their example. Nearly every metadata compromise in recent history has been through SSRF.

Another aspirational read is how Netflix detects credential compromise [3]: the first time a host asks for metadata credentials they save its ip address, and if they ever see those credentials used from a different ip address they alert on it.

[1]: https://zerodium.com/program.html

[2]: https://aws.amazon.com/blogs/security/defense-in-depth-open-...

[3]: https://netflixtechblog.com/netflix-cloud-security-detecting...


Local privilege escalation is very frequently possible

I would say that how frequently it's possible depends on the context. If someone gets RCE as user nobody running inside /var/empty, there's a wide range of vulnerabilities which they would be unable to utilize. Even more so if they're locked down with Capsicum or other sandboxing tools.

People talk about RCE as if it's a single category, but there are many cases where someone might be able to execute arbitrary code inside a sandbox while not having the ability to execute arbitrary code on the host system.


Definitely been meaning to test out Amazon's V2 metadata service. I presented some research last year on misconfigured reverse proxies [0] that allowed access to the metadata URL within AWS, Azure, and Digital Ocean. Not sure if a hardened service is on the roadmap for Azure or Digital Ocean though, so this could fill that gap.

[0] https://github.com/opsdisk/cloud_metadata_extractor/blob/mas...


Does this provide any advantages over the Instance Metadata Service v2 that launched last year?

https://aws.amazon.com/blogs/security/defense-in-depth-open-...


Yes. IMDSv2 only addresses misconfigured proxies.


Nice! I do currently filter based on username / groups in my firewall policies on my virtualized Linux hosts which has been pretty effective but yes there are some places where I've had to give an otherwise unprivileged user the ability to query the metadata service which is not great. In most cases restricting this to root is sufficient.


Does the packet filter vs routing performance thing apply also on Linux, would doing this with netfilter add perf overhead and do people run Linux without netfilter in high-load environments? Is using route tables instead a valid pattern that should be applied also more widely?


Does the packet filter vs routing performance thing apply also on Linux

I haven't looked at the Linux kernel code, but keeping routes cached per-flow is a trivial optimization; I'd be shocked if they weren't using it.




Consider applying for YC's Spring batch! Applications are open till Feb 11.

Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: